المهندسون / الترحيل
المهندس الذي يحوّل إعادة كتابة تمتد 4 سنوات
إلى ترحيل من 3 أشهر
تفشل عمليات الترحيل حين لا يفهم القائد التقني كلاً من النظام القديم وإطار العمل المستهدف. يسدّ مهندس ترحيل DEX هذه الفجوة — فقد أنجز عشرات عمليات الترحيل عبر Oracle Forms وSAP وPeopleSoft. يعرف الأنماط والحالات الخاصة والاختصارات التي توفر أشهراً.
ماذا يفعل مهندس الترحيل
يقود التنفيذ التقني من التحليل إلى التحوّل. تمرّ كل قرارات — استراتيجية تحويل المخطط، وتوقيت التشغيل بالتوازي، ومنهج التحقق من منطق الأعمال — عبر مهندس الترحيل.
تحليل الكود القديم
تحليل عميق لملفات .fmb أو وحدات ABAP أو برامج PeopleCode. يُقابل كل نموذج ومحفز وعنصر LOV وقاعدة أعمال بمعمارية واصفات JSON لإطار العمل المستهدف.
تهيئة محرك الترحيل
يُهيّئ معاملات محرك الترحيل الآلي — قواعد التحويل، واصطلاحات التسمية، وتطابقات أنواع البيانات، وأنماط ترجمة منطق الأعمال الخاصة بقاعدة الكود لديكم.
تنسيق تحويل المخطط
يعمل مع مدراء قواعد البيانات لديكم لتحويل مخططات قاعدة البيانات، وترحيل الإجراءات المخزّنة، وضمان سلامة المراجع. ويتعامل مع الفروق بين Oracle وSQL Server وPostgreSQL وقواعد البيانات السحابية الأصلية.
تكافؤ منطق الأعمال
يتحقق من أن كل قاعدة أعمال وكل حساب وكل سير عمل في النظام القديم ينتج نتائج متطابقة في النظام الجديد. اختبارات انحدار آلية في كل خطوة — لا في النهاية فقط.
لماذا تفشل عمليات الترحيل من دونه
يفشل الترحيل المؤسسي النموذجي لأحد ثلاثة أسباب: يقلّل الفريق من تعقيد منطق الأعمال القديم، أو لا تأخذ خطة التحوّل التشغيل بالتوازي بالحسبان، أو يفقد المشروع زخمه حين تتراكم الحالات الخاصة. لقد شاهد مهندس الترحيل أنماط الفشل الثلاثة — عبر عشرات التعاقدات — ويعرف كيف يمنعها.
النمط الذي نراه: تبدأ المؤسسة "إعادة كتابة" بفريق تطوير عام الغرض. بعد 18 شهراً، يكون الفريق قد أعاد بناء 30% من النظام، ويكتشف أن الـ70% المتبقية تحوي منطق الأعمال الذي يهم فعلاً. يتعثّر المشروع. يتجنّب مهندس الترحيل ذلك ببدء تحليل منطق الأعمال — بتحديد التعقيد قبل كتابة سطر كود واحد.
كيف يضغط الجداول الزمنية
تأتي السرعة من التعرف على الأنماط. مهندس ترحيل حوّل 500 من Oracle Forms يعرف أن نمط محفز محدداً يُقابل تهيئة واصف JSON محددة. لا يُصحّح الأخطاء — بل يتعرّف ويُطبّق. يتعامل محرك الترحيل الآلي مع 60 إلى 80% من التحويل. ويتولى المهندس الـ20 إلى 40% التي تتطلب حكماً بشرياً.
من الشاشات تُحوَّل آلياً بواسطة محرك الترحيل وفق معاملات يهيّئها المهندس.
تتطلب تدخلاً يدوياً من المهندس — منطق أعمال معقّد، محفزات مخصَّصة، حالات خاصة.
جدول ترحيل نموذجي لتطبيق قديم بـ 200 إلى 500 شاشة مع مهندس ترحيل مخصّص.
تكافؤ منطق الأعمال مُتحقَّق منه عبر اختبارات انحدار آلية عند كل معلم.
نموذج التعاقد
يُستأجر مهندسو الترحيل عادةً بدوام كامل طوال فترة الترحيل — شهر إلى ثلاثة أشهر حسب تعقيد النظام. وبعد اكتمال الترحيل، إما أن ينتقلوا إلى دور صيانة، أو يسلّموا إلى مهندس أمن أو ابتكار، أو يُدرّبوا فريقكم الداخلي على إدارة النظام باستقلالية.
مهندس مدمج بدوام كامل
يقود مهندس ترحيل باسم معيّن التنفيذ التقني منذ اليوم الأول. يعمل داخل مؤسستكم، وينسّق مع مدراء قواعد البيانات ومحللي الأعمال، ويتملّك الجدول الزمني للترحيل.
- تحليل كامل لقاعدة الكود القديمة وخطة الترحيل خلال الأسبوع الأول
- تقارير تقدم يومية مع تتبّع التحويل على مستوى الشاشة
- تنسيق التشغيل بالتوازي — النظامان القديم والجديد جنباً إلى جنب
- التحقق من تكافؤ منطق الأعمال عند كل معلم
- تخطيط التحوّل وتنفيذه مع إجراءات تراجع
التسليم والانتقال
بعد اكتمال الترحيل، يوثّق المهندس معمارية النظام، ويدرّب فريقكم على إطار العمل، ويُحيل المسؤوليات. يصبح معظم الفرق مكتفياً ذاتياً خلال أسبوعين إلى أربعة أسابيع من اكتمال الترحيل.
- توثيق كامل للنظام ومخططات معمارية
- تدريب الفريق على إطار عمل DEX ومنشئ الذكاء الاصطناعي
- الانتقال إلى مهندس أمن أو ابتكار إذا لزم دعم مستمر
- دعم ما بعد الترحيل لمدة 30 يوماً للحالات الخاصة والاستقرار
أسئلة شائعة
ما الأنظمة القديمة التي عمل عليها مهندس الترحيل؟
Oracle Forms (جميع الإصدارات من 6i إلى 12c)، ووحدات SAP GUI/ABAP، وPeopleSoft PeopleTools، وOracle APEX. يغطي محرك الترحيل وخبرة المهندس أكثر الحزم القديمة المؤسسية شيوعاً. إذا لم يكن نظامكم مدرجاً، يحدّد التقييم جدوى العمل عليه.
كيف تتعاملون مع الإجراءات المخزّنة ومنطق الأعمال على مستوى قاعدة البيانات؟
يعمل مهندس الترحيل مع مدراء قواعد البيانات لديكم لفهرسة كل إجراء مخزّن وحزمة ومحفز. يُرحَّل المنطق الذي ينبغي نقله إلى طبقة التطبيق. والمنطق الذي يجب أن يبقى في قاعدة البيانات يُحوَّل إلى صياغة قاعدة البيانات المستهدفة. لا شيء يُفقد — كل شيء يُقابَل.
ماذا لو استغرق الترحيل أكثر من المقدَّر؟
تعتمد التقديرات على تحليل الكود القديم الأولي الذي يحدد التعقيد قبل بدء الترحيل. الزيادة في النطاق هي الخطر الرئيسي — يديرها المهندس بتجميد النطاق القديم وقت التحليل وتتبع أي متطلبات جديدة على حدة. عملياً، يكتمل معظم عمليات الترحيل ضمن النافذة المُقدَّرة.
هل يمكننا إبقاء النظام القديم عاملاً أثناء الترحيل؟
نعم — التشغيل بالتوازي هو النهج القياسي. يواصل النظام القديم العمل بينما يُبنى الجديد ويُتحقَّق منه إلى جانبه. لا يقع التحوّل إلا بعد تأكيد تكافؤ منطق الأعمال. ويمكن ترحيل المستخدمين بمراحل — قسماً تلو الآخر — لتقليل المخاطر.
ما الذي يسلّمه مهندس الترحيل عند اكتمال المشروع؟
معمارية نظام موثّقة بالكامل، وفريق داخلي مُدرَّب (أو الانتقال إلى مهندس أمن أو ابتكار مدمج)، و30 يوماً من الدعم بعد الترحيل، ونظام جاهز للتوسعة المستمرة عبر منشئ الذكاء الاصطناعي.
توقفوا عن إعادة الكتابة. ابدؤوا الترحيل.
يستطيع مهندس ترحيل إكمال تحليل نظامكم القديم خلال الأسبوع الأول. ثم يتبع الترحيل الكامل جدولاً زمنياً قابلاً للتنبؤ يعتمد على المعالم.