Odoo 17 から Odoo 18 への移行: 変更点、変更点、および準備方法

Odoo は毎年メジャー バージョンをリリースし、アップグレードするたびに新機能、パフォーマンスの向上、そして必然的に重大な変更がもたらされます。 Odoo 17 から Odoo 18 への移行には、特にカスタム モジュールを実行する場合やコミュニティ アドオンに依存する場合には、慎重な計画が必要です。このガイドでは、主要な変更点、潜在的な破損、準備手順、テスト戦略など、Odoo 17 から 18 への移行について知っておくべきことをすべて説明します。

Odoo 18 にアップグレードする理由?

Odoo 18 では、プラットフォーム全体に大幅な改善が加えられています。

• 新しいOWL 3コンポーネント: フロントエンドコンポーネントが書き直され、パフォーマンスと開発者のエクスペリエンスが向上しました。
• AI を活用した機能: 予測リード スコアリング、スマートバンク照合提案、AI 支援コンテンツ作成
• スプレッドシートの改善: リアルタイムの Odoo データ、ピボット テーブル、および共同編集とのネイティブ スプレッドシートの統合
• 製造のアップグレード: 生産スケジュール、下請けポータル、および製造現場のタブレット インターフェイスの改善
• パフォーマンス: 最適化されたアセット バンドルと遅延読み込みにより、ページの読み込みが 15 ～ 25% 高速化
• ウェブサイト ビルダー: 新しいドラッグ アンド ドロップ ブロック、テーマのカスタマイズ オプション、モバイル編集の改善

古いバージョンを使い続けると、セキュリティ パッチが適用されず、コミュニティ モジュールのアップデートにアクセスできなくなり、将来の移行が困難になる技術的負債が蓄積されることになります。

タイムライン: Odoo の移行にはどのくらい時間がかかりますか?

|複雑さ |カスタムモジュール |推定スケジュール | |---|---|---| |標準 (カスタム コードなし) | 0 | 1～2週間 | |低 (カスタム フィールド/ビューが少ない) | 1-5 | 2～4週間 | |中 (カスタム ワークフロー) | 5-15 | 4～8週間 | |高 (深いカスタマイズ) | 15 歳以上 | 8～16週間 |

これらのタイムラインには、分析、移行、テスト、稼働開始が含まれます。最大の変数はカスタム モジュールの複雑さです。

Odoo 18 の重大な変更点

OWLフレームワークの変更

Odoo 18 は OWL 3 への移行を継続します。カスタム モジュールにフロントエンド JavaScript コンポーネントが含まれている場合は、次の変更が予想されます。

OWLの主な変更点:

• コンポーネントのライフサイクル: willStart および willUpdateProps は setup() および onWillStart フックに置き換えられます
• テンプレートのコンパイル: QWeb テンプレートは、実行時ではなくビルド時に最適化された JavaScript にコンパイルされるようになりました。
• サービス インジェクション: this.env.services パターンを通じて排他的にサービスにアクセスします。直接インポートは廃止されました
• アセット バンドル: web.assets_backend バンドル構造が変更されました。 __manifest__.py アセット宣言を更新します

移行の例:

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

Python バックエンドの変更

モデルとフィールドの変更:

• fields.Monetary では、currency_field を明示的に宣言する必要があります (デフォルトは currency_id ではなくなりました)
• @api.multi デコレータは完全に削除されました (v13 以降非推奨になりましたが、一部のコミュニティ モジュールはまだ使用していました)
• sudo() の動作変更: 引数なしの sudo() は、OdooBOT ユーザーではなく SUPERUSER を明示的に使用するようになりました。
• search_count() は、パフォーマンスの最適化のためにオプションの limit パラメーターを受け入れるようになりました

非推奨の更新メソッド:

|非推奨 (v17) |置換 (v18) | |---|---| | コード0 | fields.Many2one と domain 属性 | | コード0 |マニフェスト内の _post_init_hook | |モデル内の直接 SQL |適切なパラメータ化を使用した self.env.cr.execute() | | website.published フィールド | website.is_published (名前変更) |

ビューとテンプレートの変更

