إن نقل تنفيذ قديم لأودو إلى أودو 20 ليس مجرد الترقية المعتادة مع رقم إصدار أكبر.
فكلما زاد عدد الإصدارات الفاصلة بين النظام المصدر وأودو 20، زاد احتمال أن يتضمن المشروع شيفرة مخصصة متراكمة، وحلولاً التفافية متقادمة، ووحدات قديمة من جهات خارجية، وديوناً تقنية في التكاملات، وإعدادات لم تعد صالحة، وعمليات أعمال تغيّرت منذ تنفيذ نظام ERP لأول مرة.
لذلك فالخطوة الأولى الصحيحة ليست تقدير ساعات الترحيل.
بل هي تحديد حقيقة النظام الحالي.
ملاحظة حول تواريخ الدعم: لا تنشر موعداً ثابتاً لانتهاء الدعم أو الاستضافة منقولاً من مقال مدونة قديم، فالجداول الزمنية للدعم والاستضافة في أودو قد تتغير. تحقّق من سياسة الدعم والاستضافة الرسمية الحالية في أودو للإصدار المصدر مباشرة قبل النشر.
لماذا تختلف ترقية الإصدارات القديمة؟
قد تنطوي ترقية إصدار حديث على فارق ضيق نسبياً في إطار العمل.
أما التنفيذ القديم فقد يحتوي على سنوات من:
- الوحدات المخصصة؛
- تخصيصات Studio؛
- الواجهات الموروثة؛
- التقارير المخصصة؛
- الإجراءات المجدولة وإجراءات الخادم؛
- تكاملات API؛
- سلوك المحاسبة والتوطين؛
- حلول التفافية للبيانات؛
- ميزات مهجورة؛
- عمليات يدوية بُنيت للتغلب على قيود النظام.
وترحيل كل ذلك دون مساءلته قد يعيد إنتاج سنوات من الديون التقنية على إصدار جديد.
المرحلة 1 — اكتشف النظام الفعلي
أنشئ جرداً للترقية.
الإصدار والاستضافة
- إصدار أودو المصدر؛
- Community/Enterprise؛
- Odoo Online/Odoo.sh/استضافة محلية؛
- البنية التحتية؛
- حجم قاعدة البيانات؛
- حجم مخزن الملفات (filestore).
التخصيصات
- مستودعات الإضافات المخصصة؛
- وحدات الجهات الخارجية؛
- Studio؛
- الواجهات المخصصة؛
- التقارير؛
- الأتمتة؛
- قواعد الأمان.
التكاملات
- تطبيقات الجوال؛
- البوابات؛
- الدفع؛
- الشحن؛
- الأسواق الإلكترونية؛
- الحضور؛
- ذكاء الأعمال (BI)؛
- المحاسبة/الخدمات المصرفية؛
- البرمجيات الوسيطة؛
- واجهات API.
عمليات الأعمال
قابل المستخدمين الفعليين.
فالوثائق المكتوبة قبل سنوات قد لا تعكس طريقة استخدام النظام اليوم.
المرحلة 2 — صنّف كل تخصيص
استخدم أربع فئات:
الإبقاء
لا يزال مطلوباً ويستحق الصيانة.
الاستبدال بأودو 20 القياسي
أصبح الإصدار المستهدف يلبي المتطلب بشكل أصلي.
إعادة التصميم
لا يزال المتطلب قائماً، لكن التنفيذ التقني القديم لم يعد مناسباً.
الإيقاف
غير مستخدم أو متقادم.
وقد يخفض هذا التصنيف تكلفة الترقية أكثر من أي اختصار في ترحيل الشيفرة.
المرحلة 3 — حدّد النقاط الساخنة الناتجة عن فجوة الإصدارات
في القفزات الكبيرة بين الإصدارات، راجع التغييرات التراكمية في:
- ORM؛
- الواجهات؛
- JavaScript/Owl؛
- نقاط البيع (POS)؛
- الموقع الإلكتروني؛
- التقارير؛
- المحاسبة؛
- المخزون/التصنيع (MRP)؛
- طبقة API والتكامل؛
- الأمان؛
- الترجمات.
لا تفترض أن ترحيل وحدة ما ممكن بإصلاح الفرق الأول فقط بين إصدار وآخر.
فالهدف هو سلوك أودو 20.
المرحلة 4 — راجع التكاملات قبل الترقية التجريبية
تستحق التكاملات القديمة اهتماماً خاصاً لأن اعتمادياتها قد تكون متقادمة.
فعلى سبيل المثال، تنص وثائق أودو الحالية على أن واجهات RPC الخارجية القديمة متقادمة، وأن خدمة db أُزيلت في أودو 20، وأن من المقرر حالياً إزالة common/object في أودو 22.
وقد تحتوي منظومة التكاملات القديمة أيضاً على:
- مكتبات عملاء غير مدعومة؛
- كلمات مرور مضمّنة في الشيفرة؛
- مستخدمين بصلاحيات المدير؛
- افتراضات متقادمة بشأن TLS والشبكة؛
- سكربتات cron غير موثقة.
تعامل مع تحديث التكاملات بوصفه مسار عمل مستقلاً.
المرحلة 5 — اطلب ترقية تجريبية
اتبع العملية الرسمية الحالية في أودو الخاصة بالإصدار المصدر ونموذج الاستضافة.
لا تفترض أن المسار متاح لمجرد أن أودو 20 نفسه قد صدر.
بمجرد توفر قاعدة البيانات التجريبية:
- راجع تقرير الترقية (Upgrade Report)؛
- افحص الواجهات المعطّلة؛
- انشر الشيفرة المخصصة للإصدار المستهدف أو رحّلها؛
- تعامل مع مخزن الملفات حيثما ينطبق ذلك؛
- ابدأ اختبار الأعمال.
المرحلة 6 — ضع خطة اختبار قائمة على المخاطر
رتّب أولويات مسارات العمل بحسب أثرها على الأعمال.
المستوى 1 — ما يوقف الأعمال
أمثلة:
- الفوترة/المحاسبة؛
- المبيعات/تنفيذ الطلبات؛
- المستودع؛
- التصنيع؛
- نقاط البيع؛
- الرواتب؛
- واجهات API الخارجية الحرجة.
المستوى 2 — أثر تشغيلي كبير
أمثلة:
- أتمتة إدارة علاقات العملاء (CRM)؛
- الموافقات؛
- الخدمات الميدانية؛
- المشتريات؛
- التقارير؛
- بوابة العملاء.
المستوى 3 — أثر أقل
أمثلة:
- تغييرات شكلية في الواجهات؛
- تقارير تهدف إلى التسهيل؛
- أتمتة غير حرجة.
ينبغي أن يتبع عمق الاختبار حجم الأثر، لا عدد الوحدات.
المرحلة 7 — طابق البيانات
في الأنظمة القديمة، خذ عينات من السجلات عبر فترات زمنية مختلفة.
تحقّق من:
- السجلات التاريخية القديمة جداً؛
- السجلات المفتوحة حالياً؛
- السجلات المؤرشفة؛
- بيانات الشركات المتعددة؛
- الحقول المخصصة المُرحّلة؛
- المرفقات؛
- الأرصدة المحاسبية؛
- المخزون/التقييم؛
- الضرائب؛
- المستخدمين/الأمان.
فالبيانات التاريخية كثيراً ما تكشف مشكلات ترحيل لا تكشفها سجلات الاختبار الجديدة.
المرحلة 8 — حدّد التغييرات التي يحتاج المستخدمون إلى تعلّمها
قد تغيّر الترقية عبر عدة إصدارات مسارات العمل تغييراً كبيراً حتى عندما تكون الشيفرة المخصصة محدودة.
خطّط لما يلي:
- ملاحظات إصدار بحسب الأدوار؛
- تدريب قصير؛
- تحديث إجراءات التشغيل القياسية (SOPs)؛
- لقطات شاشة؛
- اعتماد المديرين؛
- رعاية مكثفة ودعم بعد الإطلاق.
لا ينبغي الخلط بين نطاق الترقية التقنية القياسية في أودو وبين تدريب المستخدمين وإدارة التغيير.
المرحلة 9 — أجرِ تجربة على نسخة حديثة من الإنتاج
قد ينحرف مشروع الترحيل الطويل عن مساره.
قبل الإنتاج:
- اطلب ترقية تجريبية حديثة أو أنشئها؛
- انشر الشيفرة النهائية للإصدار المستهدف؛
- شغّل سكربتات الترحيل؛
- شغّل الاختبارات الآلية؛
- شغّل اختبار قبول المستخدم (UAT) للمسارات الحرجة؛
- قِس زمن الانتقال إلى الإنتاج؛
- وثّق الخطوات اليدوية؛
- تحقّق من التكاملات.
لا تقدّر زمن توقف الإنتاج بناءً على محاولة الترحيل الأولى.
تقييم عملي للتعقيد
بدلاً من وصف المشروع بأنه "سهل/متوسط/صعب" استناداً إلى حجم قاعدة البيانات وحده، قيّم عوامل موضوعية:
| العامل | الأسئلة |
|---|---|
| فجوة الإصدارات | كم عدد الإصدارات الرئيسية؟ |
| الوحدات المخصصة | كم عددها، وما مدى تدخّلها في النظام؟ |
| إعادة تعريف النواة | هل تغيّر المحاسبة/المخزون/التصنيع/الموارد البشرية؟ |
| تطبيقات الجهات الخارجية | هل تُصان إصداراتها المستهدفة؟ |
| التكاملات | كم عدد الأنظمة الخارجية التي تكتب أو تقرأ؟ |
| البيانات | الحجم والعمر والجودة والمرفقات؟ |
| الشركات المتعددة | منتجات وعملات مشتركة، وتدفقات بين الشركات؟ |
| الموقع الإلكتروني/نقاط البيع | مسارات عمل عامة أو ميدانية حرجة للإيرادات؟ |
| الاختبار | هل أصحاب الأعمال متاحون؟ |
| التوثيق | هل السلوك الحالي موثّق؟ |
ينتج عن ذلك تقدير أفضل بكثير من "X درهم لكل وحدة" أو "أسبوعين لكل إصدار".
الأخطاء الشائعة
- ترحيل كل تخصيص قديم.
- افتراض أن حجم قاعدة البيانات يساوي التعقيد.
- تجاهل التكاملات غير الموثقة.
- الجمع بين نقل الاستضافة وتغيير النسخة وإعادة التصميم وترقية الإصدار دون سبب.
- اختبار السجلات الحديثة فقط.
- الاستهانة بتغيير مسارات عمل المستخدمين.
- تثبيت تواريخ الدعم نقلاً عن مصادر قديمة.
- تحديد موعد للإطلاق قبل أول ترقية تجريبية واقعية.
حالة الدعم مقابل قابلية الترقية
لا تخلط بين إصدار غير مدعوم وترقية مستحيلة.
فوثائق أودو التاريخية الخاصة بالإصدارات المدعومة تنص صراحةً على أن الإصدارات الأقدم غير المدعومة لا تزال قابلة للترقية. وفي أي مشروع حالي، تحقّق من حالة الدعم الدقيقة للإصدار المصدر ومن توفر أودو 20 بوصفه إصدارًا مستهدفًا قبل الالتزام بأي موعد.
هل تحتاج إلى الترقية عبر كل إصدار وسيط؟
بالنسبة لقاعدة البيانات القياسية، استخدم خدمة الترقية أو مسار الترقية المدعوم حاليًا من أودو لقاعدة البيانات المصدر، بدلًا من افتراض أن كل إصدار وسيط يجب أن يصبح عملية نشر منفصلة في بيئة الإنتاج.
أما الشيفرة المخصصة فأمرها مختلف: إذ لا يزال على المطورين مراعاة التغييرات المتراكمة في إطار العمل والتطبيقات بين التنفيذ القديم وأودو 20.
افصل بين ثلاث طبقات:
- ترقية قاعدة البيانات القياسية؛
- ترحيل الشيفرة والبيانات المخصصة؛
- قبول العمليات التجارية.
حوّل الاكتشاف إلى نطاق ترقية حقيقي
بعد الجرد، أعدّ أربعة مخرجات:
1. خريطة التطبيقات
كل وحدة قياسية أو مخصصة أو من جهة خارجية، وهل ستبقى أم لا.
2. خريطة التكاملات
كل نظام خارجي، ومسؤوله، وبروتوكوله، ونموذج بيانات الاعتماد فيه، وخطة اختباره.
3. خريطة عمليات الأعمال
المسارات الحرجة لكل قسم، والأشخاص الذين سيعتمدونها.
4. قائمة أعمال الترحيل
كل مهمة في الشيفرة أو البيانات أو الإعدادات يتطلبها الوصول إلى أودو 20.
وعند هذه النقطة يصبح التقدير قابلاً للدفاع عنه.
قرّر هل تجمع أعمال التحديث معاً
كثيراً ما يكشف مشروع الإصدار القديم عن تغييرات أخرى مرغوبة:
- نقل الاستضافة؛
- الانتقال من Community إلى Enterprise؛
- تغييرات دليل الحسابات أو التوطين؛
- إعادة هيكلة الشركات؛
- إعادة تصميم الموقع الإلكتروني؛
- تحديث واجهات API؛
- تنظيف البيانات.
قد يقلّل جمع كل شيء معاً من تكرار الجهد، لكنه يضاعف أيضاً المتغيرات أثناء الاختبار.
وثمة قاعدة مفيدة:
اجمع التغييرات حين تكون مترابطة تقنياً، وافصلها حين يقلّل التراجع والاختبار المستقلان من المخاطر.
فعلى سبيل المثال، قد ينتمي ترحيل API تفرضه متطلبات التوافق مع الإصدار المستهدف إلى الترقية نفسها. أما إعادة بناء هوية الموقع الإلكتروني بالكامل فلا تحتاج عادةً إلى مشاركة موعد الانتقال إلى الإنتاج نفسه.
تنظيف البيانات: قبل الترقية أم بعدها؟
لا تنظّف تلقائياً كل مشكلة تاريخية قبل الترقية.
صنّف مشكلات البيانات:
- ما يعيق الترقية القياسية؛
- ما يعطّل منطق الأعمال في الإصدار المستهدف؛
- ما ينشئ مخاطر قانونية أو محاسبية؛
- ما هو شكلي أو منخفض الأثر.
عالج المعيقات ومشكلات الصحة عن قصد. أما مشاريع التنظيف الاختيارية الكبيرة فيمكن غالباً فصلها كي لا تؤخر ترقية الإصدار.
أنشئ بوابة قرار للمضي أو التوقف
قبل الإنتاج، اشترط وجود أدلة على ما يلي:
- اكتمال الترقية التجريبية؛
- نجاح الوحدات المخصصة المطلوبة؛
- نجاح التكاملات الحرجة؛
- نجاح مطابقة الأرصدة المالية والمخزون؛
- اعتماد أصحاب مسارات المستوى 1 لها؛
- إجراء تجربة على خطوات الإنتاج؛
- ملاءمة زمن التوقف المقاس للنافذة المتفق عليها؛
- جاهزية فريق الدعم والدعم المكثف بعد الإطلاق (hypercare).
وإذا كان أحد مسارات المستوى 1 بلا مسؤول أو بلا نتيجة اختبار، فالمشروع ليس جاهزاً لمجرد أن المطورين يقولون إن قاعدة البيانات تعمل.
الدعم المكثف بعد الترقية
في القفزات الكبيرة بين الإصدارات، خطّط للأيام الأولى بعد الإطلاق.
تابع:
- مشكلات المصادقة والوصول؛
- إخفاقات التكاملات؛
- المهام المجدولة؛
- الفروقات المحاسبية؛
- استثناءات المخزون؛
- الأداء؛
- ارتباك المستخدمين في مسارات العمل؛
- الأخطاء والتحذيرات.
حدّد درجات الخطورة والمسؤوليات قبل الإطلاق، كي لا تتحول مشكلات الإنتاج إلى محادثة جماعية بلا تنظيم.
الأسئلة الشائعة
هل يمكن نقل قاعدة بيانات أودو قديمة إلى أودو 20؟
ربما، لكن تحقّق من مسار الترقية الرسمي الحالي للإصدار المصدر والنسخة ونموذج الاستضافة بدقة.
هل يجب أن نرقّي يدوياً عبر كل إصدار وسيط؟
لا تفترض أياً من الاتجاهين. استخدم عملية الترقية المدعومة حالياً من أودو لقاعدة البيانات المصدر بعينها. ومع ذلك، يظل العمل الهندسي على الوحدات المخصصة مطالباً بمراعاة التغييرات التراكمية حتى الإصدار المستهدف.
هل قاعدة البيانات القديمة أصعب لأنها تحتوي على بيانات أكثر؟
حجم البيانات مهم، لكن التخصيصات والتكاملات وتعقيد الأعمال والديون التقنية التاريخية قد تكون أهم.
هل نعيد كتابة الوحدات المخصصة أم نرحّلها؟
صنّفها أولاً: إبقاء، أو استبدال بأودو 20 القياسي، أو إعادة تصميم، أو إيقاف.
هل نرقّي ونعيد تصميم كل شيء دفعة واحدة؟
من الأفضل عادةً فصل المخاطر ما لم يكن هناك سبب مدروس للجمع بينها. فالترقية المضبوطة مع إعادة تصميم محددة النطاق بوضوح أسهل في الاختبار.
هل يمكن ترقية أودو 14 إلى أودو 20؟
ذكرت وثائق أودو تاريخيًا أن الإصدارات الأقدم غير المدعومة لا تزال قابلة للترقية. تحقّق من الأهلية الحالية للانتقال إلى أودو 20 لقاعدة البيانات بعينها ونموذج الاستضافة، ثم قيّم الشيفرة المخصصة والتكاملات.
هل يمكن الانتقال من أودو 15 أو 16 إلى أودو 20؟
استخدم مسار الترقية الرسمي الحالي بدلًا من افتراض أنك مضطر إلى تشغيل كل إصدار وسيط على حدة. ولا تزال الوحدات المخصصة بحاجة إلى ترحيل إلى الإصدار المستهدف.
ما الذي يجعل ترحيل نسخة أودو قديمة مكلفًا؟
عادةً ما تكون التخصيصات، ووحدات الجهات الخارجية، والتكاملات، وجودة البيانات، وتعقيد الأعمال، لا مجرد عمر قاعدة البيانات أو حجمها.
الخلاصة
مشروع الانتقال من أودو قديم إلى أودو 20 هو عملية تحديث، وليس مجرد تحويل لقاعدة بيانات.
وأفضل نتيجة ليست أن "كل ما هو قديم قد نجا".
بل هي:
أن السلوك الحرج للأعمال قد نجا، وأن التخصيصات المتقادمة اختفت، وأن التخصيصات الضرورية أُعيد بناؤها على أنماط مدعومة، وأن للتكاملات مستقبلاً واضحاً، وأن الفريق قادر على العمل بثقة على أودو 20.
هل تخطط لمشروع على أودو 20؟ تساعد Octivex Tech الشركات في ترقيات أودو، وترحيل الوحدات المخصصة، والتكاملات، وسير العمل المدعوم بالذكاء الاصطناعي. تصفّح خدماتنا في أودو أو تواصل مع فريقنا الهندسي لمناقشة بيئتك.