الترحيل من Odoo 17/18 إلى Odoo 19: الدليل الكامل

توفر الترقية إلى Odoo 19 Enterprise تحسينات كبيرة في الأداء وتجربة المستخدم والميزات المدعومة بالذكاء الاصطناعي. لكن الترحيل هو إحدى العمليات الأكثر خطورة في دورة حياة تخطيط موارد المؤسسات (ERP) - حيث إن فقدان البيانات والوحدات المخصصة المعطلة ووقت التوقف الطويل كلها مخاطر حقيقية تتطلب التخطيط والتنفيذ الدقيق.

يوفر هذا الدليل منهجية عملية للترحيل خطوة بخطوة للمؤسسات التي تنتقل من Odoo 17 أو Odoo 18 إلى Odoo 19 Enterprise. وهو يغطي كل شيء بدءًا من التقييم الأولي وتعيين البيانات وحتى تحديثات الوحدة المخصصة وإجراءات الاختبار وخطة التشغيل المباشر.

الوجبات الرئيسية

• يتطلب ترحيل Odoo 19 ترقية إصدار رئيسي واحد في كل مرة (17→18→19 أو 17→19 مباشرةً باستخدام OpenUpgrade)
• يجب التحقق من توافق الوحدة المخصصة مقابل تغييرات واجهة برمجة التطبيقات الخاصة بـ Odoo 19
• يتم ترحيل البيانات من خلال منصة الترقية الرسمية لـ Odoo أو OpenUpgrade
• تعتبر بيئة الاختبار الموازية إلزامية قبل تحويل الإنتاج
• خطط للجدول الزمني الإجمالي للترحيل لمدة 3-8 أسابيع اعتمادًا على التعقيد
• يجب إغلاق الفترات المالية قبل التحويل لتجنب مشاكل التسوية
• تحتاج جميع عمليات تكامل الجهات الخارجية إلى إعادة التحقق بعد الترحيل
• يجب توثيق خطة التراجع واختبارها قبل بدء التشغيل

---

تخطيط الهجرة: مرحلة التقييم

قبل كتابة نص ترحيل واحد، استثمر الوقت في التقييم الشامل. تفشل عمليات الهجرة في أغلب الأحيان بسبب عدم كفاية التخطيط، وليس بسبب التعقيد الفني.

الخطوة 1: جرد بيئتك الحالية

قم بتوثيق كل مكون من مكونات تثبيت Odoo الحالي لديك:

Current Environment Inventory:
- Odoo version: 17.0.x or 18.0.x
- Edition: Community or Enterprise
- Database size: X GB, Y records in sale.order, Z in account.move
- Installed modules: [list all modules]
- Custom modules: [list with developer contact]
- Third-party connectors: [Amazon, Shopify, etc.]
- Active integrations: [API, webhooks, cron jobs]
- Customized reports: [list]
- Custom fields (Studio or code): [list]
- Server specs: RAM, CPU, disk
- PostgreSQL version: (minimum 15 required for Odoo 19)

الخطوة 2: تصنيف الوحدات المخصصة

لكل وحدة مخصصة، حدد:

الخطوة 3: تحديد التغييرات العاجلة في Odoo 19

التغييرات الرئيسية بين Odoo 17/18 وOdoo 19 التي تؤثر على الوحدات المخصصة:

• OWL 3.x: يجب ترحيل مكونات الواجهة الأمامية من أنماط OWL 2.x
• Python 3.12: قد تحتاج بعض صيغ Python 3.10/3.11 إلى تعديل
• PostgreSQL 15+: الحد الأدنى للإصدار المطلوب؛ تتغير بعض أنماط الاستعلام
• إهمال واجهة برمجة التطبيقات: تمت إزالة العديد من أساليب _legacy؛ تحقق من _multi → _create_multi
• محرك التقرير: تمت إعادة تسمية بعض متغيرات تقرير QWeb
• إعادة هيكلة نقل الحساب: تؤثر تغييرات بنية السطر account.move على التخصيصات المحاسبية

---

اختيار مسار الهجرة الخاص بك

المسار 1: خدمة ترقية Odoo الرسمية

توفر Odoo SA خدمة ترقية تلقائية على upgrade.odoo.com. تقوم بإرسال قاعدة البيانات الخاصة بك، ويقومون بتشغيل البرامج النصية للترحيل التي تم تطويرها وصيانتها بواسطة Odoo SA، وتتلقى قاعدة بيانات تمت ترقيتها.

الايجابيات:

• الدعم الرسمي والاختبار من قبل Odoo SA
• يتعامل مع تغييرات مخطط قاعدة البيانات تلقائيًا
• مناسب لنظام Odoo القياسي مع الحد الأدنى من التخصيصات

سلبيات:

