استلام برنامج بناه مزود آخر هو انتقال مسؤولية تشغيلية وتجارية وتقنية، لا مجرد تنزيل مستودع. يجب أن يبقى العملاء والموظفون قادرين على العمل، وأن تنتقل الحسابات والمعرفة والقرارات والأدلة، وأن يُفهم ما يملكه العميل فعلاً قبل أن يتعهد الفريق الجديد بتغيير أو موعد.
هذا الموضوع يختلف عن استلام تطبيق Laravel قديم. هنا التركيز على إدارة خروج المورد واستمرارية الخدمة والأصول والاتفاقيات مهما كانت التقنية. أما قائمة استلام تطبيق Laravel قديم فتدخل لاحقاً في فحص الإطار والكود وقاعدة البيانات والطوابير والترقيات.
عيّن قائداً للانتقال وحدد قواعد التواصل
اختر مالكاً من جهة العميل يملك القرار ويجمع الأسئلة ويوافق على الوصول. أنشئ سجل انتقال يحتوي الأصول والمالكين والحالة والموعد والمخاطر. تجنب طلبات متفرقة من الفريق الجديد إلى موظفي المورد القديم؛ قناة واحدة تقلل التناقض وتحافظ على علاقة مهنية.
اتفق على فترة تعاون ومواعيد جلسات وتسليمات مكتوبة وآلية للأسئلة بعد الجلسة. لا تبنِ الخطة على حسن النية وحده؛ اربطها بالعقد والحقوق والالتزامات. إذا كان هناك نزاع، استعن بمستشار قانوني ولا تطلب من المهندسين تفسير الملكية.
راجع العقد قبل الوصول
تحقق من ملكية الكود والتصميم والبيانات والنطاقات والحسابات، وتراخيص المكونات، وحقوق الاستخدام، وفترة الدعم، وبند الخروج، والدفعات أو الالتزامات المفتوحة. قد يمتلك العميل نسخة من الكود لكنه لا يملك حساب السحابة أو رخصة خط أو خدمة خارجية.
اكتب الفجوات كمسائل تحتاج حلاً، لا تفترض أن كلمة «ملكية كاملة» تغطي كل شيء. لا تنسخ مواد لا يملك العميل حقها. حدد مع المختص كيف تنتقل العقود أو تُستبدل، ومن يبلغ مزودي الطرف الثالث.
أنشئ جرد أصول مستقل
يشمل الجرد المستودعات والفروع والإصدارات، وخطوط CI/CD، وبيئات التطوير والاختبار والإنتاج، والسحابة وقواعد البيانات والتخزين، والنطاق وDNS، والبريد، والمتاجر، والتحليل، والمراقبة، وخدمات الدفع والرسائل، وشهادات TLS، ومفاتيح التوقيع.
لكل أصل سجل المالك القانوني ومالك الحساب والمسؤول التشغيلي وطريقة الاسترداد وتاريخ التجديد والتكلفة والاعتماديات. لا تضع السر نفسه في جدول الجرد؛ ضع مكانه وطريقة الوصول. اختبر أن العميل يستطيع استعادة الحساب من دون بريد شخصي لموظف سابق.
اجعل الإنتاج مستقراً قبل نقله
اطلب خطاً أساسياً: إصدار التطبيق، وحالة النشر، والحوادث المفتوحة، وسعة الموارد، والنسخ الاحتياطي، وآخر اختبار استعادة، والمهام المجدولة والطوابير، والتكاملات الحرجة. جمّد التغييرات غير الضرورية خلال نافذة الانتقال أو اجعل لها موافقة مشتركة.
لا تبدأ بإعادة هيكلة واسعة لإثبات قدرة الفريق الجديد. أول واجب هو فهم الخدمة ومراقبتها والقدرة على الرجوع. أي إصلاح عاجل يكون صغيراً وموثقاً وله اختبار وخطة تراجع. قس الفرق بين خطر معروف ودين تقني يمكن جدولته.
انقل الحسابات قبل تدوير الأسرار
أنشئ حسابات فردية للفريق الجديد بأقل صلاحية، وتأكد من أن العميل يملك الحساب الإداري ووسائل الاسترداد. بعد إثبات الوصول، خطط لتدوير كلمات المرور والمفاتيح والرموز والشهادات من دون قطع الخدمة. لا تلغِ حساب المورد قبل معرفة ما يعتمد عليه.
استخدم قائمة تشمل أسرار التطبيق وقاعدة البيانات والتكاملات والنشر والنسخ والمراقبة. لا ترسلها في وثيقة أو محادثة عامة. سجل من دوّر السر والوقت والخدمة التي أُعيد تشغيلها وكيف تحقق من النجاح.
اطلب نقل معرفة مبنياً على سيناريو
الجلسة المفيدة لا تستعرض بنية المجلد فقط. اطلب من المورد شرح مسار مستخدم حرج، وحادث سابق، ونشر إصدار، واستعادة نسخة، وتغيير إعداد، وتعطل طرف ثالث، وتصحيح بيانات مخول. سجل القرارات والحدود والأسئلة المفتوحة.
اطلب مخططات بسيطة لمكونات النظام وتدفق البيانات والتكاملات، ودليل تشغيل وقائمة مهام دورية. تحقق من الوثيقة بتنفيذ المهمة تحت إشراف، لأن نصاً قديماً قد لا يطابق الإنتاج. لا تسجل جلسة أو تشاركها قبل اتفاق واضح على الخصوصية.
افهم البيانات قبل أخذ نسخة
حدد قواعد البيانات والمخازن والمرفقات والنسخ والتحليلات، وتصنيف البيانات والاحتفاظ والتشفير والصلاحيات. اطلب مخططاً وتفسيراً للمعرفات والعمليات الحساسة. لا تنسخ إنتاجاً إلى جهاز مطور لمجرد الاستكشاف.
اختبر تصديراً واستعادة في بيئة محمية، وقارن أعداداً ومجاميع مناسبة. احتفظ بسجل سلسلة الحيازة للنسخ المستخدمة في الانتقال. يوضح دليل ملكية بيانات SaaS لماذا يجب إثبات قابلية التصدير قبل إغلاق العلاقة.
ارسم خريطة التكاملات والعقود
لكل تكامل، سجل المالك والوثائق والحساب والبيئة والحدود وعناوين callback والمفاتيح ومعدل الاستخدام وفشل حديث. تحقق من أن الطرف الخارجي يسمح بتغيير الجهة الفنية أو نقل الحساب. قد يحتاج عنوان IP أو شهادة أو توقيعاً إلى تحديث منسق.
نفذ اختباراً آمناً لكل مسار رئيسي في بيئة الاختبار أو بنافذة مراقبة. لا تطلق أحداثاً مالية حقيقية لمجرد التحقق. حدد مساراً يدوياً مؤقتاً عند تعطل التكامل، ومن يملك التصعيد لدى المزود.
افحص سلسلة الإمداد والرخص
أنشئ قائمة بالمكتبات والحزم والخدمات والصور والأصول والخطوط وأدوات البناء. تحقق من المصادر والتراخيص والإصدارات المقفلة والتنبيهات الأمنية. لا تفترض أن كل ملف في المستودع قابل للاستخدام التجاري أو أن الحساب المدفوع سينتقل تلقائياً.
راجع مفاتيح الحزم الخاصة والمستودعات الفرعية وسجلات الصور. خطط لاستبدال اعتماد لا يمكن نقله قبل انتهاء وصول المورد. لا تحدث كل المكتبات دفعة واحدة أثناء الانتقال؛ صنف الخطر ونفذ تغييرات قابلة للعكس.
ضع فترة مراقبة مزدوجة
اتفق على نافذة يكون فيها الفريق الجديد على الاستدعاء الأول مع إمكانية تصعيد محددة للمورد السابق. سجل الحوادث والأسئلة والإجابات في نظام العميل. اختبر التنبيهات فعلياً: من يستلمها، وما مستوى الخطورة، وكيف يصل إلى السجلات.
لا تطل الفترة بلا نهاية. ضع معايير خروج مثل نجاح نشر وتراجع، واستعادة نسخة، ومعالجة حادث تجريبي، وتوثيق التكاملات الحرجة، وتدوير الأسرار المتفق عليها. عندها تنتقل المسؤولية رسمياً.
قيّم النظام من دون حكم سريع
بعد استقرار الوصول، نفذ فحصاً محايداً للأمن والاعتمادية والاختبارات والأداء وقابلية الصيانة. صنف النتائج إلى حادث فوري، ومخاطرة قريبة، ودين مخطط، وتحسين اختياري. لا تصف كل قرار قديم بأنه خطأ؛ ربما كان مناسباً لقيود لم تعد معروفة.
اربط كل توصية بدليل وأثر وخيار وتكلفة تقريبية مبنية على اكتشاف. تجنب وعد إعادة كتابة تعالج كل شيء. كثير من الأنظمة تحتاج حدوداً أو اختبارات أو تحديثات مركزة قبل التفكير في استبدال كامل.
خطط للتواصل مع المستخدمين
إذا تغيرت جهة الدعم أو نافذة الصيانة أو سياسة الوصول، اكتب رسالة واضحة بلا لوم للمورد السابق. لا تعلن تغييراً تقنياً لا يؤثر في المستخدم. جهز الدعم بأسئلة شائعة ومراجع للحوادث، واحفظ قنوات الإبلاغ.
راقب مؤشرات الخدمة قبل الانتقال وبعده، مثل أخطاء المسارات الحرجة وتأخر الطوابير وفشل التكاملات، من دون ادعاء تحسن لا تدعمه البيانات. أي تراجع يفعّل خطة استجابة أو رجوع معروفة.
أغلق العلاقة بأثر مكتوب
راجع قائمة الأصول والتسليمات والأسئلة المفتوحة والوصول. اطلب من المورد تأكيد حذف النسخ أو سحب الحسابات حيث ينص العقد والسياسة، ولا تفترض قدرة على إثبات ما لم يُتفق عليه. احتفظ بمحضر قبول واستثناءات ومسؤوليات ما بعد الانتقال.
تتولى خدمة صيانة الأنظمة الانتقال عندما يكون المطلوب استمرار التشغيل، بينما يشرح دليل نقل نظام دون توقف نقل المستخدمين والبيانات إلى منصة أخرى. لا تخلط استلام النظام نفسه مع مشروع استبداله.
الخلاصة: أثبت القدرة على التشغيل قبل أول إعادة تصميم
نجاح الاستلام يظهر عندما يملك العميل الحسابات، ويستطيع الفريق نشر إصدار والتراجع واستعادة البيانات وتشخيص حادث والتواصل مع الأطراف، لا عندما يكتب تقريراً ينتقد الكود. اطلب تقييم انتقال بين مزودي البرمجيات مع قائمة الأصول والعقد المنقح ومسار مستخدم حرج، من دون إرسال أسرار أو بيانات إنتاج.
