新システム導入時のデータ移行前準備

目次

• 第1章　はじめに：なぜデータ移行前準備が重要なのか
• 第2章　移行対象の整理
• 第3章　旧システムのデータ構造を理解する
• 第4章　データクレンジング
• 第5章   データマッピング
• 第6章　移行方式とツールの選定
• 第7章　テスト移行（リハーサル）
• 第8章　本番移行計画の立案
• 第9章　移行後の確認と稼働準備
• 第10章　まとめ

第1章　はじめに：なぜデータ移行前準備が重要なのか

企業が新しいシステムを導入する理由はさまざまです。老朽化したシステムの刷新、クラウド化によるコスト削減、業務効率化、セキュリティ強化、あるいは事業拡大に伴う機能強化など、背景は企業ごとに異なります。しかし、どんなに優れた新システムを導入したとしても、データ移行がうまくいかなければ、そのシステムは本来の力を発揮できません。特に、旧システムから新システムへ「一括でデータを移行する」ケースでは、移行作業の成否が稼働初日の混乱を左右します。もし移行が失敗すれば、以下のような事態が起こり得ます。

• 新システムにデータが入らず業務が開始できない
• 顧客情報や取引データが欠損し、業務部門からクレームが殺到する
• データ不整合により、システムがエラーを起こして停止する
• 稼働初日から緊急対応に追われ、プロジェクト全体の信頼が揺らぐ

こうしたトラブルは実際の現場で頻繁に起きており、その多くは、「移行前の準備不足」が原因です。

■ データ移行は「コピー作業」ではない

よく誤解されがちですが、データ移行は単に「旧システムのデータを新システムにコピーする」作業ではありません。実際には、以下のような多くの工程が含まれています。

• 移行対象の整理
• 旧システムのデータ構造の理解
• データクレンジング
• データマッピング
• 移行方式の選定
• テスト移行（リハーサル）
• 本番移行計画の策定
• 移行後の確認作業

これらの工程を丁寧に進めることで、初めて「安全に」「正確に」「確実に」データを移行することが出来ます。

■ 本記事の目的

この記事では、データ移行前に必要な準備を順序立てて解説していきます。

• どんな作業が必要なのか
• どの順番で進めればいいのか
• どこでつまずきやすいのか
• どうすればトラブルを防げるのか

こうした疑問を解消し、実務でそのまま使える知識や考え方を提供することが本記事の目的です。

第2章　移行対象の整理

1. 移行対象データの種類の洗い出し

新システム導入におけるデータ移行は、単に「データを移す」作業ではなく、どのデータを移すべきかを判断するところから始まります。

• マスタデータ

企業の基盤となる情報で、長期間利用されるデータです。

• • 顧客マスタ
  • 商品マスタ
  • 社員マスタ
  • 部署マスタ
  • 取引先マスタ

マスタデータは新システムでも継続して利用されるため、移行対象となることが多いです。

• トランザクションデータ（取引データ）

日々の業務で発生するデータで、データ量が多いのが特徴です。

• • 受注データ
  • 売上データ
  • 在庫データ
  • 購買データ
  • 請求・支払データ

これらは業務部門の利用頻度が高いため、移行対象期間を慎重に決める必要があります。

• 履歴データ・ログデータ

システムの利用履歴や変更履歴などのことです。

• • 操作ログ
  • 変更履歴
  • アクセスログ

新システムで必須でなければ、アーカイブ化するケースも多いです。

• 設定データ

システムの動作に関わる設定情報のことです。

• • 権限設定
  • ワークフロー設定
  • システムパラメータ

これらは新システムで再設定する場合もあるため、移行対象かどうかを慎重に判断します。

 

2. 移行対象期間の決定

次に、いつ登録されたデータを移行対象とするかを決めます。特にトランザクションデータは量が膨大なため、すべてを移行する必要があるかどうかを検討する必要があります。

• 判断基準の例

