ترحيل
السحابة

نجرد ما تشغّلونه، وبماذا يتصل، وما الذي سينكسر إذا انتقل: الخدمات والمهام المجدولة ورفع الملفات واستدعاءات الأطراف الثالثة والعناوين المكتوبة داخل الكود وسجلات DNS التي لا يتذكر أحد من أنشأها. المخرج خريطة اعتماديات وقائمة قصيرة وصريحة بالبنود التي ستجعل هذا الترحيل صعباً فعلاً.

نصمّم الوجهة: قاعدة بيانات مُدارة، واستضافة للتطبيق، وتخزين كائنات، ومهام خلفية. ثم نسعّرها مقابل فاتورتكم الحالية شاملةً البنود التي تُنسى عادةً مثل خروج البيانات والنسخ الاحتياطي ومدة حفظ السجلات وبيئات الاختبار. السحابة ليست أرخص تلقائياً، وإذا رجّح النموذج وضعكم الحالي فستحصلون على الأرقام لا على إجابة مبيعات.

خيار rehost هو الأسرع والأقل تغييراً، وreplatform يستبدل مكوّنات تديرونها بأنفسكم مثل خادم قاعدة البيانات بخدمات مُدارة، وrefactor يعيد تشكيل أجزاء من التطبيق لتناسب المنصة. نقرر لكل حمل عمل على حدة لا للمنظومة كلها، لأن إنفاق ميزانية إعادة هيكلة على أداة إدارية مستقرة هو الطريق المعتاد لتبديد ميزانية الترحيل.

ينتقل المخطط والبيانات إلى الوجهة عبر نصوص قابلة للتكرار، ونستخدم ترحيلات Prisma حين تسمح البنية بذلك، ونشغّل العملية كاملة على نسخة أولاً لقياس المدة الحقيقية للتحويل. تُكتب خطة التراجع ويُقاس زمنها وتُختبر قبل الاتفاق على أي موعد، فالخطة التي لم تُجرَّب ليست خطة.

نخفّض قيم TTL في DNS مسبقاً، ونصدر شهادات TLS على المنصة الجديدة ونتحقق منها، ونشغّل البيئتين بالتوازي حين يسمح نموذج البيانات، ثم ننقل الحركة ضمن نافذة محددة مع تجميد الكتابة للمدة الضرورية فقط. الجلسات وwebhooks والمهام المجدولة والبريد الصادر بنود في القائمة نفسها لا مفاجآت تُكتشف لاحقاً.

في الأسابيع الأولى نراقب معدلات الأخطاء وزمن الاستجابة واتصالات قاعدة البيانات والإنفاق، ثم نضبط الأحجام والتخزين المؤقت بعد أن تكشف الحركة الحقيقية احتياج الحمل. نستعيد من نسخة احتياطية فعلياً لإثبات صلاحيتها، ونسلّم أدلة تشغيل للنشر والتراجع والتعامل مع الأعطال.