• フォーム ビュー: sheet ラッパーはすべてのフォーム ビューで必須になりました (以前はオプションでした)
• リスト ビュー: tree タグの名前が正式に list に変更されました (下位互換性のあるエイリアスは引き続き機能しますが、非推奨の警告が表示されます)
• カンバン ビュー: QWeb t-esc がデフォルトになりました。 t-raw ではセキュリティのために明示的なオプトインが必要です
• QWeb レポート: PDF レンダリング エンジンが更新されました。印刷されたすべてのレポートのレイアウト変更をテストする

データベーススキーマの変更

Odoo 18 には、コア テーブルの構造変更が含まれています。

• sale.order.line はサブスクリプション管理用の新しいフィールドを取得します
• account.move.line には、新しい調整関連の列が含まれています
• stock.quant テーブルが再構築され、大規模なインベントリでのパフォーマンスが向上しました
• 新しいインデックスで最適化された mail.message テーブルと mail.activity テーブル

これらのスキーマ変更は、標準モジュールの Odoo 組み込み移行スクリプトによって処理されますが、これらのテーブルを参照するカスタム モジュールは手動で更新する必要があります。

移行前準備チェックリスト

1. 現在のインストールを監査する

開始する前にすべてを文書化します。

• [ ] インストールされているすべてのモジュール (公式、コミュニティ、カスタム) をリストします。
• [ ] 現在の Odoo バージョンとパッチ レベルを記録します
• [ ] すべてのカスタム開発 (フィールド、モデル、ビュー、レポート、スケジュールされたアクション) を文書化します。
• [ ] すべての外部統合をリストします (支払いゲートウェイ、配送業者、サードパーティ API)
• [ ] 現在のアクセス権をエクスポートし、ルール設定を記録します
• [ ] 運用データベースとファイルストアを完全にバックアップします

2. コミュニティモジュールの互換性を確認する

各コミュニティ (OCA またはサードパーティ) モジュールについて:

• Odoo 18 と互換性のあるバージョンが GitHub または Odoo Apps ストアに存在するかどうかを確認します
• 互換性のあるバージョンが存在しない場合は、モジュールを自分で移植するか、代替案を見つけるか、機能を削除するかを決定します。
• v18 ポートの ETA についてはモジュール メンテナに連絡してください

3. カスタムモジュールポートの準備

カスタム モジュールごとに、移行作業を評価します。

低労力 (モジュールごとに 1 ～ 3 日):

• 新しいフィールドと単純なビューのみを含むモジュール
• JavaScript/OWL コンポーネントなし
• 変更されたコアメソッドをオーバーライドしない

中程度の作業 (モジュールごとに 3 ～ 10 日):

• アップデートが必要なOWLコンポーネントを含むモジュール
• 非推奨または変更されたコアメソッドのオーバーライド
• QWeb の更新が必要なカスタム レポート

多大な労力 (モジュールごとに 10 日以上):

• 変更されたコアモジュール（会計、在庫、ウェブサイト）との緊密な統合
• 複雑なOWLフロントエンドアプリケーション
• 非推奨または削除された API を広範囲に使用するモジュール

経験豊富な Odoo 移行スペシャリスト と協力することで、カスタム モジュールの移植にかかる時間とリスクが大幅に削減されます。

移行の実行手順

ステップ 1: 移行環境のセットアップ

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

以下を使用して隔離された環境を作成します。

• 新しい Odoo 18 サーバーのインストール
• 運用データベースのコピー
• すべてのカスタム モジュールが v18 に移植されました

ステップ 2: データベースのアップグレードを実行する

Odoo Enterprise の場合: Odoo の公式アップグレード サービス (upgrade.odoo.com) を使用します。データベースをアップロードすると、Odoo SA がすべての標準モジュールの移行スクリプトを実行します。

Odoo コミュニティの場合: OCA の openupgrade プロジェクトを使用します。 OpenUpgrade は、コミュニティが管理する標準モジュール用の移行スクリプトを提供します。

1. 対象バージョンの OpenUpgrade をインストールします
2. テスト データベースに対して移行を実行します。
3. 移行ログでエラーと警告を確認します。
4. 問題があれば修正し、クリーンになるまで再実行します。

ステップ 3: カスタム モジュールを移植する

各カスタム モジュールについて:

1. __manifest__.py バージョンを 18.0.x.x.x に更新します
2. Python コードを修正 (非推奨の API、変更されたメソッド シグネチャ)
3. JavaScript/OWL コンポーネントを v3 パターンに更新します
4. XML ビューを修正 (ツリーからリストへ、シート ラッパー、テンプレートの変更)
5. モジュールのテスト スイートを実行し、障害を修正します
6. ステージング環境で手動でテストする