• • 法的に保存が必要な期間（例：会計データは7年保存が必要）
  • 業務で参照される頻度（例：直近3年分だけあれば十分なケースも多い）
  • データ量と移行時間のバランス
    • データ量が多いほど移行時間が増え、本番移行のリスクも高まる
  • 新システムのパフォーマンスへの影響
    • 不要なデータを大量に移行すると、検索や処理速度が低下する可能性がある

＜よくある判断例＞

• • マスタデータ：全件移行
  • トランザクションデータ
    • 取引データ：直近3〜5年分のみ移行
    • 過去データ：アーカイブとして別保管
  • 履歴データ・ログデータ：移行せずアーカイブ化

 

3. 移行しないデータの整理

移行対象を決めるのと同じくらい重要なのが、移行しないデータを明確にすることです。

• 移行しないデータの例
  • 廃止された商品コード
  • 退職済み社員のデータ
  • 過去のテストデータ
  • 不整合が多く、利用されていないデータ
  • 古いログデータ

これらを曖昧にしたまま進めると、後で「やっぱり必要だった」という事態が発生し、手戻りにつながります。

 

4. 業務部門との合意形成

移行対象の判断はデータ移行の担当者だけで決めるものではありません。 実際にデータを使うのは業務部門であり、彼らの意見が最も重要です。

• 合意形成のポイント
  • 移行対象データの一覧を作成し、業務部門とレビューする
  • 「必要」「不要」「アーカイブ」の分類を明確にする
  • 移行対象期間について業務部門の意見を聞く
  • 移行しないデータの扱い（アーカイブ方法）を説明する

この段階で業務部門と認識を合わせておくことで、後工程のトラブルを大幅に減らすことが出来ます。

 

5. 移行対象の整理

移行対象の整理は、データ移行の最初の工程ですが、同時に最も重要な工程のひとつです。

• • 移行対象が曖昧だと、マッピング作業が進まない
  • データ量が読めないと、移行時間の見積もりができない
  • 業務部門との認識に齟齬が生じると、後で大きな手戻りが発生する

つまり、移行対象の整理は、プロジェクト全体でも特に重要な作業になります。

第3章　旧システムのデータ構造を理解する

移行対象が整理できたら、次に取り組むべきは 旧システムのデータ構造を正確に把握することです。

1. 旧システムの仕様書確認

最初に行うべきは、旧システムの仕様書（設計書）を確認することです。

• テーブル定義書
• ER図（エンティティ・リレーションシップ図）
• 項目定義書
• データ型一覧
• 制約（必須項目、ユニーク制約、外部キーなど）

ただし、ここでは注意が必要です。

多くの企業では、旧システムが長年運用されているため、仕様書が最新状態ではないことがよくあります。

• 過去の改修が反映されていない
• 実データと仕様書が一致していない
• 担当者が退職していて情報が引き継がれていない

そのため、仕様書はあくまで「参考資料」として扱い、次のステップで実データを必ず確認する必要があります。

 

2. 実データを抽出して確認

仕様書だけでは不十分なので、実際に旧システムからデータを抽出して確認します。仕様書と実データが一致していないケースは非常に多く、実データを見ないまま移行設計を進めると、テスト移行で大量のエラーが発生する可能性があります。

• 確認すべきポイント
  • 項目の実際のデータ型（例：仕様書では「数値」だが、実際は文字列で保存されている）
  • データの桁数・フォーマット（例：日付が「YYYY/MM/DD」と「YYYYMMDD」が混在している）
  • 必須項目の実態（例：仕様書では必須だが、実データには欠損がある）
  • コード体系の揺れ（例：部署コードが「ABCDE00001」と「00001」が混在している）
  • データ量
    • 移行時間の見積もりに直結するため、正確に把握する必要がある

 

3. データ品質の確認

旧システムには、長年の運用で蓄積された“汚れたデータ”が必ず存在します。