• لا يتعامل مع الوحدات المخصصة
• يتطلب تقديم بيانات الإنتاج إلى خوادم Odoo
• سيطرة محدودة على عملية الهجرة
• ترحيل الوحدة المخصصة هو مسؤوليتك

المسار 2: OpenUpgrade (أداة المجتمع)

OpenUpgrade هو مشروع مفتوح المصدر يوفر نصوصًا برمجية للترحيل للمجتمع والمؤسسات.

# Clone OpenUpgrade for Odoo 19
git clone https://github.com/OCA/OpenUpgrade.git -b 19.0

# Install upgrade dependencies
pip install openupgradelib

# Run migration
python odoo-bin --config=upgrade.conf \
    --update=all \
    --load=base,web,openupgrade_framework

المسار 3: التثبيت الجديد مع استيراد البيانات

بالنسبة للمثيلات المخصصة بشكل كبير أو الإصدارات القديمة جدًا:

1. قم بإعداد مثيل Odoo 19 Enterprise جديد
2. إعادة تكوين كافة الوحدات والإعدادات
3. تصدير البيانات الهامة من النظام القديم
4. قم بالاستيراد عبر أداة الاستيراد الخاصة بـ Odoo أو نصوص الترحيل المخصصة
5. إعادة إدخال الأرصدة الافتتاحية للمحاسبة يدوياً

هذا المسار أبطأ ولكنه يوفر نقطة بداية أنظف.

موصى به لمعظم عمليات الترحيل في Odoo 17/18 → 19: المسار 1 أو 2 مدمجًا مع جهود إعادة تطوير الوحدة المخصصة الموازية.

---

التحضير لما قبل الهجرة (الأسابيع 1-2)

** إعداد قاعدة البيانات: **

-- Run on source database before export
-- Identify orphaned records
SELECT id, name FROM res_partner WHERE active = FALSE AND id NOT IN (
    SELECT partner_id FROM sale_order
    UNION SELECT partner_id FROM account_move
    UNION SELECT partner_id FROM stock_picking
);

-- Archive old draft records (reduces migration time)
UPDATE sale_order SET active = FALSE
WHERE state = 'draft' AND date_order < NOW() - INTERVAL '2 years';

-- Verify accounting reconciliation
SELECT COUNT(*) FROM account_move_line
WHERE reconciled = FALSE AND debit != credit;

الفترات المالية المغلقة:

قبل الهجرة:

1. قفل جميع الفترات قبل الشهر الحالي في محاسبة Odoo
2. تشغيل تقارير الذمم المدينة والدائنة القديمة وتسوية الفروقات
3. قم بتسوية كافة البيانات المصرفية خلال تاريخ الترحيل
4. ترحيل جميع مسودات الفواتير التي ينبغي تضمينها في البيانات التاريخية

** النسخ الاحتياطي لكل شيء: **

# PostgreSQL backup
pg_dump -h localhost -p 5433 -U odoo_user -Fc odoo_production > \
    odoo_prod_backup_$(date +%Y%m%d_%H%M%S).dump

# Filestore backup (attachments, images)
tar -czf odoo_filestore_$(date +%Y%m%d).tar.gz \
    /var/lib/odoo/.local/share/Odoo/filestore/

# Configuration backup
cp /etc/odoo/odoo.conf odoo_conf_backup_$(date +%Y%m%d).conf

مراجعة كود الوحدة المخصصة:

لكل وحدة مخصصة، قم بإجراء فحص التوافق:

# Check for deprecated patterns
grep -r "execute_kw" custom_modules/   # Still valid in v19
grep -r "browse\(\[" custom_modules/  # Should be browse(ids) not browse([ids])
grep -r "_multi" custom_modules/      # Check for renamed methods
grep -r "account\.move\.line\." custom_modules/  # Account refactoring affected
grep -r "@api\.one" custom_modules/   # Removed in v14, ensure not present
grep -r "@api\.multi" custom_modules/ # Removed in v14, ensure not present

---

تهيئة بيئة الهجرة (الأسبوع 2-3)

إعداد البنية التحتية:

# Install Odoo 19 Enterprise on migration server
# Requirements: Ubuntu 22.04/24.04, PostgreSQL 15+, Python 3.12

# Install PostgreSQL 15+
sudo apt install postgresql-15 postgresql-contrib

# Install Python 3.12 and dependencies
sudo apt install python3.12 python3.12-dev python3.12-venv \
    libxml2-dev libxslt1-dev libldap2-dev libsasl2-dev \
    libtiff5-dev libjpeg8-dev libopenjp2-7-dev zlib1g-dev \
    libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev \
    libfribidi-dev libxcb1-dev

