داخل كل خطة ترحيل توجد وثيقة تسمى cutover runbook. عادةً 40 إلى 120 صفحة، تسرد الترتيب الذي تُبدَّل فيه الأنظمة خلال عطلة نهاية أسبوع واحدة، وخطوات التراجع لكل منها، وخطة الاتصال، والشمبانيا. في تجربتنا، الترحيلات التي تجري بشكل جيد هي تلك التي يُحذف فيها cutover runbook بهدوء من SharePoint قبل شهر من عطلة نهاية الأسبوع المفترضة، لأن الترحيل قد حدث بالفعل وحدة بعد أخرى ولم يبقَ شيء للتبديل.
أفضل الترحيلات مملة. تنطلق تدريجيًا، وحدة بعد أخرى، على مدى أسابيع. لا يحصل المستخدمون على مذكرة. يحصلون على رابط إلى URL جديد يفعل الشيء نفسه، فقط أسرع وفي متصفح.
لماذا يتفوق التدريجي على الانفجار الكبير
عمليات التبديل بالانفجار الكبير تضغط كل المخاطر في لحظة واحدة. قاعدة تحقق مفقودة، تنسيق بيانات غير متوقع، مشكلة تحميل تحت حركة مرور حقيقية — أي واحدة منها تؤثر على المؤسسة بأكملها في آن واحد. التراجع يعني العودة إلى Oracle Forms، مما يعني الاعتراف بفشل المشروع، مما يعني عواقب سياسية لا يريد أحد استيعابها.
الترحيل التدريجي يوزع المخاطر عبر الوقت. الوحدة 1 تُشحن إلى 20 مستخدمًا. يستخدمونها لأسبوعَين. تظهر المشاكل وتُصلَح. الوحدة 2 تُشحن. كرّر. بحلول الوقت الذي تُبدَّل فيه الوحدة الأخيرة، تصبح العملية روتينية ويكون الفريق مُعايَرًا.
في 2010 راقبت موزّعًا أوروبيًا يحاول تبديلًا كلاسيكيًا بالانفجار الكبير ليلة سبت. توقف نظام Forms القديم الساعة 10 مساءً، وصعد عميل Java الجديد الساعة 2 صباحًا، وبحلول الساعة 9 صباح الاثنين كان الرئيس التنفيذي في مكالمة يطالب بإعادة كل شيء لأن مُلتقطي المستودع لم يستطيعوا مسح الإيصالات. كان العيب الفعلي تافهًا — حقل باركود مُقتطَع عند 12 حرفًا بدلًا من 14 — لكن بحلول ذلك الوقت كانت الأضرار السياسية قد وقعت وفقد المشروع تسعة أشهر أخرى لـ “مرحلة استقرار” كانت في الحقيقة إعادة تخطيط. ذلك الاثنين صباحًا هو السبب في أنني أرفض عرض تبديل في عطلة نهاية أسبوع واحدة، أبدًا.
التشغيل المتوازي هو المتطلب المعماري
هذا النمط يعمل فقط إذا استطاع كلا النظامَين العمل في آن واحد. يجب على تطبيق Oracle Forms وتطبيق الويب الجديد التعايش مقابل قاعدة البيانات نفسها طوال مدة الترحيل.
يبدو معقدًا. إنه ليس كذلك، عندما تدعمه المعمارية. يقرأ النظام الجديد ويكتب عبر طبقة REST API. يقرأ النظام القديم ويكتب عبر وصول Oracle الأصلي. كلاهما يضربان الجداول نفسها. كلاهما يريان البيانات نفسها. يمكن لمستخدم إدخال فاتورة في Forms ورؤيتها فورًا في واجهة الويب الجديدة، أو العكس. تبقى قاعدة البيانات مصدر الحقيقة. الواجهة مجرد نافذة عليها.
كيف تبدو تجربة المستخدم الفعلية
التدحرج المثالي للمستخدم النهائي يجري هكذا:
- يصل بريد إلكتروني: “وحدة المقاولين الجديدة الخاصة بك جاهزة على app.company.com/contractors.”
- يفتحها. تبدو حديثة لكن مألوفة. البيانات نفسها هناك. الأزرار نفسها تفعل الأشياء نفسها.
- يُدخل بضعة سجلات. يتصرف التحقق بالطريقة نفسها. البحث أسرع. الأعمدة تُفرز. يعمل على جهاز لوحي.
- بعد أسبوع، نسي Oracle Forms تمامًا.
لا جلسات تدريب. لا دليل مستخدم من 50 صفحة. لا مبادرة إدارة تغيير. فقط أداة أفضل تتصرف بالطريقة نفسها التي كانت تتصرف بها الأداة القديمة. هذا هو الترحيل الذي لا يلاحظه أحد، وفي تجربتنا هو النوع الوحيد الذي ينجح فعلًا على نطاق المؤسسة.