システム移行は段階的か一括か：ビッグバン移行との違いと選び方

システム移行を段階的に進めるか、一度にすべてを切り替えるか（ビッグバン移行）は、「業務停止をどこまで許容できるか」「新旧のシステムのあいだでデータがどれだけ密につながっているか」「移行期間中の費用と手間をどこまで負えるか」の三つで判断します。業務を止めにくく、機能同士の結びつきが比較的ゆるいなら段階移行が向いています。逆に、データが密に絡み合っていて新旧を同時に動かすのが難しく、切り替え日に一定の業務停止を確保できるなら、一括移行のほうが全体の費用とリスクを抑えられることがあります。

どちらが優れているという答えはありません。段階移行は一度に失敗する範囲を小さくできる一方で、新旧が共存する期間のデータ連携や二重運用の負担が生まれます。一括移行は移行期間が短く仕組みも単純ですが、切り替え当日にすべてのリスクが集中します。多くの現場では、純粋などちらかではなく、データは一括で移しつつ利用者は部署ごとに順番に切り替える、といった組み合わせで設計されています。

この記事は、システムのリプレイスやクラウドへの移行を控え、移行方式を決めなければならない事業責任者や情報システム担当者に向けて書いています。両方式の違い、選び方の判断基準、段階の切り方、それぞれのリスクへの備え、よくある失敗を順に整理します。

段階移行と一括移行（ビッグバン移行）の違い

最初に、二つの方式の違いを整理します。

一括移行は、ある日時を境に、旧システムのすべての機能と利用者を新システムへ一度に切り替える方式です。旧システムを停止し、データを移し、新システムで業務を再開します。切り替えが一度で済むため、新旧が共存する期間がほとんどなく、仕組みは単純です。一方で、問題が起きたときの影響は全業務に及びます。

段階移行は、機能、拠点、部署、顧客の区分などの単位に分けて、順番に新システムへ切り替えていく方式です。一回ごとの切り替えの範囲が小さいため、問題が起きても影響を限定でき、先の段階で得た教訓を次の段階に生かせます。ただし、移行期間中は新旧のシステムが並んで動くため、両者のデータをどう整合させるかという課題が生まれます。

なお、段階移行とよく混同される方式に並行稼働があります。並行稼働は、同じ業務を新旧両方のシステムで一定期間処理し、結果を比べてから旧システムを止める方法です。段階移行と組み合わせることもあれば、一括移行の直前の確認として行うこともあります。

移行方式を選ぶ三つの判断軸

方式を選ぶ際に最も重要な三つの判断軸を順に見ていきます。

業務停止をどこまで許容できるか

一括移行では、旧システムを止めてから新システムで業務を再開するまでのあいだ、業務が止まります。データの量によっては、この時間が長くなることもあります。夜間に動くバッチ処理や、外部との定期的なデータ連携が止まる影響も含めて、停止の範囲を考える必要があります。夜間や週末、連休に切り替えることで影響を抑えられる業務であれば、一括移行の現実味は高まります。

一方、二十四時間止められないサービスや、取引先と常時データをやり取りしている業務では、長い停止は許されません。この場合は、データを事前に移して差分だけを同期する、利用者の一部から順に切り替える、といった段階的な工夫が必要になります。

機能やデータの結びつきの強さ

段階移行を選ぶには、システムを「切り分けられる」ことが前提になります。たとえば、受注、在庫、請求が同じデータを共有し、互いに密に参照し合っている場合、受注だけを新システムに移すと、在庫と請求は旧システムに残るため、新旧のあいだでデータを常に同期させる必要が生じます。この同期の仕組みは、それ自体が一つの開発案件になるほど複雑になることがあります。

逆に、拠点ごとにデータが独立している、顧客の区分ごとに業務が完結している、といった構造であれば、段階に分けても新旧の連携は最小限で済みます。

移行期間中の費用と体制

段階移行では、新旧の連携の仕組み、二重運用の手間、複数回の移行作業とテスト、旧システムの保守費用の延長が加わります。移行期間が長くなれば、そのぶん新旧両方の保守体制を維持しなければなりません。一括移行に比べて安全に見える段階移行も、期間中の負担を見積もると、思った以上に費用がかかることがあります。

