Migrating from Odoo 17/18 to Odoo 19: Complete Guide

Step-by-step guide to migrating from Odoo 17 or 18 to Odoo 19. Covers planning, data migration, custom module updates, testing, and zero-downtime cutover.

E
ECOSIRE Research and Development Team
|19 मार्च 202611 मिनट पढ़ें2.4k शब्द|

ओडू 17/18 से ओडू 19 में माइग्रेट करना: संपूर्ण गाइड

Odoo 19 एंटरप्राइज में अपग्रेड करने से प्रदर्शन, उपयोगकर्ता अनुभव और AI-सहायता सुविधाओं में महत्वपूर्ण सुधार मिलते हैं। लेकिन ईआरपी जीवनचक्र में माइग्रेशन सबसे अधिक जोखिम वाले ऑपरेशनों में से एक है - डेटा हानि, टूटे हुए कस्टम मॉड्यूल और विस्तारित डाउनटाइम सभी वास्तविक जोखिम हैं जिनके लिए सावधानीपूर्वक योजना और निष्पादन की आवश्यकता होती है।

यह मार्गदर्शिका Odoo 17 या Odoo 18 से Odoo 19 Enterprise की ओर जाने वाले संगठनों के लिए एक व्यावहारिक, चरण-दर-चरण माइग्रेशन पद्धति प्रदान करती है। इसमें प्रारंभिक मूल्यांकन और डेटा मैपिंग से लेकर कस्टम मॉड्यूल अपडेट, परीक्षण प्रक्रियाएं और गो-लाइव कटओवर योजना तक सब कुछ शामिल है।

मुख्य बातें

  • ओडू 19 माइग्रेशन के लिए एक समय में एक प्रमुख संस्करण को अपग्रेड करने की आवश्यकता होती है (17→18→19 या 17→19 सीधे ओपनअपग्रेड के साथ)
  • कस्टम मॉड्यूल अनुकूलता को Odoo 19 के API परिवर्तनों के विरुद्ध सत्यापित किया जाना चाहिए
  • डेटा माइग्रेशन ओडू के आधिकारिक अपग्रेड प्लेटफॉर्म या ओपनअपग्रेड के माध्यम से चलता है
  • उत्पादन कटौती से पहले एक समानांतर परीक्षण वातावरण अनिवार्य है
  • जटिलता के आधार पर 3-8 सप्ताह की कुल प्रवासन समय-सीमा की योजना बनाएं
  • समाधान संबंधी समस्याओं से बचने के लिए वित्तीय अवधियों को कटओवर से पहले बंद कर देना चाहिए
  • माइग्रेशन के बाद सभी तृतीय-पक्ष एकीकरणों को पुन: सत्यापन की आवश्यकता होती है
  • रोलबैक योजना को लाइव होने से पहले दस्तावेज़ीकृत और परीक्षण किया जाना चाहिए

प्रवास योजना: मूल्यांकन चरण

एकल माइग्रेशन स्क्रिप्ट लिखने से पहले, संपूर्ण मूल्यांकन में समय लगाएं। प्रवास अक्सर अपर्याप्त योजना के कारण विफल होता है, न कि तकनीकी जटिलता के कारण।

चरण 1: अपने वर्तमान परिवेश की सूची बनाएं

अपने वर्तमान ओडू इंस्टॉलेशन के प्रत्येक घटक का दस्तावेजीकरण करें:

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: कस्टम मॉड्यूल वर्गीकृत करें

प्रत्येक कस्टम मॉड्यूल के लिए, निर्धारित करें:

वर्गीकरणपरिभाषामाइग्रेशन एक्शन
मानक उपयोगओडू मार्केटप्लेस से मॉड्यूल अपरिवर्तितOdoo 19 के लिए पुनः डाउनलोड करें
हल्के से संशोधितमामूली फ़ील्ड परिवर्धन, परिवर्तन देखेंअद्यतन करें और परीक्षण करें
अत्यधिक अनुकूलितव्यवसाय-महत्वपूर्ण पायथन तर्कपूर्ण डेवलपर समीक्षा
पदावनतओडू कोर में अब कार्यक्षमतानिकालें और पुन: कॉन्फ़िगर करें
असंगतहटाए गए Odoo 19 API पर निर्भर करता हैपुनः लिखना आवश्यक

चरण 3: ओडू 19 ब्रेकिंग परिवर्तनों की पहचान करें