• よくあるデータ品質の問題
  • 欠損値（NULL）（例：住所が空欄、日付が未入力である）
  • 重複データ（例：同じ顧客が複数登録されている）
  • 異常値（例：日付が「1900/01/01」、金額がマイナスで登録されている）
  • 不正なコード（例：存在しない部署コードが登録されている）
  • フォーマットの揺れ（例：電話番号が「090-xxxx-xxxx」と「090xxxxxxxx」で混在している）

こうした問題を把握しておかないと、新システム側でエラーが発生し、移行作業が止まってしまいます。

 

4. データ間の関係理解

データ移行では、単にデータ単体を見るだけでは不十分です。データ同士がどのように関連しているかを理解することが重要です。

＜例＞顧客と受注の関係

• • 顧客マスタ（customer）
  • 受注データ（order）

受注データには顧客IDが紐づいているため、顧客マスタを先に移行しないと受注データが移行できません。

第4章　データクレンジング

旧システムのデータ構造を理解したら、次に取り組むべきは データクレンジング（データの整理・清掃） です。多くの企業では、旧システムが長年運用されているため、データには必ず“汚れ”が蓄積しています。こうしたデータをそのまま新システムに移行すると、検索性の低下、エラーの多発、業務効率の悪化など、稼働後の混乱につながります。

1. データクレンジングの目的

データクレンジングの目的は、「新システムで正しく動作するために、データを正しい状態に整えること」 です。具体的には、以下のような効果があります。

• 新システムでのエラーを防ぐ
• データの検索性・活用性を高める
• 業務効率を向上させる
• データ分析の精度を高める
• 稼働後のトラブルを最小限に抑える

 

2. 不要データの削除

データクレンジングにおいて、まず取り組むべきは、移行する必要のないデータを削除することです。

• よくある不要データの例

• • 廃止された商品コード
  • 退職済み社員のデータ（必要な期間を過ぎたもの）
  • 過去のテストデータ
  • 使われていない部署コード
  • 参照されていないマスタデータ

不要データを移行すると、新システムのパフォーマンス低下や混乱の原因になります。特にマスタデータは、古い情報が残っていると業務部門から「どれが正しいの？」と問い合わせが増えるため、事前に整理しておくことが重要です。

 

3. 重複データの整理

旧システムでは、同じ顧客や商品が複数登録されているケースがよくあります。

• 重複データが発生する原因

• • 担当者ごとに登録ルールが異なる
  • システム側で重複チェックが弱い
  • 過去の運用で統合されていない
• 重複データを放置するとどうなるか

• • 新システムで検索性が悪化する
  • 業務部門が誤ったデータを参照する
  • 分析結果が不正確になる
  • 顧客対応の品質が低下する

重複データは、移行前に統合・整理しておくことが必須です。

 

4. 異常値の修正

異常値とは、明らかに正しくないデータのことです。

• よくある異常値の例

• • 日付が「1900/01/01」や「9999/12/31」
  • 金額がマイナス
  • 電話番号が桁不足
  • 郵便番号が存在しない形式
  • コードが定義外の値

こうした異常値は、新システム側でエラーを引き起こす原因になります。

 

5. コード体系の統一

旧システムと新システムでコード体系が異なる場合、コードの統一や変換ルールの作成が必要です。

• よくあるコード体系の揺れ

• • 部署コードが「ABCDE00001」と「00001」で混在
  • 商品コードが英数字と数字で混在
  • 顧客区分が「1」「01」「A」など複数存在

こうした揺れを放置すると、マッピング作業が複雑になり、移行時に大量のエラーが発生します。

 

6. 業務部門との調整

データクレンジングは情シスだけで完結する作業ではありません。実際にデータを使うのは業務部門であり、最終判断も業務部門が行うべきです。

• 業務部門と協力するポイント

• • 不要データの判断は業務部門に確認する
  • 重複データの統合ルールを業務部門と決める
  • 異常値の修正方針を共有する
  • コード体系の統一は業務部門の運用ルールと合わせる

業務部門と連携することで、移行後のトラブルを大幅に減らせます。

第5章   データマッピング

