GGROWTH INTELLIGENCE経営に、次の一手を。
経営基盤/業務改革

データ移行は「コピー作業」ではない—新システムが稼働初日に止まる原因の多くは、移行範囲・テスト移行・本番判断の事前準備で防げる

2026.10.19GROWTH INTELLIGENCE 編集部

新システムの導入で、最も軽く見積もられがちな工程がデータ移行（古いシステムのデータを新しいシステムへ移す作業）です。「古いシステムの中身を新しいシステムに流し込むだけ」と考えていると、稼働初日に思わぬ事態に直面します。取引先の住所が欠ける、残高が合わない、伝票が登録できない、といった事態です。原因の多くはプログラムの不具合ではありません。何を移すか、データがどんな状態か、どう確かめるかを決めないまま本番を迎えたことにあります。本稿では、経営が下すべき判断に絞って、次の4点を整理します。移行範囲の決め方と法定保存期間（法律で保存が義務づけられた期間）の関係、旧データの把握とクレンジング（重複や誤りを直してデータを整えること）、移行方式の選び方、テスト移行と本番判断の進め方です。結論は、データ移行を「IT部門やベンダー（システム会社）の作業」ではなく、業務部門が責任を持つ経営プロジェクトとして扱うことです。

1｜結論—今すぐ取るべき経営判断

経営判断の核心は、データ移行の責任者を業務部門に置くことです。データの意味を知っているのは、日々そのデータで仕事をしている業務部門だけです。ベンダーやIT部門は「データを正しく運ぶ」ことには責任を持てます。しかし、「運んだデータが業務上正しいか」は判断できません。家の引っ越しにたとえると分かりやすいでしょう。引っ越し業者は、荷物を壊さずに運ぶことには責任を持てます。けれども、何を持っていき、何を捨て、どの部屋に置くかは、住む人にしか決められません。この線引きを曖昧にしたまま進めると、テストで見つかった不整合（データ同士の食い違い）が「仕様どおり」として通ってしまいます。そして、稼働後に現場が気づくことになります。

そのうえで、経営が事前に決めておくべきことは三つあります。第一に、どこまでの過去データを新システムに移すか。第二に、本番移行に踏み切るか延期するか（Go/No-Go）の基準と、それを誰がいつ判断するか。第三に、本番で問題が起きたときに旧システムへ戻す（ロールバック）条件と期限です。いずれも技術の問題ではありません。業務を止めないこととコストを比べてどう決めるか、という経営の問題です。

2｜なぜ移行は「コピー」では済まないのか—旧データと新システムのずれ

データ移行が難しいのは、旧システムのデータが「旧システムの都合」で作られているからです。長年使ううちに、次のような状態になっていることは珍しくありません。同じ取引先が、別のコードで二重に登録されている。備考欄に、重要な取引条件が手入力されている。使われなくなった項目に、別の意味のデータが入っている。旧システムでは人が補って回っていたこうした「くせ」が、新システムでは入力チェックで弾かれたり、誤った意味で解釈されたりします。

比較軸 「コピー作業」と考えた場合 「業務の引っ越し」と考えた場合
責任者 ベンダー・IT担当者 業務部門の責任者（ITは実行役）
移行範囲 旧システムの全データ 業務と法令から必要な範囲に絞る
品質の確認 件数が合えば完了 金額・残高・業務上の意味まで照らし合わせる
テスト 本番前に1回 本番と同じ手順で2〜3回
失敗時の備え 想定しない 戻す条件・期限を事前に決める

移行の失敗は、規模の大きな組織でも起こります。2021年2月28日、みずほ銀行では二つの記帳処理が同じ日に重なりました。一つは、定期性預金（期間を決めて預けるお金）を、通帳を発行しない口座へ切り替える際の未記帳分約45万件です。もう一つは、月末の定期性預金約25万件の記帳処理です。データ移行の処理中に、一部でメモリ容量（コンピュータが一度に扱える作業領域）の上限を超えました。その結果、全国で4,318台のATMが停止しました。5,244件のキャッシュカードや通帳が、機械に取り込まれたままになりました（出典：Impress Watch、2021年4月／ScanNetSecurity、2021年4月）。この例では、二つのことが、顧客に直接影響する障害につながりました。取引が集中する月末に、移行作業を重ねたこと。処理量に対する事前の見積もりと確認が、十分でなかったことです。

3｜移す範囲の決め方—法定保存期間と「移さないデータ」の扱い

過去データをどこまで移すかは、移行の工数（かかる手間と時間）とリスクを最も大きく左右する判断です。全件を移せば安心に見えます。しかし、古いデータほど品質が悪く、クレンジングとテストの負担が膨らみます。一般には直近数年分を移し、それ以前は別の形で保管する方法が取られます。ただし、その線引きは法定保存期間を確認してから決める必要があります。

