اگر آپ پرانے سسٹم کو اس وقت تک بند نہ کریں جب تک نیا سسٹم خود کو ثابت نہ کر دے تو کام روکے بغیر منتقل ہو سکتے ہیں: دونوں کو ایک ہی حقیقی لین دین پر چلا کر نتائج کا موازنہ کریں، عمل کے ذمہ داروں کی بتائی ہوئی نایاب صورتوں کو جانچیں، ہر ماڈیول کو چالو کرنے سے پہلے انسانی منظوری لازمی کریں، اور پرانے سسٹم کو واپسی کے لیے تیار رکھیں۔ Microsoft اپنی منتقلی پر عمل درآمد کی گائیڈ میں منتقلی کے بعد پہلے 24 سے 48 گھنٹوں تک نئے سسٹم کی نگرانی کرنے اور استحکام کی مدت میں پرانے ماحول کو واپسی کے متبادل کے طور پر رکھنے کا مشورہ دیتا ہے۔

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

AI کے تبدیل کیے گئے کوڈ کو مختلف جانچ کیوں چاہیے

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

کوڈ کو دوبارہ لکھنے والا ہر مرحلہ کوئی چھوٹی سی بات بدل سکتا ہے۔ اس لیے یہ کافی نہیں کہ کوئی ڈویلپر نیا کوڈ پڑھ کر کہہ دے کہ یہ درست لگتا ہے۔ انتظامیہ کا ایک ہی سوال ہے: کیا اسی ڈیٹا پر نیا سسٹم وہی نتیجہ دیتا ہے جو پرانا دیتا ہے؟ اس کا جواب نتائج کے موازنے سے ملتا ہے، کوڈ پڑھنے سے نہیں۔

ایک ہی حقیقی لین دین پر نتائج کا موازنہ کریں

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

  • حتمی اعداد: مدت کے آخر میں انوائسز کا کل، بیلنس اور اسٹاک۔
  • رپورٹیں: وہ ماہانہ رپورٹیں جن پر انتظامیہ انحصار کرتی ہے، سطر بہ سطر۔
  • دوسرے سسٹمز کو جانے والی چیزیں: بینک، اکاؤنٹنگ یا سرکاری پورٹلز کو بھیجی جانے والی فائلیں اور پیغامات۔
  • مستردگیاں اور غلطیاں: جس لین دین کو پرانا سسٹم مسترد کرتا ہے، نیا سسٹم بھی اسی وجہ سے اسے مسترد کرے۔

کچھ ٹولز تیاری میں مدد دیتے ہیں، فیصلہ نہیں کرتے۔ مثال کے طور پر مین فریم کے لیے AWS Transform کوڈ کی خصوصیات، کاموں کی پیچیدگی اور شیڈولر کے راستوں سے 3 مراحل (ترتیب، دائرہ کار کا تعین اور جائزہ) میں ٹیسٹ کا منصوبہ بناتا ہے، پھر مین فریم سے ٹیسٹ ڈیٹا جمع کرنے والی اسکرپٹس 4 مراحل میں تیار کرتا ہے۔ لیکن Amazon اسی گائیڈ میں خبردار کرتا ہے کہ یہ اسکرپٹس آپ کے اپنے مین فریم پر اور آپ کی ٹیم کی اجازتوں کے ساتھ چلانی ہوں گی۔ ٹول تیاری کرتا ہے؛ چلانا اور فیصلہ کرنا آپ کی ٹیم کا کام ہے۔ ڈیٹا کی جانچ کے لیے Microsoft تجویز کرتا ہے کہ فوری جانچ کے لیے قطاروں کی گنتی اور گہری جانچ کے لیے چیک سم کا موازنہ کریں: چیک سم ڈیٹا سے نکالا گیا ایک عدد ہے جو ایک حرف بدلنے پر بھی بدل جاتا ہے۔

نایاب صورتیں: ان سے پوچھیں جو انہیں جانتے ہیں

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

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

ہر ماڈیول پر انسانی منظوری