データ移行において最も重要な作業のひとつがデータマッピングで、これは旧システムのデータ項目が新システムのどの項目に対応するのかを整理する作業を指します。マッピングが曖昧なまま移行を進めると、テスト移行で大量のエラーが発生したり、業務部門から「データが正しく移っていない」と指摘されたりして、プロジェクト全体が混乱します。

1. データマッピングとは何か

データマッピングとは、旧システムの項目 → 新システムの項目の対応関係を一覧化する作業です。

例えば、旧システムの「顧客名」が新システムでは「customer_name」になる、といった対応を明確にします。

• マッピング表に含めるべき情報

• • 旧システムの項目名
  • 新システムの項目名
  • データ型（文字列、数値、日付など）
  • 桁数
  • 必須項目かどうか
  • 変換ルール（コード変換、日付形式変換など）
  • 備考（注意点、例外など）

この表がしっかり作られていると、移行バッチの作成やテスト移行が非常にスムーズになります。

 

2. マッピング作成の手順

Step1：旧システムの項目一覧を作成する

第3章で把握した旧システムのデータ構造をもとに、項目一覧を作成します。

Step2：新システムの項目一覧を確認する

新システムの仕様書やベンダー提供の項目定義書を確認し、対応する項目を探します。

Step3：項目ごとに対応関係を整理する

1対1で対応する項目もあれば、以下のように複雑なケースもあります。

• • • 1対多
      例：旧システムの「住所」が新システムでは「都道府県」「市区町村」「番地」に分割される
    • 多対1
      例：旧システムの「姓」「名」が新システムでは「氏名」に統合される
    • 変換が必要な項目
      例：日付形式、コード体系、数値フォーマットなど

Step4：業務部門と合意する

マッピングは業務部門の理解が不可欠です。

• • • この項目は本当に必要か
    • 変換後の値は業務で問題ないか
    • 必須項目が欠けていないか

業務部門と合意形成することで、後のトラブルを防げます。

 

3. データ変換ルールの定義

マッピング作業では、単に項目を対応させるだけでなく、データをどのように変換するかを定義する必要があります。

• よくある変換ルール

• • 日付形式の変換
    例：YYYY/MM/DD → YYYY-MM-DD

• • コード変換
    例：部署コード「ABCDE00001」と「00001」

• • 文字コード変換
    例：Shift-JIS → UTF-8

• • 数値フォーマットの統一
    例：カンマ付き数値 → カンマなし数値

• • 文字列の分割・結合
    例：商品コード「A12345」 → 「A」と「12345」

変換ルールが曖昧だと、移行バッチの作成時に解釈が分かれ、テスト移行で「思っていたのと違う」という事態が発生します。

 

4. マッピング作業でつまずきやすいポイント

• 新システムに対応する項目が存在しない

この場合は、業務部門と相談し、以下のような判断が必要です。

• • 新システム側で項目を追加する
  • 代替項目を利用する
  • 移行しない

• 必須項目が満たせない

新システムで必須なのに、旧システムにデータがないケースがあります。
この場合は、以下のような対応が必要です。

• • デフォルト値を設定する
  • 業務部門に入力してもらう

• コード体系が複雑で変換が難しい

部署コードや商品コードが複雑な場合、変換表を作成し、業務部門と合意する必要があります。

 

5. マッピング表は「移行の設計図」

データマッピングは、移行作業のすべての基盤になります。どの作業もマッピング表がなければ進められません。

• 移行バッチの作成
• テスト移行の実施
• データクレンジングの方針
• 本番移行の手順書作成

第6章　移行方式とツールの選定

移行対象が整理され、旧システムのデータ構造と品質が把握できたら、次に決めるべきは 「どのようにデータを移すか」 という移行方式です。移行方式の選定は、データ移行の成否を左右する重要な工程であり、ここでの判断が本番移行の安定性に直結します。

移行方式は、システムの構造、データ量、移行期間、利用可能なツール、ベンダーのサポート範囲など、さまざまな要素を踏まえて決める必要があります。