根拠 対象 保存期間
法人税法 帳簿（総勘定元帳・仕訳帳など、取引を記録する会計の帳面）と取引書類 確定申告書の提出期限の翌日から7年。青色申告（帳簿をつける代わりに税の優遇を受ける申告方式）で欠損金（税務上の赤字）が生じた事業年度は10年（2018年4月1日以後に開始した事業年度）
会社法 会計帳簿と事業に関する重要な資料 会計帳簿の閉鎖の時（帳簿を締めた時）から10年
電子帳簿保存法 電子で受け取った・送った請求書や領収書などの取引データ 2024年1月1日以後は、原則として紙に出力しての保存は認められない。電子データのまま保存する必要がある（一定の猶予措置あり）

（出典：国税庁「No.5930 帳簿書類等の保存期間」令和8年4月1日現在法令等／e-Gov法令検索「会社法」第432条第2項／国税庁「電子取引データ保存制度サイト」）

ここで注意すべきは、「法人税は7年」とだけ覚えていると見落としが出ることです。会社法の10年や、欠損金がある年度の10年です。また、電子取引のデータは、新システムに移さない場合でも保存を続ける必要があります。原則として、検索できることなどの保存要件を満たした状態で保存します。旧システムを廃止するなら、移さないデータを読み出せる形で保管しなければなりません。その保管方法と費用を、移行計画に含めます。

移す範囲を決めたら、関係する業務部門の責任者に合意の署名をもらいます。稼働後に「去年の実績が見られない」と言われることがあります。そのとき、それが合意済みの判断なのか、漏れなのかを区別できるようにするためです。

4｜進め方—移行前準備の6ステップ

STEP1　旧データの実態を把握する

仕様書を読むだけでなく、実データを抜き出して確かめます。見るのは、件数、空欄の割合、重複、ありえない値（マイナスの在庫、未来の日付など）です。仕様書と実データは、長年の運用で必ずずれています。

STEP2　クレンジングを旧システム側で進める

重複の統合や不要データの削除は、可能な限り移行前に旧システム上で行います。移行プログラムの中で直そうとすると、変換ルールが複雑になります。何を直したかも追えなくなります。統合した取引先や品目は、新旧コードの対応表として必ず残します。稼働後のマスタ（取引先や品目など、業務の土台になる基本データ）の管理の考え方は、マスタデータ保守運用の設計を扱った別稿も参照してください。

STEP3　マッピングと変換ルールを業務部門が承認する

旧項目と新項目の対応づけ（マッピング）、コード変換、桁数や日付形式の変換を一覧にします。それを業務部門の責任者が承認します。「旧システムの区分Aは新システムの区分Bに相当する」といった判断は、ITではなく業務の判断です。

STEP4　移行方式を選ぶ

方式 向いている場面 注意点
CSV（表計算ソフトで開ける形式のファイル）・Excel 件数が少ないマスタ 手作業が入り、誤りと漏れが起きやすい
ベンダー提供ツール 新システムの標準機能で足りる場合 旧システム固有のデータに対応できないことがある
自社開発の変換プログラム 変換ルールが複雑な場合 開発・テストの手間がかかり、作った人しか直せなくなりやすい
API・DB直結（システム同士を直接つないで移す） 大量データ、短時間での移行 誰がどのデータを扱えるかの管理と、処理量の見積もりが欠かせない

方式は1つに絞る必要はありません。マスタはCSV、取引データは変換プログラム、といった組み合わせが一般的です。

STEP5　テスト移行を本番と同じ手順で2〜3回行う

1回目で、手順と変換ルールの誤りを洗い出します。2回目で修正を確認し、3回目で本番と同じ時間枠・同じ体制で所要時間を測ります。各回で、件数だけでなく合計値も新旧で突き合わせます。売掛金（まだ受け取っていない売上代金）の残高や、在庫金額などです。あわせて、業務担当者が代表的な取引を実際に処理してみることが欠かせません。

STEP6　本番計画・Go/No-Go・ロールバックを決める

本番の作業手順、担当者、連絡体制を決めます。加えて、どの時点で何を確認すれば先に進むかの判定点を、時刻つきで決めます。月末や締め日など、取引が集中する時期は避けます。

5｜Go/No-Goの判断—誰が、いつ、何で決めるか

本番移行の可否は、移行作業の担当者が判断するものではありません。業務を止めるかどうかの責任を負える、経営層または業務部門の責任者が判断します。担当者には、それまでの準備を無駄にしたくない心理が働きます。判断を任せると、多少の問題を抱えたまま進めてしまいがちです。

