الترقية من Odoo 16 إلى Odoo 19: التكلفة الحقيقية على الشركات في الإمارات

«الترقية من Odoo 16 إلى Odoo 19» عبارة توحي بمشروع واحد، لكنها في حقيقتها ثلاثة مشاريع: ثلاث قفزات سنوية بين الإصدارات الرئيسية، مجتمعةً في عملية ترحيل واحدة، ولكل قفزة منها تغييراتها التي تكسر التوافق مع ما قبلها. وتسألني عن هذا الأمر شركات في الإمارات أنجزت الإطلاق الفعلي على Odoo 16 وبدأت ترى نافذة الدعم لديها تقترب من الإغلاق. والسؤال دائماً هو كم ستبلغ التكلفة، والجواب الصادق أن القفزة بين الإصدارات في حدّ ذاتها تكاد تكون مجانية، أما ما يكلّف مالاً حقاً فهو كل ما بنيته فوق Odoo القياسي منذ الإطلاق الفعلي. وهذا هو التمييز الذي أشرحه لكل عميل، مع طريقتي في التفكير في توقيت الترقية.

مشروع واحد تختبئ فيه ترقيتان

تعرّف وثائق Odoo الرسمية الترقية تعريفاً بسيطاً: نقل قاعدة بيانات من إصدار أقدم إلى إصدار أحدث مدعوم، «مثل الانتقال من Odoo 16.0 إلى Odoo 18.0». وهذا يغطي أمراً واحداً بعينه: تطبيقاتك القياسية وبياناتك. ويتولى فريق الترقية لدى Odoo تحويل الاثنين آلياً، وهذا التحويل مجاني ضمن Odoo Enterprise، «بما في ذلك أي دعم لازم لمعالجة ما قد يظهر من تباينات في قاعدة البيانات المُرقّاة».

أما تخصيصاتك فمسألة منفصلة. إذ تعرّف Odoo الوحدة المخصّصة بأنها «أي وحدة توسّع الشيفرة القياسية لـ Odoo ولم تُبنَ بتطبيق Studio»، وتوزّع المسؤولية على هذا الأساس. فأعمال Studio مشمولة باتفاقية مستوى الخدمة (SLA) ما دام Studio مثبّتاً والاشتراك فيه قائماً، وكذلك الأعمال التي يغطيها عقد صيانة التخصيصات ما دام ساري المفعول. أما كل ما سوى ذلك، أي الوحدات التي بُنيت داخل الشركة أو اشتُريت من طرف خارجي دون هذا العقد، فمستثنى، وقاعدة البيانات «لا يمكن ترقيتها إلى أن يتوافر إصدار من وحداتك المخصّصة للإصدار المستهدف من Odoo». وهذا شرط تقني صارم لا مجرد إجراء شكلي: فلا ترقية ما لم تتوافر شيفرة مخصّصة متوافقة. وهو سبب آخر يجعلني أرى أن الاختيار بين Studio والشيفرة المخصّصة قرار يستحق أن يُتخذ عن قصد وقت البناء، لا أن يُترك للعادة.

لماذا لا تكون القفزة بين الإصدارات عادةً هي الجزء الصعب

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

أما ما يحرّك التكلفة فعلاً فهو الفجوة بين الإصدارين. وتقولها Odoo بوضوح: «كلما صغرت الفجوة بين الإصدارين، يُفترض أن تكون الترقية أسهل». فكل إصدار رئيسي يمسّ الحقول وطرق العرض والدوال البرمجية، وإرشادات Odoo نفسها لقواعد البيانات المخصّصة تذكر ما ينكسر بالتحديد: حقول أُعيدت تسميتها أو أُزيلت، وطرق عرض نُقلت من موضعها، ودوال لم تعد موجودة. فإذا عبرتَ ثلاثة إصدارات رئيسية دفعة واحدة، كما يحدث في مشروع من 16 إلى 19، مرّت الشيفرة المخصّصة بثلاث جولات من ذلك لا بجولة واحدة. ويحمل بناء مخصّص لقطاع بعينه، مثل نظام إدارة الجامعات المكوّن من 18 وحدة الذي صمّمته، من هذا العبء أكثر بكثير مما تحمله شركة تجارية قريبة من الوضع القياسي، لأن نصيب التخصيص فيه أكبر بحكم التصميم. وفي عمليات التطبيق التي راجعتُها ضمن دراسة لـ 140 وحدة Odoo مخصّصة، تبيّن أن 79% منها بُنيت من الصفر أو أُعيد تعديلها بدلاً من تركها على حالها كما ثُبّتت، وهذه هي الشيفرة التي تخضعها ترقية كهذه لإعادة الاختبار فعلاً. كما تدعم Odoo كل إصدار رئيسي ثلاث سنوات، تليها مهلة إضافية لإتمام أي ترقية إلزامية، ولذلك فالبقاء على الإصدار 16 له أجل محدود.

سير عمل الترقية التجريبية

اطلب أولاً، ثم كيّف شيفرتك الخاصة

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

تحقّق، ثم أجرِ البروفة، ثم انتقل إلى الإطلاق الفعلي

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

نظافة البيانات: أرخص خطوة لا يقوم بها أحد

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

تطبيقات الأطراف الخارجية: من يتولى صيانتها فعلاً

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

إعادة التدريب واختبار قبول المستخدمين (UAT)

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

هل تُرقّي الآن أم تبقى على الإصدار 16؟

المحفّز الصحيح للانتقال ليس أن «19 هو أحدث رقم»، وإنما أن يكون في أحد الإصدارات الواقعة بين إصدارك الحالي والإصدار 19 ما يحلّ مشكلة تواجهها فعلاً. وفي تجربتي تشمل الأسباب المشروعة للانتقال الآن حاجة فريقك إلى ميزة بعينها (وأول ما أبدأ به لمقابلتها بقائمتك أنت هو ما الجديد فعلاً في Odoo 19)، أو نافذة دعم تقترب من الإغلاق، أو تخصيصاً كثيفاً يزداد حمله كلفة كلما تأخّرت. وإن كنت في الإمارات فأضف إلى هذه القائمة تقويم الامتثال لديك: فمواءمة الانتقال مع إعداد ضريبة القيمة المضافة أو مع الجدول الزمني لجاهزيتك للفوترة الإلكترونية سبب مشروع للانتقال الآن، حتى لا تعيد ضبط المنطق الضريبي وتنتقل إلى إصدار جديد من Odoo في الشهر نفسه.

ولا ينطبق شيء من ذلك على كل شركة. فإن كان نظام Odoo 16 لديك مستقراً، وفريقك منتجاً، ولا شيء في قائمة ميزات Odoo 19 يعالج فجوة تشعر بها، فلا إلزام بالانتقال في هذا الربع. غير أن عليك ألا تحسب ذلك إعفاءً مفتوحاً، فعدّاد الدعم ما زال يعمل، وكلما انتظرت اتسعت الفجوة بين الإصدارين التي ستعبرها في النهاية.

الأسئلة الشائعة

قراءات ذات صلة