# Clone Odoo 19 Enterprise
git clone https://github.com/odoo/odoo.git -b 19.0 /opt/odoo19
git clone https://github.com/odoo/enterprise.git -b 19.0 /opt/odoo19-enterprise

# Install Python dependencies
pip3.12 install -r /opt/odoo19/requirements.txt

استعادة قاعدة البيانات المصدر إلى خادم الترحيل:

# Create target database
createdb -h localhost -U postgres odoo_migration_test

# Restore backup
pg_restore -h localhost -U postgres -d odoo_migration_test \
    odoo_prod_backup_YYYYMMDD.dump

# Run Odoo upgrade
python3 /opt/odoo19/odoo-bin \
    -d odoo_migration_test \
    -u all \
    --without-demo=all \
    --stop-after-init

---

ترحيل الوحدة المخصصة (الأسابيع 3-5)

هذه المرحلة هي الأكثر استهلاكا للوقت. تتطلب كل وحدة مخصصة ما يلي:

1. تحديث نسخة البيان:

# Change from:
'version': '17.0.1.0.0',
# To:
'version': '19.0.1.0.0',

2. تحديث توافق بايثون:

# Old pattern (deprecated):
@api.multi
def my_method(self):
    for record in self:
        pass

# New pattern:
def my_method(self):
    for record in self:
        pass

3. تحديث بناء جملة العرض:

<!-- Old (v16 and earlier): -->
<field name="state" attrs="{'invisible': [('active', '=', False)]}"/>

<!-- New (v17+): -->
<field name="state" invisible="not active"/>

4. تحديث مكونات OWL (إن وجدت عناصر الواجهة الأمامية):

يقدم OWL 3.x تغييرات في التفاعل. إذا كانت وحداتك تستخدم عناصر واجهة مستخدم JavaScript مخصصة:

// Old OWL 2.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    willStart() { ... }
}

// New OWL 3.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    setup() {
        onWillStart(async () => { ... });
    }
}

5. اختبار كل وحدة بشكل مستقل:

# Install and test each custom module
python3 odoo-bin -d test_db -i my_custom_module --stop-after-init
python3 odoo-bin -d test_db --test-enable -u my_custom_module

---

التحقق من صحة البيانات واختبارها (الأسابيع 5-6)

التحقق من صحة البيانات المالية:

-- Verify balance sheet balances (assets = liabilities + equity)
SELECT
    SUM(CASE WHEN account_type LIKE 'asset%' THEN balance ELSE 0 END) as assets,
    SUM(CASE WHEN account_type LIKE 'liability%' THEN balance ELSE 0 END) as liabilities,
    SUM(CASE WHEN account_type = 'equity' THEN balance ELSE 0 END) as equity
FROM account_account aa
JOIN account_move_line aml ON aml.account_id = aa.id
JOIN account_move am ON aml.move_id = am.id
WHERE am.state = 'posted';

** التحقق من صحة عدد السجلات: **

مقارنة أعداد السجلات بين قاعدة البيانات المصدر وقاعدة البيانات المُرحّلة:

# Run on both source and target to compare
models_to_check = [
    'res.partner', 'product.template', 'product.product',
    'sale.order', 'purchase.order', 'account.move',
    'stock.quant', 'mrp.production', 'hr.employee'
]

for model in models_to_check:
    count = env[model].search_count([])
    print(f"{model}: {count}")

قائمة التحقق من اختبار قبول المستخدم:

• يمكن الوصول إلى جميع القوائم وعناصر التنقل
• سير العمل الرئيسي: أمر البيع ← التسليم ← الفاتورة ← الدفع
• المحاسبة: قيود اليومية، التسوية البنكية، التقارير
• المخزون: الإيصالات والتسليمات وتقييم المخزون
• التصنيع: قائمة مكونات الصنف، أوامر العمل، فحوصات الجودة (إن أمكن)
• الموارد البشرية: الموظفون، إدارة الإجازات، الرواتب (إن وجدت)
• تم التحقق من وظيفة الوحدة المخصصة بواسطة مستخدمي الأعمال
• يتم إنشاء التقارير بشكل صحيح وتتوافق مع مخرجات ما قبل الترحيل
• تم اختبار عمليات التكامل الخارجية (واجهة برمجة التطبيقات (API)، وخطافات الويب) في المرحلة المرحلية

---

خطة البث المباشر (الأسبوع 7-8)

تخطيط النوافذ الشاملة:

اختر فترة تحويل مع الحد الأدنى من التأثير على الأعمال:

• عطلة نهاية الأسبوع (من مساء السبت إلى صباح الأحد لمعظم الشركات)
• نهاية الشهر المالي (يبسط إدخال الرصيد الافتتاحي)
• بعد آخر يوم عمل قبل عطلة البنوك (وقت احتياطي إضافي)

قائمة التحقق من القطع:

T-48 hours:
[ ] Final communication to all users about downtime window
[ ] Freeze all non-critical transactions in old system
[ ] Verify migration server is ready
[ ] Complete last data validation run

T-0 (Cutover Start):
[ ] Put old system in maintenance mode (disable user access)
[ ] Create final backup of production database
[ ] Run final migration on this backup
[ ] Verify record counts and financial balances
[ ] Test all critical workflows
[ ] DNS/URL cutover to new system
[ ] Smoke test from user devices (desktop, mobile)

T+2 hours (Go-Live Verification):
[ ] All users can log in
[ ] Create test sale order, confirm, ship, invoice
[ ] Verify email sending works
[ ] Check integrations are receiving/sending data
[ ] Monitor error logs for first 30 minutes

خطة العودة:

إذا تم العثور على مشكلات حرجة أثناء عملية الاستبدال:

1. قم بتبديل DNS مرة أخرى إلى الخادم القديم (أقل من 5 دقائق)
2. إعادة تمكين النظام القديم للمستخدمين
3. قم بتوثيق جميع المشكلات التي تم العثور عليها
4. جدولة نافذة متابعة الترحيل

---

الأسئلة المتداولة

هل يمكنني الانتقال من Odoo 17 مباشرة إلى Odoo 19 أم يجب أن أنتقل إلى 18؟

باستخدام خدمة الترقية الرسمية من Odoo، يمكنك عادةً الانتقال مباشرة من 17 إلى 19. وتتعامل نصوص الترحيل الخاصة بـ Odoo SA مع القفزات المتعددة الإصدارات. مع OpenUpgrade، قد تحتاج إلى الانتقال إلى 17 → 18 → 19 اعتمادًا على نصوص الترحيل المتاحة. تحقق دائمًا من مستودع OpenUpgrade لمعرفة الإصدارات المحددة التي تحتاجها.

ما المدة التي تستغرقها عملية الترحيل النموذجية لنظام Odoo؟

يعتمد الجدول الزمني بشكل كبير على مستوى التخصيص. مثيل Odoo قياسي مع الحد الأدنى من التخصيصات: 2-3 أسابيع. مخصصة إلى حد ما (5-10 وحدات مخصصة): 4-6 أسابيع. مخصصة بشكل كبير مع عمليات التكامل المعقدة: 8-16 أسبوعًا. تستغرق عملية الترحيل نفسها (ترقية قاعدة البيانات) ساعات؛ الوقت قيد الاختبار وتحديثات الوحدة والتحقق من الصحة.

ماذا يحدث لتخصيصات الاستوديو أثناء الترحيل؟

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

هل أحتاج إلى إعادة إدخال الأرصدة الافتتاحية بعد الترحيل؟

لا، إذا قمت بترحيل قاعدة البيانات مباشرة. يتم نقل كافة إدخالات دفتر اليومية والأرصدة التاريخية مع قاعدة البيانات. إذا اخترت مسار "التثبيت الجديد مع استيراد البيانات"، فستحتاج إلى إدخال الأرصدة الافتتاحية اعتبارًا من تاريخ الاستبدال، الأمر الذي يتطلب تنسيقًا دقيقًا مع فريق المحاسبة الخاص بك.

هل سيتم نقل ترخيص Odoo Enterprise الخاص بي إلى الإصدار 19؟

نعم. لا تختلف اشتراكات Odoo Enterprise عن الإصدار. يغطي اشتراكك السنوي أي إصدار تقوم بتشغيله. اتصل بشريك Odoo الخاص بك للحصول على رمز Odoo 19 Enterprise إذا لم تتمكن من الوصول إليه من خلال مستودع Odoo's Git باستخدام بيانات اعتماد مؤسستك.

---

الخطوات التالية

تعد عمليات ترحيل Odoo عبارة عن مشاريع عالية المخاطر تؤثر بشكل مباشر على استمرارية الأعمال. الفرق بين الهجرة السلسة والهجرة المؤلمة يعود إلى الإعداد والخبرة ومنهجية الاختبار الصارمة.

نجحت ECOSIRE في ترحيل العشرات من مثيلات Odoo من الإصدارات 13 و14 و15 و16 و17 و18 إلى Odoo 19 Enterprise. تغطي منهجية الترحيل لدينا التقييم الكامل وتحديثات الوحدات المخصصة والاختبار الموازي وخطة الاستبدال الموثقة مع إجراءات التراجع.

اطلب تقييم ترحيل Odoo من ECOSIRE →

سنقوم بتقييم بيئتك الحالية، وتحديد جميع مخاطر الترحيل، وتوفير خطة ترحيل ذات نطاق ثابت حتى تعرف بالضبط ما يمكن توقعه قبل تشغيل البرنامج النصي الأول للترحيل.