方式を決める手順

移行方式は、次の手順で検討すると、関係者の合意を得やすくなります。

1. 業務ごとに、許容できる停止時間を業務部門に確認する。繁忙期と閑散期で許容度が違う場合はそれも記録する。
2. 機能とデータの関係を図にし、どこで切り分けられるか、切り分けた場合に新旧のあいだでどんなデータのやり取りが必要かを洗い出す。
3. 一括移行の場合の停止時間を、データ量と移行リハーサルの見込みから概算する。
4. 段階移行の候補となる切り方（機能別、拠点別、顧客区分別など）を複数挙げ、それぞれの連携の仕組みと二重運用の負担を整理する。
5. 一括移行と、段階移行の各案について、期間、費用、リスク、利用者の負担を比較表にまとめる。
6. 業務部門、経営層、開発会社で比較表を確認し、方式を決める。決めた理由と前提条件を記録する。

手順2で作る図は、移行方式の判断だけでなく、データ移行計画や切り戻しの計画にもそのまま使えます。データ移行の具体的な計画の立て方はリプレイス時のデータ移行計画：移行リハーサルと切り戻しの準備で解説しています。

段階移行の切り方のパターン

段階移行を選ぶ場合、どの単位で段階を切るかが成否を左右します。代表的な切り方と、それぞれの向き不向きを整理します。

機能別に切る。 マスタ管理、受注、出荷、請求のように、業務機能の単位で順に移す方法です。データの流れの上流から移すと、後の段階で必要なデータが新システムに揃っている状態を作れます。ただし、機能間の結びつきが強いと、新旧の連携が複雑になります。

拠点・部署別に切る。 ある支店や部署から新システムを使い始め、順に広げていく方法です。最初の拠点を、協力的で規模が小さく、問題が起きても影響を抑えられる拠点にすると、そこで得た教訓を次に生かせます。拠点ごとにデータが独立している場合に向いています。

顧客・取引の区分別に切る。 新規顧客から新システムで扱い、既存顧客は順に移す、あるいは特定の商品やサービスの取引だけを先に移す方法です。自社サービスのリプレイスでは、新規登録の利用者から新しい仕組みを使ってもらい、既存の利用者は後から移すという形がよく選ばれます。

画面と裏側を分けて切る。 利用者が触る画面だけを先に新しくし、裏側の処理やデータベースは旧システムを使い続け、後から順に置き換える方法です。旧システムの外側を新しい仕組みで包み、内側を少しずつ入れ替えていく考え方で、大規模なシステムを止めずに作り直す場合に用いられます。

どの切り方でも、各段階が終わった時点で業務が成立していることが条件です。途中の段階で「この業務だけは新旧どちらでもできない」という状態が生まれないよう、段階ごとの業務の流れを確認してください。

それぞれの方式のリスクと備え方

一括移行のリスクと備え

一括移行の最大のリスクは、切り替え当日にすべての問題が集中することです。このリスクに備えるには、リハーサルを本番と同じ条件で複数回行い、移行にかかる時間と手順の不備を事前に潰しておくことが欠かせません。

あわせて、切り戻しの準備を厚くしておきます。どの状態になったら旧システムに戻すかという判断基準、判断者、手順、切り戻しが可能な期限を決め、リハーサルで実際に試しておきます。切り替え直後の数週間は、開発会社の体制を手厚くし、問い合わせ窓口を一本化して、問題を早く拾える状態を作ります。

段階移行のリスクと備え

段階移行のリスクは、新旧の共存期間に生じるデータの不整合と、移行が長引くことです。新旧のあいだでデータを同期する仕組みを作る場合は、同期が失敗したときの検知と再実行の方法、どちらのデータを正とするかのルールを決めておきます。連携の障害対策の考え方はAPI連携の障害対策：リトライ設計とデータ不整合への備え方も参考になります。

