لیگیسی سسٹم کو جدید بنانے کے 4 راستے ہیں: اسے جوں کا توں کلاؤڈ پر منتقل کرنا، اس کا کوڈ کسی جدید پلیٹ فارم پر تبدیل کرنا، آپ کے نکالے گئے کاروباری اصولوں کے گرد اسے دوبارہ بنانا، یا اسے تیار پروڈکٹ سے بدل کر صرف ڈیٹا رکھنا۔ فیصلہ 4 سوال کرتے ہیں: کیا آپ کے اصول آپ کی کمپنی کے اپنے ہیں؟ مسئلہ اس جگہ میں ہے جہاں سسٹم چلتا ہے یا خود سسٹم میں؟ اس کا کوڈ اب بھی کون سمجھتا ہے؟ آپ کے ملازمین کتنی تبدیلی برداشت کر سکتے ہیں؟ Amazon ان راستوں کو 7 حکمت عملیوں میں اور Microsoft انہیں 8 میں تقسیم کرتا ہے، اور دونوں ہر سسٹم کا فیصلہ الگ کرتے ہیں۔

حصہ 4 میں آپ نے اپنے سسٹم کے کاروباری اصول نکالے اور عمل کے ذمہ داروں سے ان کی تصدیق کروائی۔ یہی اصول نیچے دیے گئے موازنے کو ممکن بناتے ہیں: ان کے بغیر آپ نہیں جانتے کہ ہر راستے پر سسٹم کا کون سا رویہ کھو جائے گا۔

چاروں راستے آسان الفاظ میں

تکنیکی نام بہت ہیں، لیکن وہ 4 فیصلوں تک سمٹ جاتے ہیں جنہیں کوئی بھی مینیجر سمجھ سکتا ہے۔ یہ جدول ان کا موازنہ کرتا ہے؛ قوسین میں دیے گئے نام وہ ہیں جو آپ وینڈرز سے سنیں گے:

راستہکب موزوں ہےکیا محفوظ رہتا ہےکس چیز کا خطرہکسے شامل ہونا چاہیے
جوں کا توں منتقل کرنا (Rehost)سسٹم مستحکم ہے اور اپنا کام کرتا ہے؛ مسئلہ سرورز یا ڈیٹا سینٹر میں ہےسب کچھ: کوڈ، اصول اور کام کا طریقہپرانے مسائل نئی جگہ ساتھ چلے جاتے ہیںآئی ٹی اور سیکیورٹی و ڈیٹا کا ذمہ دار
کوڈ تبدیل کرنا (Replatform یا Refactor)اصول درست ہیں، لیکن زبان یا پلیٹ فارم کی سپورٹ ختم ہو چکی ہے یا لائسنس بوجھ بن گئے ہیںاصول اور سسٹم کا رویہ، جدید زبان یا پلیٹ فارم پرچھپی ہوئی تبدیلی کی غلطیاں جو صرف نایاب صورتوں میں ظاہر ہوتی ہیںڈیولپرز، اور نتائج جانچنے کے لیے عمل کے ذمہ دار
اصولوں کے گرد دوبارہ بنانا (Rebuild)اصول آپ کی کمپنی کے اپنے ہیں اور آپ کو ممتاز بناتے ہیں، اور پرانا سسٹم اب آپ کی ضروریات نہیں سنبھال سکتاتصدیق شدہ اصول اور ڈیٹا؛ کوڈ نئے سرے سے لکھا جاتا ہےسب سے طویل راستہ، جس میں انتظامیہ کے سب سے زیادہ فیصلے درکار ہیںانتظامیہ، عمل کے ذمہ دار اور ڈیولپمنٹ ٹیم مل کر
تیار پروڈکٹ سے بدلنا (Replace)اس شعبے میں آپ کا کام دوسروں جیسا ہے، جیسے ایچ آر یا عمومی اکاؤنٹنگصرف ڈیٹاملازمین پروڈکٹ کے مطابق اپنا طریقہ بدلتے ہیں، اور جن اصولوں کو پروڈکٹ سپورٹ نہیں کرتا وہ کھو جاتے ہیںانتظامیہ اور وہ ملازمین جو روزانہ اسے استعمال کریں گے

سورس کوڈ وہ پروگرام کا متن ہے جس میں سسٹم لکھا گیا تھا۔ اگر وہ آپ کے پاس نہیں ہے، یا اب کوئی اسے نہیں سمجھتا، تو کوڈ تبدیل کرنے کا راستہ مشکل ہو جاتا ہے؛ Amazon کی حکمت عملی گائیڈ ایسی ایپلیکیشن کو، جسے کوئی برقرار رکھنا نہیں جانتا یا جس کا سورس کوڈ دستیاب نہیں، ان صورتوں میں شمار کرتی ہے جو دوبارہ ڈیزائن کی طرف لے جاتی ہیں۔

AI سے کوڈ تبدیل کرنے والے ٹولز کہاں کام آتے ہیں

