移行は 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: データ インポートを使用した新規インストール
大幅にカスタマイズされたインスタンスまたは非常に古いバージョンの場合:
- 新しい Odoo 19 Enterprise インスタンスをセットアップする
- すべてのモジュールと設定を再構成します
- 古いシステムから重要なデータをエクスポートする
- Odoo のインポート ツールまたはカスタム移行スクリプトを介してインポートする
- 会計用の期首残高を手動で再入力する
このパスは遅いですが、最もクリーンな開始点となります。
ほとんどの Odoo 17/18 → 19 移行に推奨: パス 1 または 2 と並行したカスタム モジュールの再開発作業を組み合わせます。
移行前の準備
決算期を終える:
移行前:
- Odoo Accounting で当月より前のすべての期間をロックする
- 期限切れの売掛金および買掛金レポートを実行し、差異を調整します
- 移行日までのすべての銀行取引明細書を照合します。
- 履歴データに含める必要があるすべての請求書草案を転記します。
すべてをバックアップします:
# 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
ロールバック計画:
カットオーバー中に重大な問題が見つかった場合:
- DNS を古いサーバーに戻します
- ユーザーに対して古いシステムを再度有効にする
- 見つかったすべての問題を文書化する
- フォローアップ移行期間のスケジュールを設定する
よくある質問
Odoo 17 から Odoo 19 に直接スキップできますか? それとも 18 を経由する必要がありますか?
Odoo の公式アップグレード サービスを使用すると、通常は 17 から 19 に直接移行できます。Odoo SA の移行スクリプトは複数バージョンのジャンプを処理します。必要な特定のバージョンについては、常に OpenUpgrade リポジトリを確認してください。
一般的な Odoo の移行にはどのくらい時間がかかりますか?
タイムラインはカスタマイズ レベルに大きく依存します。移行自体 (データベースのアップグレード) には数時間かかります。時間はテスト、モジュールの更新、検証にあります。
移行中に Studio のカスタマイズはどうなりますか?
Studio のカスタマイズは標準の Odoo データ (ビュー、フィールド、オートメーション) として保存され、標準のデータベース アップグレード プロセスを通じて移行されます。ただし、Odoo 19 で基礎となるフォーム構造が変更された場合、一部のビューのカスタマイズは手動で確認する必要がある場合があります。移行後は、Studio のカスタマイズをすべて必ずテストしてください。
移行後に期首残高を再入力する必要がありますか?
データベースを直接移行する場合は、いいえ。すべての過去の仕訳入力と残高はデータベースに転送されます。 「データインポートを伴う新規インストール」パスを選択した場合は、カットオーバー日の期首残高を入力する必要があり、これには会計チームとの慎重な調整が必要です。
次のステップ
Odoo の移行は、ビジネスの継続性に直接影響を与える一か八かのプロジェクトです。スムーズな移行と困難な移行の違いは、準備、専門知識、および厳格なテスト方法にかかっています。
当社の移行方法論には、完全な評価、カスタム モジュールの更新、並行テスト、ロールバック手順を含む文書化されたカットオーバー計画が含まれます。
執筆者
ECOSIRE Research and Development Teamテクニカルライティング
ECOSIRE のテクニカルライティングチームは、Odoo ERP、Shopify による EC、AI エージェント、Power BI による分析、GoHighLevel による自動化、そしてエンタープライズソフトウェアのベストプラクティスを扱っています。私たちのガイドは、企業が十分な情報に基づいてテクノロジーを判断できるよう支援します。
関連記事
AI を活用した顧客セグメンテーション: RFM から予測クラスタリングまで
AI が顧客セグメンテーションを静的な RFM 分析から動的な予測クラスタリングにどのように変換するかを学びます。 Python、Odoo、および実際の ROI データを使用した実装ガイド。
サプライチェーン最適化のための AI: 可視性、予測、自動化
AI を使用してサプライ チェーンの運用を変革します。需要の検知、サプライヤーのリスク スコアリング、ルートの最適化、倉庫の自動化、混乱の予測などです。 2026年のガイド。
B2B卸売Eコマースガイド:バイヤーポータル・掛け払い・顧客別価格
バイヤーが実際に使うB2B卸売ポータルの作り方:顧客別価格、掛け払いと与信限度、発注書と承認付きチェックアウト、注文履歴からの再注文。