Odoo 17/18 और Odoo 19 के बीच मुख्य परिवर्तन जो कस्टम मॉड्यूल को प्रभावित करते हैं:

  • OWL 3.x: फ्रंटएंड घटकों को OWL 2.x पैटर्न से माइग्रेट किया जाना चाहिए
  • पायथन 3.12: कुछ पायथन 3.10/3.11 सिंटैक्स को समायोजन की आवश्यकता हो सकती है
  • पोस्टग्रेएसक्यूएल 15+: आवश्यक न्यूनतम संस्करण; कुछ क्वेरी पैटर्न बदलते हैं
  • एपीआई बहिष्करण: कई _legacy विधियां हटा दी गईं; _multi_create_multi की जाँच करें
  • रिपोर्ट इंजन: कुछ QWeb रिपोर्ट वेरिएबल का नाम बदला गया
  • अकाउंट मूव रिफैक्टरिंग: account.move लाइन संरचना परिवर्तन लेखांकन अनुकूलन को प्रभावित करते हैं

अपना प्रवास पथ चुनना

पथ 1: ओडू आधिकारिक अपग्रेड सेवा

Odoo SA upgrade.odoo.com पर एक स्वचालित अपग्रेड सेवा प्रदान करता है। आप अपना डेटाबेस सबमिट करते हैं, वे Odoo SA द्वारा विकसित और अनुरक्षित माइग्रेशन स्क्रिप्ट चलाते हैं, और आपको एक उन्नत डेटाबेस प्राप्त होता है।

पेशेवर:

  • ओडू एसए द्वारा आधिकारिक समर्थन और परीक्षण
  • डेटाबेस स्कीमा परिवर्तनों को स्वचालित रूप से संभालता है
  • न्यूनतम अनुकूलन के साथ मानक ओडू के लिए उपयुक्त

विपक्ष:

  • कस्टम मॉड्यूल को संभाल नहीं पाता
  • Odoo के सर्वर पर उत्पादन डेटा सबमिट करने की आवश्यकता है
  • प्रवासन प्रक्रिया पर सीमित नियंत्रण
  • कस्टम मॉड्यूल माइग्रेशन आपकी जिम्मेदारी है

पथ 2: ओपनअपग्रेड (सामुदायिक उपकरण)

ओपनअपग्रेड एक ओपन-सोर्स प्रोजेक्ट है जो समुदाय और उद्यम के लिए माइग्रेशन स्क्रिप्ट प्रदान करता है।

# 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 एंटरप्राइज इंस्टेंस सेट करें
  2. सभी मॉड्यूल और सेटिंग्स को पुन: कॉन्फ़िगर करें
  3. पुराने सिस्टम से महत्वपूर्ण डेटा निर्यात करें
  4. Odoo के आयात उपकरण या कस्टम माइग्रेशन स्क्रिप्ट के माध्यम से आयात करें
  5. लेखांकन के लिए आरंभिक शेषों को मैन्युअल रूप से पुनः दर्ज करें

यह पथ धीमा है लेकिन सबसे साफ़ प्रारंभिक बिंदु प्रदान करता है।

अधिकांश ओडू 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. ओडू अकाउंटिंग में चालू माह से पहले की सभी अवधियों को लॉक करें
  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 प्रतिक्रियाशीलता परिवर्तन प्रस्तुत करता है। यदि आपके मॉड्यूल कस्टम जावास्क्रिप्ट विजेट का उपयोग करते हैं:

// 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}")

उपयोगकर्ता स्वीकृति परीक्षण चेकलिस्ट:

  • सभी मेनू और नेविगेशन आइटम पहुंच योग्य
  • मुख्य कार्यप्रवाह: बिक्री आदेश → वितरण → चालान → भुगतान
  • लेखांकन: जर्नल प्रविष्टियाँ, बैंक समाधान, रिपोर्ट
  • इन्वेंटरी: प्राप्तियां, डिलीवरी, स्टॉक मूल्यांकन
  • विनिर्माण: बीओएम, कार्य आदेश, गुणवत्ता जांच (यदि लागू हो)
  • एचआर: कर्मचारी, अवकाश प्रबंधन, पेरोल (यदि लागू हो)
  • व्यावसायिक उपयोगकर्ताओं द्वारा सत्यापित कस्टम मॉड्यूल कार्यक्षमता
  • रिपोर्टें सही ढंग से उत्पन्न होती हैं और प्री-माइग्रेशन आउटपुट से मेल खाती हैं
  • स्टेजिंग में बाहरी एकीकरण (एपीआई, वेबहुक) का परीक्षण किया गया