1. 移行方式の種類と特徴

データ移行にはいくつかの方式があり、それぞれにメリット・デメリットがあります。

• CSV/Excel経由の移行

最も一般的で、シンプルな移行方式。

メリット

• • ほとんどのシステムがCSVインポートに対応している
  • 作業内容が分かりやすい
  • 小規模データの移行に向いている
  • ベンダー側のサポートが受けやすい

デメリット

• • 大量データの移行には不向きである
  • 文字コードやフォーマットの揺れでエラーが出やすい
  • 手作業が多いとミスが発生しやすい

 

• API連携による移行

新旧システムがAPIを提供している場合に利用できる方式。

メリット

• • 自動化しやすい
  • データ整合性を保ちやすい
  • 大量データでも安定して移行できる

デメリット

• • API仕様の理解が必要である
  • 開発工数がかかる
  • API制限（レートリミット）に注意が必要である

 

• DB直結（ダイレクトアクセス）

旧システムのデータベースに直接接続してデータを抽出し、新システムのDBに投入する方式。

メリット

• • 大量データの移行に向いている
  • 高速で移行できる
  • 柔軟な変換処理が可能である

デメリット

• • DB構造の深い理解が必要である
  • 誤操作のリスクが高い
  • セキュリティ面の配慮が必須である

 

• ベンダー提供の移行ツール

新システムのベンダーが専用の移行ツールを提供している場合。

メリット

• • 新システムに最適化されている
  • エラーが出た場合のサポートが受けやすい
  • 設定項目が分かりやすい

デメリット

• • ツールの仕様に合わせる必要がある
  • カスタマイズ性が低い場合がある
  • ライセンス費用が発生する可能性もある

 

• 自社開発の移行バッチ

要件に合わせて独自の移行プログラムを作成する方式。

メリット

• • 柔軟性が高い
  • 複雑な変換処理に対応できる
  • 大量データでも安定して移行可能である

デメリット

• • 開発工数が大きい
  • テストが必須である
  • 保守が必要である

 

2. 移行方式を選定する際の判断ポイント

移行方式は、以下の観点から総合的に判断します。

• データ量

• • 数万件程度 → CSVでも対応可能
  • 数百万件以上 → APIやDB直結が現実的

• データの複雑さ

• • 単純な項目移行 → CSVで十分
  • 複雑な変換が必要 → バッチやAPIが向いている

• 移行時間（本番移行の制約）

• • 停止時間が短い → 高速な方式（DB直結）が必要
  • 停止時間に余裕がある → CSVでも対応可能

• ベンダーのサポート範囲

• • ベンダーが提供するツールがある → それを使うのが安全
  • サポートが限定的 → 自社でバッチを作る必要がある

• セキュリティ要件

• • DB直結は権限管理が重要である
  • APIは認証方式の確認が必要である
  • CSVはファイル管理のリスクがある

 

3. 移行方式選定でつまずきやすいポイント

• ベンダー任せにしてしまう

ベンダーは新システムの専門家ですが、旧システムのデータ構造までは把握していません。
そのため、移行方式は自社側の理解も必要です。

• データ量を過小評価する

「CSVでいけるだろう」と思っていたら、実際は数百万件あり、移行に数十時間かかるといった問題が出る可能性もあります。

• 本番移行の時間制約を考慮していない

本番移行は週末や深夜に行うことが多く、時間が限られています。
方式選定時に必ず考慮する必要があります。

• 変換処理の複雑さを見落とす

コード変換や文字列分割などが多い場合、CSVでは対応しきれないことがあります。

第7章　テスト移行（リハーサル）

データ移行プロジェクトにおいて、最も効果的なリスク対策がテスト移行（リハーサル）です。
どれだけ綿密に設計し、どれだけ丁寧にデータクレンジングを行っても、実際に移行してみないと分からないことが必ずあります。そのため、テスト移行は「やるべき工程」ではなく、“何度も繰り返すべき工程”と言えます。

1. テスト移行の目的