移行が長引くと、旧システムへの改修要望が続き、新旧両方に同じ変更を加える二重の作業が発生します。段階移行の期間中は、旧システムへの変更を原則として止め、必要な変更は新システム側でだけ行うルールを決めておくのが有効です。また、全段階の完了日と旧システムの停止日を最初に決め、段階ごとの進み具合を定期的に確認してください。

移行方式によって見積もりで確認すべき点

移行方式が変わると、開発会社の見積もりに含まれる作業も変わります。複数社から見積もりを取る場合、前提とする移行方式が揃っていないと金額を正しく比べられません。見積もりを依頼する際は、想定している方式を伝え、次の点が含まれているかを確認してください。

一括移行の場合は、移行ツールの作成、移行リハーサルの回数、本番移行当日の作業体制、切り戻しの準備、切り替え後の手厚い保守期間が含まれているかを確認します。特にリハーサルの回数は会社によって前提が異なりやすく、一回だけの見積もりと複数回の見積もりでは、金額にも安全性にも差が出ます。

段階移行の場合は、上記に加えて、新旧のあいだでデータを同期する仕組みの開発、段階ごとの移行作業とテスト、移行期間中の旧システムの保守、二重運用を支える手順書やマニュアルの作成が含まれているかを確認します。同期の仕組みを「段階移行の付帯作業」として軽く見積もっている場合、後から費用が膨らむ原因になります。

いずれの方式でも、移行作業のうち発注側が担う部分（データの整備、検証、利用者への周知、教育）を明確にしておくことが大切です。発注側の作業が見積もりに含まれていないこと自体は問題ではありませんが、その作業量を社内で確保できるかは、方式を選ぶ段階で確認しておく必要があります。

移行期間中の利用者への伝え方

どちらの方式を選んでも、利用者にとって移行は「慣れた仕組みが変わる」出来事です。方式によって伝えるべき内容とタイミングが異なります。

一括移行では、切り替え日の業務停止、切り替え後に最初に行う操作、問い合わせ先を、数週間前から繰り返し伝えます。切り替え前に操作の練習ができる環境を用意し、主要な利用者に触ってもらっておくと、当日の混乱を大きく減らせます。

段階移行では、「いつから、誰が、どの業務を、どちらのシステムで行うか」を一覧にして示すことが最も重要です。段階の途中では、ある業務は新システム、別の業務は旧システムという状態が生じるため、利用者が迷わないよう、段階ごとに最新の一覧を配布し直します。先に切り替えた部署の利用者に、次の部署への説明役を担ってもらうと、現場の言葉で使い方が伝わりやすくなります。

具体的な場面の例：複数拠点で使う販売管理システム

架空の一般例として、全国にいくつかの営業拠点を持つ会社が、販売管理システムを入れ替える場面を考えます。受注から請求までのデータは本社のデータベースで一元管理されていますが、拠点ごとに担当する顧客は分かれています。

当初、この会社は拠点ごとに順番に切り替える段階移行を考えていました。しかし、データの関係を図にしてみると、本社の経理部門が全拠点の請求データをまとめて処理しており、拠点ごとに切り替えると、移行期間中は新旧両方のシステムから請求データを集めて合算する仕組みが必要になることが分かりました。

そこで、データの移行と経理部門の切り替えは一括で行い、拠点の利用者への教育と利用開始は、本社に近い拠点から順に進める組み合わせの方式を選びました。切り替え日は請求の締め処理が終わった直後の週末とし、事前に三回の移行リハーサルを実施しています。各拠点の利用開始の初日には本社の担当者が立ち会い、操作の不明点をその場で解消しました。

この例のように、データの移行は一括、利用者の切り替えは段階的、といった組み合わせは、両方式の利点を取り入れる現実的な選択肢です。

この会社が判断の過程で役立てたのは、データの関係図と、拠点ごとの繁忙期の一覧でした。関係図によって「請求データの合算」という段階移行の隠れた負担が見え、繁忙期の一覧によって、どの週末なら全拠点の業務停止を許容できるかが分かりました。方式の議論が「安全そうだから段階的に」という印象論にならず、具体的な材料に基づいて進んだことが、関係者の合意を早めています。