ステップ 4: データの検証

移行後、データの整合性を確認します。

• 会計: v17 と v18 の間で試算表の合計を比較します。それらは正確に一致する必要があります。
• 在庫: 高額製品のサンプルの在庫数量を確認します。
• 販売/購入: 未処理の注文とそのステータスが正しく引き継がれていることを確認します。
• 連絡先: 住所や銀行の詳細を含む、顧客とベンダーの記録が損なわれていないことを確認してください。
• 添付ファイル: ドキュメント、画像、添付ファイルにアクセスできることを確認します。

テスト戦略

レベル 1: 自動テスト

インストールされているすべてのモジュールに対して完全なテスト スイートを実行します。続行する前にすべての障害を修正してください。

レベル 2: 機能テスト

コア ビジネス ワークフローをエンドツーエンドでテストします。

・見積書作成、確認、納品、請求書作成、入金登録

• 領収書と仕入先請求書を通じて注文書を処理します
• BOM から完成品まで製造オーダーを実行します
• 完全な銀行調整サイクルを完了する
• 主要な財務報告書の生成と検証

レベル 3: ユーザー受け入れテスト (UAT)

各部門の実際のユーザーに、ステージング環境で 5 ～ 10 営業日の日常タスクを実行してもらいます。共有スプレッドシートまたはプロジェクト管理ツールで問題を追跡します。

レベル 4: パフォーマンス テスト

v17 と v18 の間で、実稼働レベルのデータ量を使用してページの読み込み時間、レポート生成速度、検索パフォーマンスを比較します。

ゴーライブ戦略

推奨されるアプローチ: 週末の移行

1. 金曜日の夕方: 最終的な運用バックアップを作成します。すべての取引を凍結します。
2. 土曜日: 運用データベースでアップグレードを実行します。直前のデータを移植します。
3. 日曜日: データ検証と煙テストを完了します。運用サーバーにデプロイします。
4. 月曜日の朝: ライブを開始します。最初の 48 時間は注意深く観察してください。

ロールバック計画を準備してください。重大な問題が発生した場合に数時間以内に元に戻せるように、v17 データベースのバックアップとサーバー構成を利用可能な状態に保ちます。

よくある質問

Q: バージョンをスキップして、Odoo 16 から Odoo 18 に直接移行できますか? はい、しかし、それはより複雑です。各バージョンには独自の移行スクリプトがあり、バージョンをスキップすると変更がさらに複雑になります。 Odoo のアップグレード サービスは複数バージョンのジャンプを処理しますが、カスタム モジュールの移植では、スキップされたすべてのバージョンからの重大な変更に対処する必要があります。複数バージョンの移行に 50 ～ 100% 多くの時間を割り当てます。

Q: 移行中にカスタム レポートは壊れますか? 潜在的に。 QWeb レポート テンプレートは、データ構造の更新とレンダリング エンジンの改善により、バージョン間で頻繁に変更されます。移行後にすべての印刷レポート (請求書、納品書、発注書) をテストし、必要に応じてテンプレートを調整します。

Q: 移行するべきですか、それとも新たに始めるべきですか? 長年にわたる履歴データ、複雑な構成、トレーニングを受けたユーザーがある場合は、移行してください。現在のインストールが修復できないほど大幅にカスタマイズされている場合、重大なデータ品質の問題がある場合、またはビジネス プロセスが大幅に変更されたため再構成の方が早い場合は、最初からやり直してください。ほとんどの企業は、運用履歴を保存するために移行を選択します。 Odoo コンサルタント パートナー に相談して、どのアプローチが自分の状況に適しているかを評価してください。

専門的な移行サポート

Odoo バージョン間の移行は、経験豊富な人材の恩恵を受ける技術プロジェクトです。 ECOSIRE の Odoo 移行サービス は、移行前監査、カスタム モジュールの移植、データ移行、テスト、本番稼働サポートなどの完全なプロセスをカバーします。

特定の Odoo インストールに基づいた移行評価とタイムラインの見積もりについては、チームにお問い合わせください。お客様のモジュール、カスタマイズ、データの複雑さを分析して、正確な範囲と予算を提供します。