Odoo 17/18 から Odoo 19 への移行: 完全ガイド

Odoo 19 Enterprise にアップグレードすると、パフォーマンス、ユーザー エクスペリエンス、AI 支援機能が大幅に向上します。しかし、移行は ERP ライフサイクルの中で最もリスクの高い操作の 1 つです。データ損失、カスタム モジュールの破損、ダウンタイムの延長はすべて実際のリスクであり、慎重な計画と実行が必要です。

このガイドでは、Odoo 17 または Odoo 18 から Odoo 19 Enterprise に移行する組織向けに、実践的で段階的な移行方法を提供します。初期評価とデータ マッピングからカスタム モジュールの更新、テスト手順、本番稼働へのカットオーバー計画に至るまで、すべてを網羅しています。

重要なポイント

• Odoo 19 への移行では、一度に 1 つのメジャー バージョンをアップグレードする必要があります (OpenUpgrade を使用して直接 17→18→19 または 17→19)
• カスタム モジュールの互換性を Odoo 19 の API 変更に対して検証する必要がある
• データ移行は 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+: 必要な最小バージョン。一部のクエリパターンが変更される
• API の非推奨: いくつかの _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 Accounting で当月より前のすべての期間をロックする
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. Python の互換性を更新:

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

ユーザー受け入れテストのチェックリスト:

• すべてのメニューとナビゲーション項目にアクセス可能
• 主なワークフロー: 販売注文→配送→請求書→支払い
• 会計: 仕訳、銀行調整、レポート
• 在庫: 入庫、納品、在庫評価
• 製造: BOM、作業指示書、品質チェック (該当する場合)
• 人事: 従業員、休暇管理、給与計算 (該当する場合)
• ビジネス ユーザーによって検証されたカスタム モジュールの機能
• レポートは正しく生成され、移行前の出力と一致します。
• ステージングでテストされた外部統合 (API、Webhook)

---

Go-Live カットオーバー プラン (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 週間。移行自体 (データベースのアップグレード) には数時間かかります。時間はテスト、モジュールの更新、検証にあります。

移行中に Studio のカスタマイズはどうなりますか?

Studio のカスタマイズは標準の Odoo データ (ビュー、フィールド、オートメーション) として保存され、標準のデータベース アップグレード プロセスを通じて移行されます。ただし、Odoo 19 で基礎となるフォーム構造が変更された場合、一部のビューのカスタマイズは手動で確認する必要がある場合があります。移行後は、Studio のカスタマイズをすべて必ずテストしてください。

移行後に期首残高を再入力する必要がありますか?

データベースを直接移行する場合は、いいえ。すべての過去の仕訳入力と残高はデータベースに転送されます。 「データインポートを伴う新規インストール」パスを選択した場合は、カットオーバー日の期首残高を入力する必要があり、これには会計チームとの慎重な調整が必要です。

Odoo Enterprise ライセンスはバージョン 19 に移行しますか?

はい。 Odoo Enterprise サブスクリプションはバージョンに依存しません。年間サブスクリプションには、実行しているバージョンに関係なく適用されます。エンタープライズ認証情報を使用して Odoo の Git リポジトリ経由でアクセスしていない場合は、Odoo パートナーに連絡して Odoo 19 Enterprise コードを取得してください。

---

次のステップ

Odoo の移行は、ビジネスの継続性に直接影響を与える一か八かのプロジェクトです。スムーズな移行と困難な移行の違いは、準備、専門知識、および厳格なテスト方法にかかっています。

ECOSIRE は、数十の Odoo インスタンスをバージョン 13、14、15、16、17、および 18 から Odoo 19 Enterprise に移行することに成功しました。当社の移行方法論には、完全な評価、カスタム モジュールの更新、並行テスト、ロールバック手順を含む文書化されたカットオーバー計画が含まれます。

ECOSIRE に Odoo 移行評価をリクエスト →

現在の環境を評価し、すべての移行リスクを特定し、最初の移行スクリプトを実行する前に何が予想されるかを正確に把握できるように、固定範囲の移行計画を提供します。