AWS Transform جیسے ٹولز بنیادی طور پر دوسرے راستے پر کام کرتے ہیں: وہ پرانا کوڈ پڑھتے ہیں اور اسے جدید پلیٹ فارم پر تبدیل کرتے ہیں، مثلاً پرانی .NET Framework ایپلیکیشنز کو Linux پر چلنے والے جدید ورژن پر لے جانا۔ Amazon کہتا ہے کہ یہ ٹول Windows، مین فریم اور VMware ایپلیکیشنز کو 5 گنا تک تیزی سے جدید بناتا ہے؛ یہ Amazon کا اپنی سروس کے بارے میں دعویٰ ہے، کوئی ضمانت شدہ نتیجہ نہیں۔ اس کے قیمتوں کے صفحے کے مطابق سروس ہر ایجنٹ منٹ کے 0.035 ڈالر لیتی ہے اور صارف کے فارغ وقت کا معاوضہ نہیں لیتی۔

لیکن ٹول آپ کے لیے راستہ نہیں چنتا۔ جب کوڈ تبدیل کرنا درست فیصلہ ہو تو وہ اسے تیز کرتا ہے، اور اگر بہتر جواب سسٹم کو تیار پروڈکٹ سے بدلنا ہو تو وہ زیادہ مدد نہیں کرتا۔ یہ بھی یاد رکھیں کہ ریجنز کے صفحے پر مشرق وسطیٰ کا کوئی ریجن نہیں ہے اور خبردار کیا گیا ہے کہ آپ کا ڈیٹا کسی دوسرے ریجن میں پروسیس ہو سکتا ہے، جبکہ سعودی پریس ایجنسی کے مطابق Amazon نے مملکت میں اپنا کلاؤڈ ریجن دسمبر 2026 میں شروع کرنے کا اعلان کیا ہے۔ اگر آپ کے کوڈ میں صارفین کا ڈیٹا ہے تو شروع کرنے سے پہلے دیکھ لیں کہ وہ کہاں پروسیس ہوگا۔

خرچ اور مدت کن باتوں سے طے ہوتے ہیں

ہم آپ کو کوئی عدد نہیں دیں گے، کیونکہ آپ کے سسٹم کو جانے بغیر دیا گیا ہر عدد اندازہ ہے۔ یہ وہ عوامل ہیں جو ہر راستے پر خرچ اور مدت کو بڑھاتے یا گھٹاتے ہیں:

  • سائز اور الجھاؤ: اسکرینوں، رپورٹوں اور اس سے جڑے دوسرے سسٹمز کی تعداد، جیسا کہ حصہ 3 میں آپ کی فہرست نے دکھایا۔
  • اصولوں کی وضاحت: ہر تصدیق شدہ اصول وقت بچاتا ہے، اور ہر نامعلوم اصول کا مطلب ہے دیر سے ہونے والی مہنگی دریافت۔
  • ڈیٹا کا معیار: دہرایا گیا یا نامکمل ڈیٹا کسی بھی منتقلی سے پہلے صاف کرنا پڑتا ہے، راستہ جو بھی ہو۔
  • ملازمین کے لیے کتنا کچھ بدلتا ہے: جوں کا توں منتقل کرنے سے صارف کے لیے کچھ نہیں بدلتا؛ بدل دینے سے تقریباً سب کچھ بدل جاتا ہے اور تربیت درکار ہوتی ہے۔
  • سسٹم کو اب بھی کون سمجھتا ہے: اس کی تاریخ جاننے والا ایک ملازم ہفتوں کے اندازوں سے بچا لیتا ہے۔

مراحل کی ترتیب پر دو سرکاری ذرائع مشورہ دیتے ہیں۔ Amazon کی گائیڈ آرکیٹیکچر کی ازسرنو تشکیل کو سب سے پیچیدہ اور سب سے مہنگی حکمت عملی قرار دیتی ہے، اور بڑی منتقلیوں میں پہلے منتقل کرنے اور منتقلی مکمل ہونے کے بعد جدید بنانے کا مشورہ دیتی ہے۔ Microsoft کا Cloud Adoption Framework کہتا ہے کہ جوں کا توں منتقل کرنا صرف تب موزوں ہے جب آپ کو یقین ہو کہ ورک لوڈ کم از کم دو سال اپنی موجودہ حالت میں رہے گا؛ ورنہ کام دو بار کرنے سے بچنے کے لیے فوراً جدید بنانا بہتر ہے۔ خود منتقلی کے مراحل ہم نے کلاؤڈ پر منتقلی کی اپنی عملی گائیڈ میں بیان کیے ہیں۔

دو آپشن جنہیں سب بھول جاتے ہیں: برقرار رکھنا اور ریٹائر کرنا

