メインコンテンツにスキップ

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

Odoo 17 または 18 から Odoo 19 に移行するためのステップバイステップ ガイド。計画、データ移行、カスタム モジュールの更新、テスト、ダウンタイムなしのカットオーバーについて説明します。

E
ECOSIRE Research and Development Team
|2026年3月19日4 分で読める768 語数|

移行は ERP ライフサイクルの中で最もリスクの高い操作の 1 つです。データ損失、カスタム モジュールの破損、ダウンタイムの延長はすべて実際のリスクであり、慎重な計画と実行が必要です。

移行は ERP ライフサイクルの中で最もリスクの高い操作の 1 つです。データ損失、カスタム モジュールの破損、ダウンタイムの延長はすべて実際のリスクであり、慎重な計画と実行が必要です。

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

重要なポイント

  • カスタム モジュールの互換性を Odoo 19 の API 変更に対して検証する必要がある
  • データ移行は Odoo の公式アップグレード プラットフォームまたは OpenUpgrade を通じて実行されます
  • 実稼働切り替え前に並行テスト環境が必須
  • 調整の問題を避けるために、カットオーバー前に会計期間を終了する必要があります
  • すべてのサードパーティ統合は移行後に再検証が必要です
  • ロールバック計画は、運用開始前に文書化してテストする必要があります

移行計画: 評価フェーズ

単一の移行スクリプトを作成する前に、時間をかけて徹底的な評価を行ってください。移行が失敗するほとんどの場合、技術的な複雑さではなく、計画が不十分であることが原因です。

ステップ 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:

ステップ 2: カスタム モジュールを分類する

カスタム モジュールごとに、次のことを決定します。

分類定義移行アクション
標準使用Odoo マーケットプレイスから変更されていないモジュールOdoo 19 の再ダウンロード
軽く修正しましたマイナーなフィールドの追加、ビューの変更更新とテスト
大幅にカスタマイズビジネスクリティカルな Python ロジック完全な開発者レビュー
非推奨Odoo コアの機能削除して再構成する
互換性がありません削除された Odoo 19 API に依存します書き換えが必要

移行パスの選択

パス 1: Odoo 公式アップグレード サービス

Odoo SA は、upgrade.odoo.com で自動アップグレード サービスを提供します。データベースを送信すると、Odoo SA によって開発および保守されている移行スクリプトが実行され、アップグレードされたデータベースを受け取ります。

長所:

  • Odoo SA による公式サポートとテスト
  • データベーススキーマの変更を自動的に処理します
  • 最小限のカスタマイズを備えた標準的な Odoo に適しています

短所:

  • 運用データを Odoo のサーバーに送信する必要があります
  • 移行プロセスに対する制限された制御
  • カスタム モジュールの移行はお客様の責任です

パス 2: OpenUpgrade (コミュニティ ツール)

OpenUpgrade は、コミュニティ向けの移行スクリプトを提供するオープンソース プロジェクトです。

パス 3: データ インポートを使用した新規インストール

大幅にカスタマイズされたインスタンスまたは非常に古いバージョンの場合:

  1. 新しい Odoo 19 Enterprise インスタンスをセットアップする
  2. すべてのモジュールと設定を再構成します
  3. 古いシステムから重要なデータをエクスポートする
  4. Odoo のインポート ツールまたはカスタム移行スクリプトを介してインポートする
  5. 会計用の期首残高を手動で再入力する

このパスは遅いですが、最もクリーンな開始点となります。

ほとんどの Odoo 17/18 → 19 移行に推奨: パス 1 または 2 と並行したカスタム モジュールの再開発作業を組み合わせます。


移行前の準備

決算期を終える:

移行前:

  1. Odoo Accounting で当月より前のすべての期間をロックする
  2. 期限切れの売掛金および買掛金レポートを実行し、差異を調整します
  3. 移行日までのすべての銀行取引明細書を照合します。
  4. 履歴データに含める必要があるすべての請求書草案を転記します。

すべてをバックアップします:

# PostgreSQL backup
pg_dump -h localhost -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

移行環境のセットアップ

インフラストラクチャのセットアップ:

# Install Odoo 19 Enterprise on migration server

# 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

カスタム モジュールの移行

このフェーズは最も時間がかかります。各カスタム モジュールには次のものが必要です。

1.マニフェストのバージョンを更新します:

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

2.ビューの構文を更新します:

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

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

3.各モジュールを個別にテストします:

# 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

データの検証とテスト

レコード数の検証:

ソース データベースと移行されたデータベースの間でレコード数を比較します。

# 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 カットオーバー プラン

カットオーバー期間の計画:

ビジネスへの影響を最小限に抑えたカットオーバー ウィンドウを選択します。

  • 週末(ほとんどの企業では土曜日の夕方から日曜日の朝まで)
  • 年度末(期首残高入力を簡素化)
  • 銀行休業日前の最終営業日以降(追加のバッファタイム)

カットオーバーチェックリスト:

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 を古いサーバーに戻します
  2. ユーザーに対して古いシステムを再度有効にする
  3. 見つかったすべての問題を文書化する
  4. フォローアップ移行期間のスケジュールを設定する

よくある質問

Odoo 17 から Odoo 19 に直接スキップできますか? それとも 18 を経由する必要がありますか?

Odoo の公式アップグレード サービスを使用すると、通常は 17 から 19 に直接移行できます。Odoo SA の移行スクリプトは複数バージョンのジャンプを処理します。必要な特定のバージョンについては、常に OpenUpgrade リポジトリを確認してください。

一般的な Odoo の移行にはどのくらい時間がかかりますか?

タイムラインはカスタマイズ レベルに大きく依存します。移行自体 (データベースのアップグレード) には数時間かかります。時間はテスト、モジュールの更新、検証にあります。

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

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

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

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


次のステップ

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

当社の移行方法論には、完全な評価、カスタム モジュールの更新、並行テスト、ロールバック手順を含む文書化されたカットオーバー計画が含まれます。

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

E

執筆者

ECOSIRE Research and Development Team

テクニカルライティング

ECOSIRE のテクニカルライティングチームは、Odoo ERP、Shopify による EC、AI エージェント、Power BI による分析、GoHighLevel による自動化、そしてエンタープライズソフトウェアのベストプラクティスを扱っています。私たちのガイドは、企業が十分な情報に基づいてテクノロジーを判断できるよう支援します。

ECOSIRE

Odoo ERP でビジネスを変革

Odoo の専門家による実装、カスタマイズ、サポートにより、業務を合理化します。