गो-लाइव कटओवर योजना (सप्ताह 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. फॉलो-अप माइग्रेशन विंडो शेड्यूल करें

अक्सर पूछे जाने वाले प्रश्न

क्या मैं ओडू 17 से सीधे ओडू 19 पर जा सकता हूं, या मुझे 18 से गुजरना होगा?

ओडू की आधिकारिक अपग्रेड सेवा का उपयोग करके, आप आम तौर पर सीधे 17 से 19 तक जा सकते हैं। ओडू एसए की माइग्रेशन स्क्रिप्ट मल्टी-वर्जन जंप को संभालती हैं। ओपनअपग्रेड के साथ, आपको उपलब्ध माइग्रेशन स्क्रिप्ट के आधार पर 17→18→19 तक जाने की आवश्यकता हो सकती है। आपके लिए आवश्यक विशिष्ट संस्करणों के लिए हमेशा OpenUpgrade रिपॉजिटरी की जाँच करें।

सामान्य ओडू प्रवास में कितना समय लगता है?

समयरेखा काफी हद तक अनुकूलन स्तर पर निर्भर करती है। न्यूनतम अनुकूलन के साथ एक मानक ओडू उदाहरण: 2-3 सप्ताह। मध्यम रूप से अनुकूलित (5-10 कस्टम मॉड्यूल): 4-6 सप्ताह। जटिल एकीकरणों के साथ अत्यधिक अनुकूलित: 8-16 सप्ताह। माइग्रेशन (डेटाबेस अपग्रेड) में ही घंटों लग जाते हैं; समय परीक्षण, मॉड्यूल अपडेट और सत्यापन में है।

माइग्रेशन के दौरान स्टूडियो अनुकूलन का क्या होता है?

स्टूडियो अनुकूलन को मानक ओडू डेटा (दृश्य, फ़ील्ड, ऑटोमेशन) के रूप में संग्रहीत किया जाता है और मानक डेटाबेस अपग्रेड प्रक्रिया के माध्यम से माइग्रेट किया जाता है। हालाँकि, यदि Odoo 19 ने अंतर्निहित प्रपत्र संरचना को बदल दिया है, तो कुछ दृश्य अनुकूलन को मैन्युअल समीक्षा की आवश्यकता हो सकती है। माइग्रेशन के बाद हमेशा सभी स्टूडियो अनुकूलन का परीक्षण करें।

क्या मुझे माइग्रेशन के बाद शुरुआती शेष राशि दोबारा दर्ज करने की आवश्यकता है?

नहीं, यदि आप डेटाबेस को सीधे माइग्रेट करते हैं। सभी ऐतिहासिक जर्नल प्रविष्टियाँ और शेष डेटाबेस के साथ स्थानांतरित होते हैं। यदि आप "डेटा आयात के साथ ताज़ा इंस्टॉल" पथ चुनते हैं, तो आपको कटओवर तिथि के अनुसार प्रारंभिक शेष दर्ज करना होगा, जिसके लिए आपकी लेखा टीम के साथ सावधानीपूर्वक समन्वय की आवश्यकता होती है।

क्या मेरा ओडू एंटरप्राइज लाइसेंस संस्करण 19 में स्थानांतरित हो जाएगा?

हाँ। Odoo Enterprise सदस्यताएँ संस्करण-अज्ञेयवादी हैं। आपकी वार्षिक सदस्यता आपके द्वारा चलाए जाने वाले किसी भी संस्करण को कवर करती है। यदि आप Odoo 19 एंटरप्राइज़ कोड प्राप्त करने के लिए अपने Odoo पार्टनर से संपर्क करें, यदि आप इसे अपने एंटरप्राइज़ क्रेडेंशियल्स के साथ Odoo के Git रिपॉजिटरी के माध्यम से एक्सेस नहीं कर रहे हैं।


अगले चरण

ओडू प्रवासन उच्च-जोखिम वाली परियोजनाएं हैं जो सीधे व्यापार निरंतरता को प्रभावित करती हैं। सहज प्रवास और कष्टदायक प्रवास के बीच का अंतर तैयारी, विशेषज्ञता और कठोर परीक्षण पद्धति पर निर्भर करता है।

ECOSIRE ने संस्करण 13, 14, 15, 16, 17 और 18 से Odoo 19 एंटरप्राइज़ में दर्जनों Odoo उदाहरणों को सफलतापूर्वक स्थानांतरित कर दिया है। हमारी माइग्रेशन पद्धति में पूर्ण मूल्यांकन, कस्टम मॉड्यूल अपडेट, समानांतर परीक्षण और रोलबैक प्रक्रियाओं के साथ एक दस्तावेजित कटओवर योजना शामिल है।

ECOSIRE से ओडू प्रवासन आकलन का अनुरोध करें →

हम आपके वर्तमान परिवेश का आकलन करेंगे, सभी माइग्रेशन जोखिमों की पहचान करेंगे, और एक निश्चित-स्कोप माइग्रेशन योजना प्रदान करेंगे ताकि आप जान सकें कि पहली माइग्रेशन स्क्रिप्ट चलने से पहले आपको क्या उम्मीद करनी है।

शेयर करें:
E

लेखक

ECOSIRE Research and Development Team

ECOSIRE में एंटरप्राइज़-ग्रेड डिजिटल उत्पाद बना रहे हैं। Odoo एकीकरण, ई-कॉमर्स ऑटोमेशन, और AI-संचालित व्यावसायिक समाधानों पर अंतर्दृष्टि साझा कर रहे हैं।

WhatsApp पर चैट करें