終わらない週末メンテ
「データ移行の泥沼」
「週末で終わるはずだった」。その言葉が、エンジニアのキャリアを終わらせます。
リプレース案件の最大の難所は、新システムの開発ではなく、旧システムからのデータ移行（Migration）です。
汚れたデータの山が、あなたの計画を粉砕します。
- 移行リハーサルを「本番データ全量」で行ったことがない
- 旧システムのDBに「NULL」や「空文字」、謎の全角スペースが混在している
- 「まあ、スクリプトで一括変換すれば余裕でしょ」と思っている
- 切り戻し（ロールバック）の手順書が、「バックアップを戻す」の1行しかない
あなたはこれから、10年分の歴史（とゴミ）に向き合うことになります。
01. 99%で止まるプログレスバー
金曜の夜20時、移行スクリプトを開始。「予定終了時刻：土曜 08:00」。
しかし、土曜の朝、ログには無慈悲なエラーが。
「電話番号カラムに『また連絡します』という文字が入っています」
想定外のデータ汚れによりスクリプトは停止。修正して再実行するには、また10時間かかります。
こうして月曜の朝、全社員が「ただいまメンテナンス中です」の画面を見ることになるのです。
常に仕様書を裏切る。
02. 移行ツールの開発工数
データ移行は「1回の使い捨てスクリプト」ではありません。
エラーハンドリング、再開機能（Resume）、詳細なログ出力、バリデーション。
これらを完備した「堅牢な移行アプリケーション」を開発するつもりで工数を見積もってください。
移行ツールの品質が、プロジェクトの成否を決めます。
03. ダブルラン（並行稼働）戦略
「一発切り替え（ビッグバン移行）」は、ギャンブルです。
可能なら、新旧システムを並行稼働させ、データを徐々に同期する「ストラングラーパターン」や「ダブルラン」を検討しましょう。
移行を「点」ではなく「期間」で行うことで、リスクを分散させることができます。