テスト移行の目的は、単に「移行できるかどうか」を確認することではありません。
実際には、以下のような複数の目的があります。

 

• 移行手順の妥当性を確認する

手順書通りに作業して問題なく移行できるかを確認します。

• 移行時間を計測する

本番移行の時間は限られているため、実際にどれくらい時間がかかるのかを把握することが重要です。

• データの整合性を確認する

• • 件数が一致しているか
  • 必須項目が欠けていないか
  • 変換ルールが正しく適用されているか
  • 新システムで正しく参照できるか

• エラーの洗い出し

テスト移行では、必ず何らかのエラーが発生します。
むしろ、エラーが出ることが正常です。

• 本番移行のリスクを最小化する

テスト移行を繰り返すことで、本番移行の成功率が飛躍的に高まります。

 

2. テスト移行の実施手順

テスト移行は、以下の流れで実施するのが一般的です。

Step1：テスト環境の準備

新システムのテスト環境を用意し、初期状態にリセットします。

Step2：移行データの抽出

旧システムから移行対象データを抽出します。本番と同じ条件で抽出することが重要です。

Step3：移行バッチ・ツールの実行

マッピング表と変換ルールに基づき、移行処理を実行します。

Step4：移行結果の確認

• 件数一致
• データ整合性
• 変換ルールの適用状況
• 新システムでの画面表示
• 検索・参照の動作確認

Step5：エラーの分析と修正

エラー内容を分析し、以下のような対応を行います。

• マッピングの修正
• クレンジングの追加
• バッチの修正

Step6：再テスト（複数回実施）

1回で終わらせず、最低2〜3回はテスト移行を繰り返すのが理想です。

 

3. テスト移行で確認すべきポイント

テスト移行では、以下の観点で確認することが重要です。

• 件数の一致

旧システムと新システムで件数が一致しているか

• データの整合性

• • NULLが入っていないか
  • 変換ルールが正しく適用されているか
  • コード体系が統一されているか

• 新システムでの動作確認

データが正しく移行されていても、画面で正しく表示されないというケースはよくあります。

• 移行時間の計測

本番移行のスケジュールを組むために必須です

• エラーの種類と傾向

以下のようなエラー内容を把握して改善します。

• • 項目不足
  • データ型不一致
  • コード変換ミス
  • 外部キー制約違反

 

4. テスト移行でつまずきやすいポイント

• テスト移行を1回だけで済ませてしまう

1回目は必ず問題が出ます。複数回の実施が前提です。

• 本番と異なる条件でテストしてしまう

抽出条件やデータ量が本番と違うと、本番で予期せぬ問題が発生します。

• 業務部門の確認が不足する

データの正しさは業務部門が最も判断できます。必ずレビューしてもらう必要があります。

• 移行時間を軽視する

「動いたからOK」ではなく、時間内に終わるかどうかが重要です。

第8章　本番移行計画の立案

テスト移行を繰り返し、移行手順やデータ品質が安定してきたら、いよいよ本番移行計画の策定に進みます。本番移行は、プロジェクトの中でも最も緊張感のある工程であり、ここでの計画の精度が当日の混乱をどれだけ防げるかを決めます。

本番移行は「ただデータを移す日」ではなく、複数のチームが連携し、限られた時間の中で一気に作業を完了させる“総合演習”のようなものです。そのため、事前に綿密な計画を立て、関係者全員が同じ認識を持つことが不可欠です。

1. 本番移行計画の目的

本番移行計画の目的は、「限られた時間内で、安全かつ確実に移行を完了させること」です。

そのために重要なポイントは、以下の3つとなります。

• 作業内容の明確化
• 作業順序の整理
• 関係者の役割分担の明確化

これらが曖昧なまま当日を迎えると、作業が止まったり、判断が遅れたりして、移行時間が大幅に延びる原因になります。

 

2. 本番移行のスケジュールを作成する

本番移行は、通常、業務停止時間（夜間・休日）に実施されます。そのため、時間の制約が非常に厳しいのが特徴です。

