لماذا يتعثر الترحيل تقنيًا قبل أن يتعثر إداريًا؟
غالبًا ما يُقدَّم الترحيل إلى السحابة كمشروع واحد بخطة واحدة، لكنه في الواقع عشرات أو مئات القرارات الصغيرة، لكل تطبيق قصته وتبعياته وقيوده. تقدّر ماكنزي (2024) أن الشركات تنفق في المتوسط 14% أكثر من المخطط على الترحيل سنويًا بسبب عدم كفاءة العملية، وفق ما أورده تحليل منشور عن استراتيجيات الترحيل لدى Cloudtech. ومن هنا تأتي أهمية التمييز بين هذا المقال والمقالات التي تناولت الميزانية والمخاطر وتبنّي المؤسسة: نحن هنا ننزل إلى مستوى التطبيق والبيانات.
تتكرر الأسباب التقنية للتعثر في معظم المشاريع: تطبيقات لم يوثَّق ارتباطها بقواعد بيانات وخدمات أخرى، وبيانات تتغير أثناء النسخ فتفرض نافذة توقف أطول مما خُطط له، وتراخيص برمجية لا تعمل كما هي على بنية مشتركة، واختيار استراتيجية ترحيل واحدة لكل شيء. الحل المنهجي هو تصنيف كل تطبيق قبل تحريكه، وهذا ما يقدمه إطار الـ7Rs.
إطار 7Rs: قرار لكل تطبيق لا خطة واحدة للجميع
تصف إرشادات AWS الإرشادية للترحيلات الكبيرة سبع استراتيجيات. الإيقاف (Retire) لتطبيقات انتهت قيمتها، ومنها التطبيقات الخاملة أو التي لم تستقبل اتصالات منذ 90 يومًا أو أكثر. الإبقاء (Retain) لما يتعذر نقله الآن بسبب الامتثال أو التبعيات أو العتاد المتخصص. إعادة الاستضافة (Rehost) أي «الرفع والنقل» دون تغيير. النقل (Relocate) لتحريك الخوادم أو المثيلات بين البيئات دون إعادة كتابة. إعادة الشراء (Repurchase) أي استبدال التطبيق بمنتج جاهز غالبًا SaaS. إعادة المنصة (Replatform) أي تحسين محدود مثل نقل قاعدة بيانات إلى خدمة مُدارة. وإعادة البناء (Refactor) أي إعادة تصميم التطبيق ليستفيد من الخصائص السحابية الأصلية.
الأرقام تدعم الواقعية. تشير AWS إلى أن من المجدي غالبًا إعادة استضافة 70% أو أكثر من التطبيقات في ترحيلات الأنظمة القديمة الكبيرة، وتصف إعادة البناء بأنها الأعقد والأعلى كلفة وغير موصى بها للترحيلات الكبيرة إلا عند تعذر غيرها. وتذكر Mordor Intelligence، وفق ما نقلته Auvik، أن «الرفع والنقل» ما زال أكبر شريحة بنسبة 38.3% من الترحيلات، بينما تنمو استراتيجيات إعادة البناء بنحو 22.35% سنويًا. وللأمانة، هذه أرقام مزوّدين ومحللي سوق وليست قياسًا مستقلًا، فاستخدمها كاتجاه لا كقاعدة.
ما وراء الأرقام: أين تتعثر البيانات والتطبيقات فعلًا؟
في الترحيل العميق تظهر ثلاث نقاط احتكاك متكررة. الأولى خريطة التبعيات: لا يمكن تحديد استراتيجية تطبيق قبل معرفة ما يتصل به، فتبعية خفية واحدة قد تفصل التطبيق عن قاعدة بياناته بعد النقل وتضيف زمن استجابة غير متوقع. الثانية البيانات: النسخ الأولي ثم النسخ المتزامن للتغييرات ثم لحظة التحويل (Cutover) مراحل تحتاج اختبار تراجع (Rollback) مسبقًا، ويُفضّل تدريب الفريق على نافذة التحويل في بيئة تجريبية قبل الإنتاج. الثالثة التراخيص والإصدارات: بعض البرمجيات مرتبطة بعتاد أو نواة أو نظام تشغيل قديم، وهذه الحالات تقع عادة في خانتي الإبقاء أو إعادة الشراء.
وتفيد إرشادات AWS أيضًا بأن «إعادة المنصة» مثل نقل SQL Server إلى خدمة قاعدة بيانات مُدارة أو تحويل الأجهزة الافتراضية إلى حاويات تحسّن التكلفة والأداء دون إعادة بناء كاملة، لذا تكون غالبًا نقطة التوازن بين السرعة والقيمة. ومن الممارسات العملية: ترحيل موجات صغيرة تبدأ بتطبيقات منخفضة المخاطر، وقياس خط أساس للأداء قبل النقل لتقارن به بعده، وتوثيق قرار الـ7Rs لكل تطبيق في سجل واحد يراجعه الفريق.
السياق السعودي: توطين البيانات يحدد الاستراتيجية قبل التقنية
في المملكة قد تحسم قواعد التوطين الاستراتيجية قبل النقاش الفني. يوضح تحليل Morgan Lewis (مارس 2026) أن الجهات الحكومية يُشترط عمومًا بقاء بياناتها داخل المملكة مع استثناءات ضيقة يحددها النظام، وأن البنك المركزي السعودي يطلب موافقة مسبقة للاستضافة خارج المملكة، وأن مزوّدي الخدمة السحابية يسجّلون لدى هيئة الاتصالات والفضاء والتقنية ويُصنَّفون في فئات A وB وC تحدد أنواع البيانات والقطاعات التي يخدمونها. ويصف التحليل الإطار بأنه ما زال في طور النضج مع تداخل أنظمة دون توجيه منشور واضح في كل حالة.
عمليًا، أضف إلى سجل الـ7Rs عمودين: تصنيف البيانات، وموقع الاستضافة المسموح. فالتطبيق الذي يعالج بيانات مصنفة قد يكون مرشحًا للإبقاء أو للنقل إلى منطقة داخل المملكة فقط، بينما يصلح تطبيق منخفض الحساسية لإعادة الاستضافة بسرعة. وتذكّر Flexera بأن إدارة الإنفاق السحابي ما زالت التحدي الأول لدى 84% من المؤسسات، فاربط كل قرار بتقدير تكلفة ما بعد الترحيل. وأخيرًا، راجع مع جهتك المختصة متطلبات الهيئة الوطنية للأمن السيبراني وهيئة الاتصالات قبل اعتماد الخطة، فهذا المقال معلوماتي وليس استشارة قانونية.
