基幹システムのクラウド化とは、会計・販売・購買・在庫・生産・人事給与といった、止まると事業が止まるシステムを、自社のサーバー室からクラウド基盤やSaaSへ移すことです。情報系のメールやファイル共有を移すのとは違い、月次の締めや出荷と直結しているため、移し方を誤ると請求書が出せない、在庫が合わないといった実害がすぐに出ます。
この記事では、なぜ今クラウド化が議題に上がるのかという背景と、現状調査から旧環境の停止までの移行手順を6つの工程に分けて説明します。クラウドとオンプレミスのどちらを選ぶかという判断そのものは基幹システムをクラウドとオンプレミスのどちらで持つかの選び方で扱っており、ここでは「移すと決めた後に何をどの順で進めるか」に絞ります。
まとめ：基幹システムのクラウド化を進める手順の結論
- クラウド化が議題に上がる直接の引き金は、OSやERPのサポート期限です。Windows Server 2016の延長サポートは2027年1月12日、SAP ERP 6.0（EhP6〜8）のメインストリーム保守は2027年末に終わります。
- クラウドを使う企業はすでに多数派です。総務省の令和7年通信利用動向調査では、クラウドサービスを利用している企業は83.4%でした。
- 移行は「現状調査→方式の割り当て→PoC→データ移行リハーサル→本番切替→旧環境の停止」の6工程で進めます。
- 方式はシステム単位で決めます。会計はSaaSへ置き換え、独自の生産管理はIaaSへ載せ替え、使われていない帳票サーバーは廃止、というように1社の中で混在するのが普通です。
- 見落とされやすいのはソフトウェアライセンスと法定保存データです。Oracle Databaseはクラウドで数え方が変わり、法人税関係の帳簿書類には原則7年、対象となる欠損事業年度等には10年（一部の旧事業年度は9年）の保存義務があります。必要なデータと参照・出力手段を適法に移管できれば、旧環境自体は廃止できます。
以下、背景、6つの工程、落とし穴の順に説明します。
基幹システムのクラウド化が進む背景：老朽化とサポート期限
老朽化した基幹システムで起きる問題と刷新の引き金
基幹システムの老朽化で困るのは、古いこと自体ではなく、直せる人と部品と保守契約がなくなることです。経済産業省は2018年9月7日公表のDXレポートで、複雑化・老朽化・ブラックボックス化した既存システムが残った場合、2025年以降に最大12兆円／年の経済損失が生じる可能性があると試算し、これを「2025年の崖」と呼びました。
実務で刷新の時期を決めるのは、この試算よりも個別の期限です。通常の保守終了後にセキュリティ修正を受けられるかは、延長保守や追加更新プログラムの契約条件によります。SAP ERP 6.0の対象版には2030年末までの延長保守の選択肢もあるため、利用できる保守と終了後の対策を確認します。代表的な期限は次のとおりです。
- Windows Server 2016：延長サポート終了 2027年1月12日
- SAP ERP 6.0（EhP6〜8）：メインストリーム保守終了 2027年末（EhP5以前は2025年末に終了済み）
- サーバー機器：保守部品の供給期限（メーカーと機種ごとに異なるため保守契約書で確認）
期限の一覧と、期限までにクラウドへ移すかオンプレミスで更新するかの判断は導入形態の選び方の記事にまとめています。レガシーシステムそのものの定義や判定基準はレガシーシステムとは何かを経産省の定義から整理した記事を参照してください。
クラウド利用率83.4%という前提と基幹系が後回しになる理由
総務省の令和7年通信利用動向調査（2025年8月末時点、2,489社）では、クラウドサービスを「全社的に利用している」企業が59.9%、「一部の事業所または部門で利用している」企業が23.5%で、合計83.4%がクラウドを使っています。
ただし、この数字はメールやファイル共有を含めた利用率です。基幹系が最後まで社内に残りやすいのは、他のシステムとの連携本数が多く、止められる時間が短く、帳票や独自の計算ロジックが長年の改修で積み上がっているためです。裏返すと、クラウド化では、サーバーの移設に加え、連携の変更、データ整備、業務日程の調整にも工数を見込む必要があります。以下の6工程はその順序です。
基幹システムのクラウド移行手順：現状調査から旧環境の停止までの6工程
工程1 現状調査：サーバー・周辺連携・ライセンスの棚卸し
最初に作るのは、サーバーの一覧ではなく連携の一覧です。基幹システムは、EDIで受けた受注データ、夜間バッチで会計へ流す仕訳、倉庫システムへ送る出荷指示、銀行へ送る振込データなど、周辺システムとファイルやDBで直接つながっています。担当者が不明な連携は、移行時の確認から漏れるおそれがあります。AWSの移行計画でもシステム間の依存関係を調査対象としており、連携ごとに確認担当者を決めます。
棚卸しでは、システムごとに次の項目を書き出します。
- 稼働しているサーバー、OSとミドルウェアの版、保守期限
- 入出力の連携先、方式（ファイル転送・DB直結・API）、実行時刻
- ソフトウェアライセンスの種類と契約条件（後述のとおりクラウドで数え方が変わる）
- 利用部門と、月次・年次で負荷が跳ねる時期
ここでライセンスを調べておかないと、方式を決めた後で費用が合わなくなります。
工程2 移行方式の割り当て：7Rによるシステム別の分類
棚卸しが済んだら、システムごとに移し方を割り当てます。AWSは移行戦略を7つ（7R）に分けて定義しており、基幹システムに当てはめると次のようになります。
| 戦略 | AWSの定義の要点 | 基幹システムでの典型例 |
|---|---|---|
| Retire | 廃止またはアーカイブ | 使われていない帳票・検索サーバー |
| Retain | 移行元に残す | 設備と直結する工場内の実績収集 |
| Rehost | 変更せずに移す | 独自開発の販売管理をIaaSへ |
| Relocate | アーキテクチャを変えず基盤ごと移す | VMware上の仮想サーバー群 |
| Replatform | 一部を最適化して移す | 自社運用のDBをマネージドDBへ |
| Repurchase | 別製品へ置き換える | 会計・人事給与をSaaSへ |
| Refactor | アーキテクチャを変更する | 受注処理をAPI化して作り直す |
基幹システムで判断を誤りやすいのはRehostです。アプリケーションの変更を抑えられる一方、OSとミドルウェアの保守責任は利用企業側に残ります。Windows Server 2016のままIaaSへ載せても、2027年1月12日の期限は何も変わりません。保守期限が移行の動機なら、Rehostと同時にOSを上げるか、Replatform以上を選びます。各戦略の割り当て基準とAWSの移行ツールはAWS移行の7R戦略と移行ツールの記事で詳しく扱っています。
工程3 PoCと非機能要件：応答時間・閉域接続・復旧目標
方式が決まったら、本番規模のデータの一部を使ってPoC（概念実証）を行います。PoCでは応答時間や復旧性を重点的に確かめます。SaaSへの置き換えやアプリケーション改修を伴う場合は、業務機能と周辺連携の適合性も検証対象に含めます。
- 応答時間：拠点や工場からクラウドまでの往復遅延で、画面操作やバッチの処理時間が延びないか
- 接続方式：インターネット経由のVPNで足りるか、専用線の閉域接続が要るか
- 復旧目標：障害時に何時間で戻すか（RTO）、どの時点のデータまで戻すか（RPO）
夜間バッチはとくに注意が必要です。オンプレミスでは同じ建物内のDBに直結していた処理が、クラウド移行後に拠点側のファイルサーバーを読みに行く構成になると、1件ごとの往復遅延が積み重なって朝までに終わらなくなることがあります。閉域接続の選び方はAzure ExpressRouteの専用線接続とSKU選定の記事が参考になります。
工程4 データ移行設計とリハーサル：マスタ・残高・未完了取引
基幹システムのデータ移行は、ファイルを丸ごとコピーすれば済むものではありません。代表的な移行対象には、次の3種類があります。過去の取引履歴や添付証憑などは、移行する範囲と別途保存する範囲を分けて決めます。
- マスタ：取引先・品目・勘定科目。重複や表記ゆれを移行前にクレンジングする
- 残高：売掛金・買掛金・在庫数量。切替時点の値が旧システムと一致するかを突き合わせる
- 未完了取引：受注残・発注残・仕掛品。新システムで続きを処理できる形に変換する
IPAの「システム再構築を成功に導くユーザガイド 第2版」（2018年2月23日発行）は、テストの開始前に、クレンジングしたデータを検証環境へ移すリハーサルを行い、不整合が見つかれば修正してリハーサルをやり直すことを想定しています。同じ箇所（p.119）は、サイクルテストで1年間のデータを日回しする場合、その分の現行データを1年前から用意しておく必要があるとも書いています。リハーサルは1回で終わる前提で日程を組まないことが要点です。本番切替と同じ手順・同じデータ量で通し、所要時間を実測して、切替当日に使える時間に収まるかを確かめます。
転送経路（ネットワーク転送か物理搬送か）や差分同期（CDC）による停止時間の短縮はクラウドデータ移行の手順と移行ツールの記事で扱っています。
工程5 本番切替：業務カレンダーに合わせた日程と切り戻し判定
切替日は技術の都合ではなく業務カレンダーで決めます。月次締め・決算・棚卸し・賞与計算の直前は避け、残高の確定後で、移行・照合・切り戻しの時間を確保できる停止枠を選びます。例えば停止枠が48時間なら、その全時間を移行作業に充てず、切り戻し所要時間を先に差し引いて判定時刻を決めます。期首に合わせると、旧システムと新システムで会計期間が分かれ、残高の突き合わせが単純になります。
当日の手順書には、切り戻しの判定時刻を必ず書きます。「何時までに残高照合が一致しなければ旧システムで翌営業日を迎える」と事前に決めておかないと、作業が押したまま始業時刻を迎え、どちらのシステムも使えない状態になります。並行稼働（新旧を一定期間同時に動かす方式）は安全に見えますが、利用部門が二重入力を負担するため、期間と対象業務を絞って使います。
移行の工程で実際に出荷停止や訴訟に至った事例は基幹システム刷新の失敗事例と回避策で工程別に分解しています。
工程6 移行後：旧環境の停止と保存義務のあるデータ
本番切替後に旧環境を停止できるかは、保存対象データと参照・出力手段の移管状況で決まります。保存が求められているのは帳簿書類とそのデータで、旧サーバーを動かし続けること自体ではありません。移行後にまず行うのは、クラウドの利用料を月次で確認する体制づくりと、旧環境で動かし続けるものを「過去データの参照」だけに絞ることです。サーバーを止めてもデータを読める状態（エクスポートしたデータと参照手段）を用意できた時点で、旧環境を停止します。
基幹システムのクラウド化で見落とされやすい2つの論点：ライセンスと法定保存
クラウドで数え方が変わるOracle DatabaseとMicrosoft製品のライセンス
オンプレミスで買ったライセンスは、そのままクラウドへ持ち込めるとは限りません。
Oracleは「Licensing Oracle Software in the Cloud Computing Environment」で、Amazon EC2・Amazon RDS・Microsoft Azure上では、プロセッサコアのマルチスレッディングが有効なら2 vCPUを1 Processorライセンス、無効なら1 vCPUを1 Processorライセンスとして数える方針を示しています。この計算ではインスタンスタイプの最大vCPU数を用います。ただしStandard Edition系には別の換算規則があり、4 vCPUまでを1ソケット、それを超える場合は4 vCPUごとに切り上げて数えます。契約上の利用権も別途確認が必要です。オンプレミスで使っていたコア係数による計算とは別のルールなので、同じ性能のサーバーに移したつもりでも必要なライセンス数が変わることがあります。AWS上でのOracleの選択肢と費用はAWSでOracleを動かす選択肢とライセンスの数え方の記事で整理しています。
Microsoftは2019年10月1日にライセンス条件を変更しました。同日前に購入したライセンスで既存バージョンを利用する場合などの例外を除き、Software Assuranceやモビリティ権のないオンプレミスのライセンスを、Microsoft・Alibaba・Amazon・Googleの4社（Listed Providers）の専用ホストへは持ち込めません。共有環境へ持ち込むLicense Mobility through Software Assuranceも、有効なSoftware Assurance（SA）があり、対象パートナーごとに検証フォームを提出することが条件です。SQL ServerではSAとLicense Mobility through Software Assuranceの適用条件を確認します。Windows Serverはこの特典の対象外です。Azure Hybrid Benefitなど別の権利、ライセンスの取得日・バージョン、移行先の条件を確認してください。
旧システムの帳簿データを消せない期間：7年・10年と電子取引データ
会計システムを移すとき、旧システムに残る過去の帳簿をどうするかは移行計画の段階で決めておきます。法人税法施行規則59条は、青色申告法人に帳簿書類を7年間保存するよう求めており、国税庁の案内では、青色申告書を提出した欠損金額の生じた事業年度などは10年間、2018年4月1日前に開始した事業年度は9年間の保存が必要です。保存期間は、その事業年度の確定申告書の提出期限の翌日から数えます。
加えて、2024年1月1日以後の電子取引では、PDFなどで受け取った請求書や領収書をデータのまま保存する必要があり、印刷した紙だけでは足りません。旧システムにこうしたデータが紐づいている場合、新システムへ移すか、旧データを検索できる形で別に保管するかのどちらかを選びます。新システムへ全件を移すとデータ移行の範囲が膨らむため、直近数年分だけを移し、それ以前は読み取り専用の保管先に置く構成も選べます。その場合も、保存期間を通じてデータを保持し、電子取引データには改ざん防止措置や速やかな表示・出力などの保存要件を満たす必要があります。検索要件には一定の条件による免除があるため、自社に適用される要件を確認します。
よくある質問
基幹システムのクラウド化とオープン化は何が違いますか？
オープン化は、メインフレームやオフコンのような特定メーカーの専用機から、WindowsやLinuxなど汎用のOSとサーバーへ移すことを指します。クラウド化は、そのサーバーを自社で持たずにクラウド基盤やSaaSへ移すことです。専用機からクラウドへ直接移す場合は、オープン化とクラウド化を同時に行うことになり、言語やデータ形式の変換まで工程に入ります。
老朽化した基幹システムはいつまでに刷新すべきですか？
目安は、使っているOS・ERP・サーバー機器の保守期限のうち最も早いものです。そこから、現状調査・PoC・データ移行リハーサルに要する期間を逆算して着手時期を決めます。期限の直前に着手すると、リハーサルをやり直す余裕がなくなります。
業務を止めずに基幹システムをクラウドへ移行できますか？
停止時間をゼロにするのは難しく、多くは連休などの業務停止枠の中で切り替えます。差分同期で停止時間を短くすることはできますが、残高照合と切り戻し判定の時間は必要です。停止できる時間を利用部門と先に合意し、その時間に収まるかをリハーサルで実測します。
基幹システムのクラウド移行ではデータ移行のリハーサルを何回行いますか？
回数は決まっておらず、本番と同じ手順で不整合が出なくなり、所要時間が切替枠に収まるまで繰り返します。IPAのユーザガイドも、不整合の修正と再リハーサルが発生する前提で説明しています。日程には再実施の枠をあらかじめ入れておきます。
クラウドへ移した基幹システムをオンプレミスへ戻すことはできますか？
IaaSへRehostしたシステムは、対応する形式でのVMエクスポートや再構築、データ移行が可能なら戻せます。ただし、AWSのVM Import/Exportにもイメージやソフトウェアによる制限があるため、持ち帰り方法とライセンス条件を事前に確認します。SaaSへ置き換えた場合は、戻すのではなく別システムへの再移行になり、エクスポートできるデータの形式と範囲に左右されます。SaaSを選ぶときは、契約前にデータの取り出し方法を確認しておきます。