• スケジュールに含めるべき項目

• • 旧システムの停止時間
  • データ抽出開始時間
  • 変換処理の開始・終了
  • 新システムへのデータ投入
  • 移行後の整合性チェック
  • 業務部門による確認
  • 新システムの稼働開始時間
  • トラブル発生時のロールバック判断タイミング

• スケジュール作成のポイント

• • テスト移行で計測した時間をベースにする
  • 余裕時間（バッファ）を必ず確保する
  • 作業者の交代タイミングも考慮する
  • 業務部門の確認時間を忘れない

本番移行は「予定通りに進まない」ことを前提に、余裕を持った計画が必要です。

 

3. 関係者の役割分担を明確にする

本番移行は、情シスだけでなく、ベンダー、業務部門、インフラ担当など、複数のチームが同時に動きます。

• 役割分担の例

• • 情シス：全体統括、進行管理、判断
  • ベンダー：移行バッチ実行、エラー対応
  • 業務部門：データ確認、業務テスト
  • インフラ担当：サーバー監視、リソース管理
  • 管理部門：業務停止の社内調整

• 役割分担で重要なこと

• • 誰がどの作業を担当するかを明確にする
  • 連絡手段（チャット、電話、会議室）を決めておく
  • トラブル発生時のエスカレーションルートを定義する

役割が曖昧だと、当日に「誰が対応するの？」という混乱が発生し、作業が止まります。

 

4. 移行手順書の作成

本番移行は、緊張感の中で深夜に行われることが多く、人間の集中力が落ちやすい環境です。

そのため、移行手順書は「誰が見ても迷わず作業できるレベル」で作成する必要があります。

• 手順書に含めるべき内容

• • 作業手順を時系列で記載
  • 実行するコマンドやツール
  • 期待される結果
  • エラー発生時の対応方法
  • 作業者の名前
  • 作業完了のチェック項目

• 手順書作成のポイント

• • テスト移行で使った手順書をベースにする
  • 曖昧な表現を避ける（例：適宜、必要に応じて）
  • スクリーンショットや例を入れると分かりやすい
  • 作業者以外の人にもレビューしてもらう

 

5. ロールバック手順の準備

本番移行で最も重要なのが、「何かあったら戻せる」状態を作っておくことです。

ロールバック手順がないと、トラブルが発生した際に判断が遅れ、業務開始時間に間に合わなくなるリスクがあります。

• ロールバック手順に含めるべき内容

• • 旧システムのバックアップ取得方法
  • 戻すための作業手順
  • ロールバック判断の基準
  • 判断者（誰が最終決定するか）
  • ロールバックにかかる時間の見積もり

• ロールバック判断のタイミング

• • データ整合性チェックで重大な不整合が発生した場合
  • 移行時間が大幅に遅延した場合
  • 新システムが正常に起動しない場合

 

6. 本番移行前の最終確認（Go/No-Go判断）

本番移行の直前には、Go/No-Go判断（実施するか延期するかの最終判断）を行います。

• 判断材料の例

• • テスト移行の結果
  • データ品質
  • 手順書の完成度
  • 業務部門の準備状況
  • ベンダーの体制
  • リスクの洗い出しと対策状況

Go/No-Go判断を曖昧にすると、準備不足のまま本番移行に突入してしまい、トラブルの原因になります。

 

第9章　移行後の確認と稼働準備

本番移行が完了しても、そこでプロジェクトが終わるわけではありません。むしろ、移行後の確認作業こそが、新システムを安定稼働させるための最終関門です。データ移行は、データを新システムに投入した瞬間がゴールではなく、「新システムが正しく動き、業務が問題なく開始できる状態」になって初めて成功と言えます。

1. データ件数・整合性の最終チェック

移行後の最初の作業は、データが正しく移行されているかの最終確認です。

• 確認すべきポイント

• • 旧システムと新システムで件数が一致しているか
  • 必須項目が欠けていないか
  • 変換ルールが正しく適用されているか
  • コード体系が統一されているか
  • 外部キー制約に違反していないか