判断時期 判断する人 確認する内容
本番の1〜2週間前 経営層・業務部門責任者 最終テスト移行の結果、残課題とその回避策、利用部門の準備状況
本番の前日 同上 旧システムの停止とデータ凍結（移行中にデータを更新しないよう止めること）の準備、体制と連絡網
本番作業中の判定点 業務部門責任者（事前に委任） 件数・合計金額の照合結果、所要時間が計画内か
稼働初日の終了時 経営層・業務部門責任者 業務が回ったか、新システムで続けるか旧システムに戻すか

基準は、事前に数値や条件で書いておきます。たとえば「重大な不整合がゼロ」「合計金額が一致」「作業が計画時間内に収まる」です。基準を満たさなければ延期する、という合意を最初に取っておきます。そうすれば、現場が問題を抱えたまま本番に進まずに済みます。稼働後しばらくは、旧システムを参照できる状態で残します。問い合わせにすぐ答えられる体制も置きます。

6｜よくある誤解—データ移行を軽く見る判断のパターン

誤解①　「移行はベンダーの契約範囲だから、任せておけば大丈夫」 ベンダーが保証できるのは、決められたルールどおりにデータを運ぶことまでです。どのデータをどう変換するのが業務上正しいかは、発注側が決めて承認しなければなりません。移行後の不整合の多くは、ルールの誤りから生まれるのではありません。業務部門が決めるべき判断が、決まっていなかったことから生まれます。

誤解②　「念のため、過去データはすべて新システムに移しておくのが安全だ」 古いデータほど品質が悪くなります。全件を移すと、クレンジングとテストの負担が大きく増え、本番の作業時間も延びます。必要なのは、法定保存期間を満たすことです。そのために新システムへ移す必要は、必ずしもありません。移さないデータを検索できる形で保管する方が、安く安全な場合があります。

誤解③　「テスト移行で件数が一致したから、本番も問題ない」 件数が合っていても、金額の桁ずれやコードの読み替え違いは見つかりません。また、テスト環境と本番では、処理量や時間帯が違います。合計金額の照合、業務担当者による実際の操作、本番と同じ時間枠での計測。ここまで行って、初めて確認したと言えます。

7｜経営判断チェックリスト—今やるべきか否かの判断軸

移行前準備を優先すべき企業の条件

  • 基幹システム（会社の中心業務を支えるシステム）・会計・販売管理などの入れ替えを1年以内に予定している
  • 旧システムを10年以上使い、仕様を説明できる人が社内に1〜2名しかいない
  • 取引先・品目のマスタに、重複や表記ゆれがあることを現場が認識している
  • 移行の範囲や本番の判断基準について、ベンダーと文書で合意していない
  • 電子で受け取った請求書などのデータを、旧システムや個人のフォルダに保存している

今やるべきかの判断軸

判断の分かれ目は、次の三つを今この場で言えるかどうかです。「移行の業務側責任者の名前」「移す期間と移さないデータの保管方法」「Go/No-Goの基準と判断者」。言えないなら、稼働日を決める前に準備に着手すべきです。準備にかかる費用の多くは、業務部門の時間です。稼働後に混乱を収拾する費用や、取引先の信用の損失に比べれば小さく済みます。

やらない場合のリスク

第一に、稼働初日に請求・出荷・支払が止まり、取引先に直接迷惑をかけるリスクです。第二に、移行で生じた不整合が気づかれないまま残るリスクです。決算や税務調査の段階で、数字の根拠を説明できなくなります。第三に、旧システムの廃止で、データを読み出せなくなるリスクです。法定保存期間内のデータや、電子取引データが対象になります。

8｜経営者への一言

データ移行は、会社がこれまで積み上げてきた取引や顧客の記録を、新しいシステムに移す仕事です。何を残し、何を手放し、いつ踏み切るか。その判断を現場任せにしないことが、新システムを初日から動かす最短の道です。

参考文献

1分で鍛える意思決定 ／ オペレーション【登録者限定】

販売管理システムを来年4月に入れ替える、従業員80名ほどの部品商社。旧システムは15年使っており、仕様を説明できるのは情報システム担当の1名だけで、ベンダー（システム会社）からは移行計画の提出を求められている。

あなたならどうする？

移行の準備で、最初に手をつけるのは？

正解はありません。登録すると、3つの選択肢から選んで、記事が示す見方まで読めます。

この先は、メールアドレスを登録すると読めます

選択肢に答えると、記事が示す見方と、あなたの判断の記録が残ります。

パスワードはありません。お送りするのは知のワークアウトに関するお知らせのみです。

← 記事一覧へ