【完全ガイド】Microsoft Dynamics 旧版（AX/GP/NAV/SL）から Dynamics 365 への移行戦略

本記事は、Microsoft Dynamics AX 2012／Dynamics NAV／Great Plains（GP）／Solomon（SL）を10〜15年使ってきた、グローバル拠点を含む中堅企業（売上300億〜3,000億円）の情シス部長を読者として書きました。Mainstream／Extended Support のスケジュール、X++／C/AL カスタムの再実装規模、Dynamics 365 への自然移行 vs SAP／NetSuite への乗り換え——意思決定に必要な材料を、現場の仕様レベルで整理します。

1. 「Dynamics 旧版から動く」5つの理由

Dynamics 旧版は、Microsoft の戦略的後継が Dynamics 365 に明示されており、新規投資は D365 に集中しています。動く理由は次の5つ。

① Microsoftのサポート期限。AX 2012 は Microsoft ライフサイクルポリシーで延長サポートが2026年以降終了予定。NAV／GP／SL も同様に段階的終了。
② クラウドERP（D365）への一本化方針。Microsoft の新機能投資は D365 のみに。
③ グローバル統合・グループ標準化。海外拠点との統合圧力。
④ モダンUX（Web／モバイル／Power Platform連携／Copilot）。
⑤ X++／C/AL 開発者の枯渇。改修1件あたりの単価が上昇。

2. 「Dynamics 旧版から D365 が当然」とは限らない

Microsoftは D365 への移行を強く推奨していますが、「同じ移行コストをかけるなら、グループ標準に寄せる」判断が長期最適なケースもあります。三択を最初に置きます。

3. AX 2012 → D365 F&O の現実：「再実装に近い」

AX 2012 ユーザーの最も自然な移行先は Dynamics 365 F&Oです。データモデルが近く、既存業務フローが活かせる一方、「アップグレード」ではなく「再実装」と認識する必要があります。

具体的に変わる点：
・UI：MorphX / Windows クライアント → Web / Unified Interface（モダン UI）
・X++ コード：Visual Studio ベースの開発に変わり、サーバー実行方式・拡張モデル（Extension framework）が変更
・カスタム：Over-layering（オーバーレイヤリング）から Extension のみに（Layer Model 廃止）
・データベース：Azure SQL Database 前提
・レポート：SSRS／Power BI／Electronic Reporting に移行
・Workflow / Reports / Formsのカスタムは原則作り直し

「コピー移行」は不可能で、X++ コードのリプラットフォーム作業＋業務フローの再検証が発生します。

4. NAV / GP / SL → Business Central の現実

NAV ユーザーの自然な移行先は Dynamics 365 Business Centralです。NAV は元々同じコードベース由来でデータモデルが近く、Microsoft が Cloud Migration Tool を提供しています。

注意点：
・NAV → BC：データ移行ツールはあるが、C/AL 拡張は AL 言語に書き直し（Extension v2）
・GP / SL → BC：「業務再設計」前提。データモデルが大きく違うため、移行ツールの恩恵は限定的
・カスタムレポート：原則作り直し
・多くの GP / SL ユーザーは、業務見直しの好機としてSaaS（NetSuite等）も比較対象にする

5. SAP S/4HANA・NetSuite を選ぶケース

「Dynamics 旧版から D365 が当然」ではないケースは次のとおり。

・海外グループでSAPが標準：本社D365、海外SAP の二重管理を避けるため、本社もS/4HANA に寄せる。
・SaaS純度・グローバル展開重視：NetSuite の方がSaaS体験が良く、多通貨・多拠点運用が標準。
・業界専用パッケージあり：製造業ならInfor、流通業ならOracle Retail等。

判断軸は「グループ標準ERPに寄せるか、Microsoftエコシステムを継続するか」です。

6. データ移行：マスタとトランザクションの分離

Dynamics 旧版からの移行で詰まる論点：

① 勘定科目・補助科目：Chart of Accounts の再設計。10年使った AX/NAV には用途不明科目が必ず含まれる。
② 取引先（Vendor / Customer）マスタ：重複統合・名寄せが必要。
③ 商品（Item）マスタ：BOM 構造、単位変換、原価情報の引き継ぎ。製造業では特に重要。
④ トランザクション：「全件移行」は失敗の典型。マスタは全件・トランザクションは「期首残高＋直近2〜3年」に絞るのが実務的。
⑤ カスタムフィールド：旧版で追加したフィールドの新ERPでの再現可否を1つずつ確認。

7. X++／C/AL カスタムの仕分け

AX／NAV 旧版では、X++／C/AL のカスタムコードが膨らんでいるケースが大半です。移行で全再現はコスト的に不可能で、次のような仕分けを行います。

「全部移植」と「全部捨てる」の中間の具体的な削減率を経営に提示することが、移行費の見積もりを現実的なレンジに収める鍵です。

8. ライセンス・契約形態の変化（重要）

Dynamics 旧版の永久ライセンス＋年間保守から、D365 のサブスクリプション課金に移ることで、年額のキャッシュフローが大きく変わります。

具体的には：
・D365 F&O：$210/user/月（Full User、リスト・USD）が基本
・D365 BC：$100/user/月（Premium、リスト・USD）
・Activity User（参照・軽い処理用）：$30〜80/user/月
・Team Member（読み取り中心）：$8/user/月
・Power Platform：別課金または D365 込み

Microsoft の D365 ライセンス情報を必ず確認し、ユーザー区分（Full / Activity / Team）を最適化することで、年額が大きく変わります。

9. プロジェクト期間の典型値（500〜1,500名規模）

10. 3年TCOの実数試算（1,000名規模）

注意：割引交渉余地が大きいため、経営への提示は実見積を使ってください。

11. 失敗事例から逆算する「やってはいけない3つ」

① AX→F&O を「アップグレード」と誤認して再実装規模を過小見積。「データはコピー、UIだけ新しく」と説明して予算化し、X++ コードの拡張モデル変更で実装規模が3倍に膨れ、12カ月遅延。
② 既存カスタムを全再現してアドオン地獄。AX 2012 の200本のX++拡張をすべてD365 で再現した結果、Microsoftの新機能リリース追従が困難に。
③ NAV→BC の移行ツールを過信して業務再設計を省略。Cloud Migration Tool でデータは移ったが、C/AL → AL 拡張の書き直しと業務フロー再設計を後工程で実施することになり、結果的に3カ月のロス。

12. 来期予算化までに、いま動かす3アクション

① X++／C/AL カスタムの棚卸しを今期中に完了する。本数・直近12カ月の改修頻度・廃止候補を一覧化。これが移行費の根拠になります。
② Microsoft パートナー（D365）／SAPパートナー／NetSuite パートナーの3社からアセスメント提案を取る。同じ前提条件で比較することで、「Microsoft 一択」の思い込みが解けます。
③ ライセンス区分（Full／Activity／Team）の最適化シミュレーションを実施する。ユーザー区分次第でD365 の年額は2〜3倍変わります。

Dynamics 旧版の今後3年は、「D365 への自然移行か、グループ標準ERP（SAP／NetSuite）に寄せるか、延命か」を根拠付きで経営に提示できる状態を作ることがゴールです。