• よくある問題例

• • 一部のデータが抽出漏れしていた
  • 変換ルールの例外パターンが適用されていない
  • NULL値が新システムでエラーになっている
  • 桁数オーバーでデータが切れている

 

2. 新システムでの動作確認

データが正しく移行されていても、画面で正しく表示されるとは限りません。

• 確認すべき動作

• • 画面でデータが正しく表示されるか
  • 検索・フィルタが正常に動作するか
  • 一覧画面での並び順が正しいか
  • 詳細画面で項目が欠けていないか
  • 関連データが正しく紐づいているか

• なぜ画面確認が重要なのか

• • UI側でフォーマットが合わず表示崩れが起きる
  • 文字コードの違いで文字化けが発生する
  • 想定外のデータが画面の制御を壊す

 

3. 業務部門による受け入れ確認（UAT）

データの正しさを最も判断できるのは、実際にそのデータを使う業務部門です。

• 業務部門に確認してもらう内容

• • 日常業務で使う通りに画面が動作するか
  • 必要なデータが揃っているか
  • 取引データの整合性
  • マスタデータの正しさ
  • 業務フローが問題なく回るか

• UATでよくある指摘

• • 「この項目が空欄になっている」
  • 「検索結果が想定と違う」
  • 「旧システムと値が違う」
  • 「コード変換が間違っている」

 

4. 稼働初日のサポート体制を整える

新システムの稼働初日は、どれだけ準備しても何かしらの問い合わせが発生します。
そのため、サポート体制を事前に整えておくことが不可欠です。

• サポート体制の例

• • 専用の問い合わせ窓口（チャット・電話）を用意
  • ベンダーの待機体制を確保
  • 業務部門のキーユーザーを配置
  • トラブル対応の優先順位を決めておく

• 稼働初日に起きやすいトラブル
  • ログインできない
  • 権限設定が間違っている
  • 一部の画面が表示されない
  • データが見つからない
  • 印刷フォーマットが崩れる

 

5. 稼働後のフォローアップ

稼働初日が終わっても、数日〜数週間はフォローが必要です。

• フォローアップ内容

• • 問い合わせ内容の分析
  • 権限や設定の微調整
  • データの追加修正
  • 業務フローの改善提案
  • ベンダーとの改善点共有

第10章　まとめ

新システム導入におけるデータ移行は、単なる技術作業ではありません。旧システムの理解、データの整理、マッピング、方式選定、テスト移行、本番移行計画、そして稼働後の確認まで、複数の工程が連動して初めて成功する“総合プロジェクト”です。

特に、初めてシステム導入に関わる人にとっては、「どこから手をつければいいのか」「何を準備すればいいのか」と不安を感じる場面も多いはずです。

データ移行で起きるトラブルの多くは、準備不足に起因しています。

• 移行対象が曖昧
• 旧システムのデータ構造を把握していない
• データクレンジングが不十分
• マッピングが曖昧
• 移行方式の選定が甘い
• テスト移行が不足している
• 本番移行計画が不十分

これらはすべて、事前準備で防げるものばかりです。

逆に言えば、準備さえしっかりしていれば、データ移行は必ず成功に近づくということです。

また、データ移行は情シスだけで完結する作業ではありません。
業務部門、ベンダー、インフラ担当など、複数のチームが関わります。

• 業務部門：データの意味と正しさを判断
• ベンダー：新システムの仕様と移行ツールを提供
• 情シス：全体統括と技術的判断
• インフラ：環境構築と安定稼働の支援

それぞれの役割が噛み合って初めて、スムーズな移行が実現します。

 

データ移行は大変な作業ですが、新システムが無事に稼働し、業務がスムーズに回り始めた瞬間、その苦労は必ず報われます。

この記事がプロジェクトの成功に少しでも役立てば嬉しい限りです。

• 【UiPath Orchestrator】少ない工数でロボットを安定的に運用するための管理ツール