移行方式の選択でよくある失敗と避け方

「段階的なら安全」と思い込む。 機能の結びつきが強いシステムで段階移行を選ぶと、新旧連携の仕組みが複雑になり、かえって不具合とコストが増えます。切り分けやすさを先に確認してください。

一括移行でリハーサルを省く。 一度きりの本番に不確実性を抱えたまま臨むことになります。本番と同じ条件でのリハーサルと、切り戻しの手順の確認は欠かせません。

段階移行の終わりを決めない。 新旧の共存が長引くほど、二重運用と保守の費用が膨らみます。最終段階の完了日と旧システムの停止日を最初に決めます。

最初の段階に難しい範囲を選ぶ。 最初の段階で大きくつまずくと、関係者の信頼を失い、以降の段階が進みにくくなります。最初は影響が小さく、協力が得やすい範囲を選びます。

利用者の負担を見積もらない。 段階移行では、利用者が新旧二つのシステムを使い分ける期間が生じることがあります。どの期間に誰がどちらを使うのかを明確にし、マニュアルと問い合わせ窓口を用意します。

移行方式を決める前のチェックリスト

• 業務ごとに、許容できる停止時間を業務部門に確認した
• 繁忙期と閑散期を把握し、切り替え時期の候補を決めた
• 機能とデータの関係を図にし、切り分けられる箇所を確認した
• 段階移行の場合に必要になる新旧連携の仕組みを洗い出した
• 一括移行の場合の停止時間を、データ量とリハーサルの見込みから概算した
• 二重運用の期間と、利用者の負担を見積もった
• 移行期間中の新旧両方の保守費用を見込んだ
• 方式ごとの期間・費用・リスクを比較表にまとめた
• 切り戻しの判断基準と手順を、方式に合わせて決めた
• 旧システムの停止日を決めた
• 方式を決めた理由と前提条件を記録した

よくある質問

Q. 小規模なシステムでも段階移行を検討すべきですか？

利用者が少なく、データ量も多くない小規模なシステムでは、一括移行のほうが単純で費用も抑えやすいことが多くあります。週末などに業務を止められるなら、一括移行と十分なリハーサルの組み合わせが現実的です。

Q. 段階移行の段階はいくつに分けるのがよいですか？

段階が多いほど一回の影響範囲は小さくなりますが、移行作業と新旧連携の期間が増えます。業務のまとまりで自然に分けられる単位を基本にし、むやみに細かく分けないことが大切です。

Q. 並行稼働はどちらの方式でも行うべきですか？

並行稼働は安心感が高い一方で、利用者に二重入力の負担がかかります。計算結果の正しさが特に重要な業務（請求、給与など）に絞り、期間を区切って行うのが現実的です。

Q. 移行方式は開発会社に任せて決めてもよいですか？

技術的な実現性は開発会社の意見が重要ですが、業務停止の許容度や利用者の負担は発注側にしか判断できません。比較表をもとに、発注側が最終的に決めるのが望ましい進め方です。リプレイス全体の流れはシステムリプレイスの進め方をご覧ください。

Otsumuに相談できること

対象のシステムが小さく、週末などに業務を止められ、データの関係もシンプルな場合は、この記事の判断軸とチェックリストで方式を決め、一括移行と十分なリハーサルで進めることができます。外部の支援なしで移行を終えられるケースも少なくありません。

一方で、業務を長く止められない、複数の機能や拠点がデータで密につながっている、新旧の連携の仕組みが必要になりそう、といった状況では、移行方式の設計そのものに経験が求められます。方式の選び方を誤ると、移行期間が長引き、費用と現場の負担が膨らむからです。

Otsumuは、業務の停止許容度とデータの関係を整理したうえで、一括・段階・その組み合わせのどれが合うかを一緒に検討し、移行計画の設計から開発、リハーサル、切り替え後の安定化までを一気通貫で支援します。進め方はシステムリプレイスのページで紹介しています。費用は範囲に応じて個別にお見積もりします。

方式を決めかねている段階でもご相談いただけます。30分の無料相談で、システムと業務の状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01