ہر لیگیسی سسٹم کو ابھی جدید بنانے کی ضرورت نہیں۔ Amazon اور Microsoft دونوں کی فہرستیں ایسے دو آپشنز سے شروع ہوتی ہیں جن پر پورے پروجیکٹ کا خرچ نہیں آتا:

  • ریٹائر کرنا: کچھ سسٹم دراصل اب استعمال ہی نہیں ہوتے۔ Amazon مثال دیتا ہے ایسی ایپلیکیشنز کی جن پر پچھلے 90 دنوں میں کوئی آنے والا کنکشن نہیں آیا، یا جن کا پروسیسر اور میموری کا استعمال 5 فیصد سے کم ہے۔ ان کا ڈیٹا آرکائیو کر کے انہیں بند کرنے سے دیکھ بھال اور سیکیورٹی کا خطرہ کم ہوتا ہے۔
  • برقرار رکھنا: ایسا مستحکم سسٹم جو اپنا کام کرتا ہے اور جسے جلد بدلنے کی کوئی وجہ نہیں، یا ایسا سسٹم جو فیکٹری کی کسی ایسی مشین سے جڑا ہے جس کا کوئی متبادل نہیں۔ یہاں فیصلہ ہے اسے رکھنا، اس پر نظر رکھنا اور بعد میں دوبارہ دیکھنا۔

اگر آپ اسے کسی تیار ERP سے بدلنے کی طرف مائل ہیں تو پہلے ERP کیسے منتخب کریں میں بیان کردہ معیارات سے تیار اور کسٹم کا موازنہ کریں، اور تصدیق شدہ اصولوں کی اپنی فہرست سے آغاز کریں: ہر وہ اصول جسے پروڈکٹ سپورٹ نہیں کرتا، یا تو مہنگی کسٹمائزیشن بنے گا یا ہاتھ کا کام۔

Origami کا نقطۂ نظر

ہم ٹیکنالوجی سے نہیں، اصولوں سے شروع کرتے ہیں: اس سسٹم کے کون سے کاروباری اصول آپ کی کمپنی کو ممتاز بناتے ہیں، اور کون سے سب میں مشترک ہیں؟ جو چیز آپ کو ممتاز بناتی ہے وہ احتیاط سے بنانے یا تبدیل کرنے کے لائق ہے؛ جو مشترک ہے اسے آپ کے دوسرے سسٹمز سے اچھی طرح جڑا ہوا ایک تیار پروڈکٹ بخوبی سنبھال سکتا ہے۔ اسی لیے فیصلہ اکثر ملا جلا ہوتا ہے: ایک سسٹم بدلا جاتا ہے، دوسرے کا کوڈ تبدیل ہوتا ہے، تیسرا جوں کا توں رکھا جاتا ہے۔

ہم AI ٹولز وہاں استعمال کرتے ہیں جہاں وہ واقعی وقت بچاتے ہیں، کوڈ پڑھنے، تبدیل کرنے اور ٹیسٹ کرنے میں، لیکن راستے کا انتخاب انتظامیہ کے پاس رہتا ہے، جب وہ دیکھ لے کہ ہر آپشن کیا محفوظ رکھتا ہے اور کیا کھوتا ہے۔ اگر آپ دیکھنا چاہتے ہیں کہ ہم کیسے کام کرتے ہیں تو ہماری خدمات دیکھیں۔

اس ہفتے کی مشق: ہر سسٹم کے لیے ایک فیصلہ

اپنے سسٹمز کی فہرست پر واپس جائیں اور ہر سسٹم کے لیے دو کالم شامل کریں: کیا اس کے اصول آپ کی کمپنی کے اپنے ہیں یا مشترک؟ اور مسئلہ کہاں ہے: اس جگہ میں جہاں وہ چلتا ہے یا خود سسٹم میں؟ پھر عارضی راستہ لکھیں:

سسٹماصول اپنے یا مشترک؟مسئلہ جگہ میں یا سسٹم میں؟عارضی راستہ
مثال: قیمتوں کا سسٹماپنےسسٹم میںکوڈ تبدیل کرنا یا دوبارہ بنانا
مثال: چھٹیوں کا انتظاممشترکسسٹم میںتیار پروڈکٹ سے بدلنا
مثال: پرانا آرکائیواستعمال نہیں ہوتاکوئی فرق نہیںڈیٹا آرکائیو کر کے ریٹائر کرنا

یہ وضاحتی مثالیں ہیں؛ آپ کا جدول مختلف ہوگا۔ اہم یہ ہے کہ ہر سسٹم کے راستے کی ایک تحریری وجہ ہو، جسے کوٹیشن مانگنے سے پہلے عمل کے ذمہ دار دیکھ لیں۔

آگے کیا ہے

آپ نے ہر سسٹم کے لیے ایک راستہ چن لیا ہے۔ پروجیکٹ کا سب سے پرخطر دن ابھی باقی ہے: منتقلی کا دن۔ حصہ 6 میں ہم بتائیں گے کہ AI کے لکھے یا تبدیل کیے گئے کوڈ کو دونوں سسٹمز کے نتائج کا انہی حقیقی لین دین پر موازنہ کر کے کیسے ٹیسٹ کریں، دونوں کو ایک مقررہ مدت تک ساتھ ساتھ کیسے چلائیں، اور کب آپ کو واپسی کے منصوبے کی ضرورت ہے۔

ذرائع