اس اصول کی سب سے واضح شائع شدہ مثال بینکاری سسٹمز کی منتقلی کا وہ عمل ہے جس کا اعلان Thought Machine نے Amazon کے ساتھ 29 ستمبر 2026 کو کیا۔ اس کے 4 مراحل ہیں: AWS Transform کے ذریعے پرانی ایپلی کیشنز سے کاروباری منطق نکالنا، دہرائی گئی شکلوں کو یکساں تفصیلات میں یکجا کرنا، AI ایجنٹس کے ذریعے نئی مالیاتی مصنوعات اور ان کے ٹیسٹ بنانا، اور ایک توثیقی مرحلہ جو کچھ بھی قبول کرنے سے پہلے بینک کی انجینئرنگ اور رسک ٹیموں کو منظوری کا واضح اختیار دیتا ہے۔ منظوری کے بعد بھی نتیجہ براہ راست چالو نہیں ہوتا بلکہ مزید جائزے کے لیے ایک الگ تھلگ سینڈ باکس ماحول میں جاتا ہے۔

آپ کی کمپنی کے لیے یہ سبق نہ بینک مانگتا ہے نہ Amazon: سسٹم کا ہر ماڈیول، جیسے بلنگ، پے رول یا انوینٹری، چالو ہونے سے پہلے دو دستخط حاصل کرتا ہے۔ ایک تکنیکی، جو تصدیق کرے کہ تمام ٹیسٹ چلائے گئے، اور ایک عمل کے ذمہ دار کا، جو تصدیق کرے کہ نتائج کاروباری لحاظ سے درست ہیں۔ Microsoft منتقلی کے بعد یہی مانگتا ہے: ایپلی کیشن کے ذمہ دار تصدیق کریں کہ تمام بڑے کام درست چل رہے ہیں۔

متوازی چلانا اور واپسی کا منصوبہ

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

مرحلہآپ کیا کرتے ہیںماخذ
منتقلی سے پہلےتمام سپورٹ ٹیموں کے ساتھ اجلاس جس میں منتقلی کے منصوبے، تصدیقی طریقہ کار اور واپسی کی شرائط کا جائزہ ہو، اور منتقلی کی مدت میں پرانے سسٹم پر ہر تبدیلی پر پابندیMicrosoft
منتقلی کا دنکم ٹریفک کے وقت آخری ہم آہنگی کے دوران پرانے سسٹم میں ڈیٹا کا اندراج روکنا، سب کو وقت سے آگاہ کرنا، اور صارفین کو منتقل کرنے سے پہلے ڈیٹا کی تصدیق کرناMicrosoft
منتقلی کے بعدبنیادی عمل کی شروع سے آخر تک جانچ، پہلے 24 سے 48 گھنٹوں تک کارکردگی اور غلطیوں کی نگرانی، اور پرانے سسٹم کو واپسی کے لیے تیار رکھناMicrosoft

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

Origami کا نقطۂ نظر

ہم منتقلی کو تکنیکی واقعہ نہیں بلکہ انتظامی فیصلہ سمجھتے ہیں۔ اسی لیے ہم نیا سسٹم بنانے سے پہلے دونوں سسٹمز کے موازنے کا انتظام بناتے ہیں، اور عمل کے ذمہ داروں کے ساتھ نایاب صورتوں اور ان کے متوقع نتائج پر جلد اتفاق کر لیتے ہیں، تاکہ کامیابی کی تعریف کسی کے نتائج دیکھنے سے پہلے لکھی جا چکی ہو۔

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

اس ہفتے کی مشق: ہر ماڈیول کے لیے منتقلی کی شیٹ

حصہ 5 میں جس بھی سسٹم کو آپ نے تبدیل کرنے یا دوبارہ بنانے کے لیے چنا، اس کے لیے منتقلی کی کوئی بھی تاریخ طے کرنے سے پہلے عمل کے ذمہ داروں کے ساتھ یہ شیٹ بھریں:

ماڈیولموازنے کی مدتنایاب صورتیںدستخط کون کرے گاواپسی کی شرط
مثال: بلنگایک بند مہینہجزوی واپسی، منسوخ انوائسفنانس مینیجر اور تکنیکی سربراہانوائسز کے کل میں کوئی بھی فرق
مثال: پے رولتنخواہ کا ایک مکمل چکرمہینے کے وسط میں شمولیتHR مینیجر اور تکنیکی سربراہکسی خالص تنخواہ میں کوئی بھی فرق

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

آگے کیا ہے

ایک سوال باقی ہے جو ہر مینیجر اپنا کوڈ اور ڈیٹا کسی AI ٹول کو بھیجنے سے پہلے پوچھتا ہے: جدید کاری کے دوران میرا ڈیٹا کہاں جاتا ہے؟ حصہ 7، جو آخری حصہ ہے، اس کا جواب دیتا ہے اور پوری سیریز کی مشقوں کو 90 دن کے منصوبے میں جمع کرتا ہے۔

ماخذ