قد يواصل برنامج قديم أداء عمله اليومي رغم صعوبة تعديله. المشكلة تظهر عندما تقترح شركة التطوير إعادة بنائه كاملًا، بينما لا تستطيع شركتك إيقاف استقبال الطلبات حتى ينتهي المشروع. هنا تصبح طريقة الانتقال جزءًا مما تشتريه، مثلها مثل وظائف البرنامج الجديد.
الاستبدال المرحلي يستحق المناقشة عندما يمكن فصل وظائف محددة مع إبقاء العمل قائمًا. لكنه ليس قرارًا تلقائيًا لكل نظام؛ فقد تجعل الاعتمادات المتشابكة أو غياب الوصول اللازم الانتقال الجزئي أعقد من بديل آخر. اطلب تقييمًا يشرح سبب الاختيار قبل اعتماد جدول التنفيذ.
اختر وظيفة تستطيع إنهاء انتقالها
في مثال افتراضي، تدير شركة تأجير معدات طلبات الخدمة ببرنامج قديم. تريد استقبال الطلبات في واجهة جديدة، بينما يبقى توزيع الفنيين مؤقتًا في البرنامج السابق. أول مرحلة ليست «تطوير نصف النظام»، بل انتقال وظيفة محددة لها بداية ونهاية وأشخاص مسؤولون.
اسأل من يستقبل الطلب، وأين يحصل على رقمه، وأي نظام يعدل بياناته، وكيف يصل إلى موظف التوزيع. إذا احتاج الموظف نسخ كل طلب يدويًا، فاكتب حجم هذا العمل ومسؤوله وموعد إنهائه. لا تخفِ تكلفة التعايش داخل عبارة الربط بين النظامين.
ورقة انتقال من خمس خانات
| الخانة | ما تسجله مع المنفذ | سؤال القبول |
|---|---|---|
| الحدود | وظيفة واحدة ومستخدموها واعتماداتها. | هل نعرف ما الذي بقي في القديم؟ |
| مرجع البيانات | النظام المخول بكتابة كل نوع من السجلات. | كيف يُحسم اختلاف النسختين؟ |
| التجربة | مجموعة محدودة وحالات عادية واستثنائية. | ما الأدلة المطلوبة قبل التوسع؟ |
| التراجع | قرار الإيقاف ومعالجة ما كُتب بعد الانتقال. | هل يستمر العمل دون فقد طلبات جديدة؟ |
| الإغلاق | اعتمادات أزيلت وأرشيف ومسؤول موافقة. | هل بقي استخدام خفي للنظام السابق؟ |
املأ هذه الورقة لكل مرحلة، ولا تعتبرها مواصفة معمارية جاهزة. قد تكون نقطة البداية تقريرًا للقراءة فقط أو وظيفة مستقلة نسبيًا، وقد يتبين أن وظيفة أخرى لا تصلح للفصل بعد. المطلوب أن يرتبط الاختيار بتشغيلك الفعلي، لا بمجرد ترتيب الشاشات.
من يملك الكتابة أثناء التعايش؟
وجود سجل في نظامين لا يعني أن كليهما يجوز أن يعدله بالطريقة نفسها. في المثال، يمكن الاتفاق على إنشاء طلب الخدمة في الجديد، وإرسال نسخة لازمة للتوزيع إلى القديم، مع تحديد الجهة التي تغير الحالة. هذه سياسة مقترحة للمثال، وليست تصميمًا يصلح لكل مشروع.
تتناول إرشادات AWS للاستبدال التدريجي اعتماد الوظائف بعضها على بعض ومشكلات اتساق البيانات أثناء التعايش. ويشرح نمط Strangler Fig لدى Microsoft نقل وظائف تدريجيًا مع استمرار القديم. هذه مراجع لفهم المفاضلة؛ لا تفرض شراء سحابة معينة أو تحويل كل برنامج إلى خدمات صغيرة.
اطلب دليلًا قبل توسيع الاستخدام
اتفق على عينة تختبر إنشاء طلب وتعديله وإلغاءه وظهوره للجهة التالية. أضف حالة تأخر نقل البيانات وحالة فشل مؤقت، ثم حدد كيف يكتشف الموظف الاستثناء ومن يصححه. ظهور الطلب في شاشة جديدة وحده لا يثبت اكتمال انتقال العمل.
يمكن أن يشترط المشتري في تجربة افتراضية تتبع كل طلب من مجموعة محددة بين الاستقبال والتوزيع، مع تفسير أي اختلاف قبل التوسع. حجم العينة والمدة ومعايير النجاح تحتاج اتفاقًا يناسب حجم العمل؛ لا يقدم هذا المثال نسبة نجاح معيارية أو وعدًا بانتقال دون توقف.
التراجع يشمل البيانات التي أضيفت اليوم
اسأل سؤالًا مباشرًا: إذا رجعنا للبرنامج السابق بعد بدء استقبال الطلبات في الجديد، أين ستذهب الطلبات التي أضيفت خلال هذه الفترة؟ إعادة تشغيل النسخة القديمة لا تحل هذا السؤال وحدها. اطلب تجربة تراجع في بيئة مناسبة وسجلًا يوضح السجلات الجديدة وكيفية تسويتها.
يميّز هذا القرار خطة الانتقال عن مجرد اختبار استعادة نسخة احتياطية. الاستعادة تثبت مسار استرجاع متفقًا عليه، أما التراجع بين نظامين فيحتاج كذلك قواعد التعامل مع العمل الذي جرى بعد نقطة التحول. وقد توجد مرحلة يصبح الرجوع منها مكلفًا؛ يجب معرفتها قبل الموافقة.
لا تترك المرحلة المؤقتة بلا نهاية
اطلب قائمة بالاستخدامات المتبقية: تقارير، وتصدير، وربط خارجي، وحسابات موظفين، وقراءة تاريخية. حدد من يجيز إيقاف كل اعتماد، وكيف ستظل المعلومات المطلوبة متاحة. ثم افصل تكلفة الإبقاء المؤقت على النظام القديم عن بناء الجديد وصيانته.
إذا كنت ما زلت تقارن أصل القرار، راجع النظام الجاهز أم التطوير الخاص. وعند مناقشة تطوير البرمجيات مع نكست ويف، أرسل مثال وظيفة واحدة وورقة الانتقال بدل طلب عام لإعادة بناء كل شيء. بذلك يبدأ النقاش من مخرج يمكن استلامه وتقييمه.
مصادر وحدود الاستخدام
فُتح المرجعان في 3 نوفمبر 2026: Microsoft: الاستبدال التدريجي وAWS: نمط Strangler Fig. يسندان مبدأ التعايش ومخاطر الاعتمادات والبيانات؛ ورقة القبول والمثال اقتراحان تحريريّان وليسا نتيجة مشروع عميل.
