移行計画書のデータ移行の欄に「過去3年分」と書いてある。なぜ3年なのかを聞くと、前回のプロジェクトがそうだったから、という答えが返る。5年と書いてある会社もあれば、全件と書いてある会社もある。どの数字にも根拠がないのに、この一行が移行費用とテスト工数とカットオーバーのリスクを一番大きく動かしている。 経理が「税務調査で必要です」と言い、情シスが「全部は無理です」と言い、決まらないまま設計が進む。順序が逆になっている。
「何年分」から議論を始めるから決まらない
年数は結論であって、出発点ではない。会議が空転しているとき、テーブルに載っているのは年数だけで、その年数が何を可能にするかは誰も語っていない。
順序を入れ替える。問いは三つだ。誰が参照するのか。何を参照するのか。いつまで参照するのか。この三つを埋めていくと、年数は最後に自動で出る。
参照者の候補は限られている。経理、税務、法務、営業、品質保証、そして監査法人。それぞれに一度ずつ「過去データを実際に見た直近の場面」を聞く。思い出せない人の要求は、要求ではなく不安である。 不安に対して支払うべき対価は、明細の全件移行ではなく、旧環境の参照権である。
保存義務は、新システムに載せる義務ではない
ここが実務で一番ひっくり返る。移行年数を膨らませている計画の多くは、保存義務を根拠に挙げている。だが条文と当局の解釈を並べると、その根拠は成り立たない。
会社法第432条第2項は、会計帳簿の閉鎖の時から十年間、会計帳簿およびその事業に関する重要な資料の保存を求める。法人税は、法人について原則7年、青色申告書を提出した事業年度で欠損金額が生じた事業年度等は10年である（国税庁No.5930 帳簿書類等の保存期間）。7年は青色申告法人に限った期間ではない。年数の水準はここで決まる。
決まらないのは、その義務を「どこで」果たすかだ。国税庁の電子帳簿保存法一問一答【電子計算機を使用して作成する帳簿書類関係】（令和8年7月）問14は、この点に正面から答えている。検索機能は現在使用しているシステムで確保しなければならないのかという問いに対し、回答は「変更前のシステムを用いること等により検索機能が確保されているのであれば、現在使用しているシステムにより検索ができなくても差し支えありません」である。解説はさらに踏み込んで、システム変更等をした場合の変更前データについて、変更前のシステムで検索機能を確保している場合がこれに該当すると書いている。
つまり当局は、旧システムで検索できることを前提として認めている。 移行しないことが問題なのではなく、参照できないことが問題なのだ。ただし条件が一つ付く。同解説は「検索に使用する電磁的記録が適用を受けて保存している電磁的記録と同一のものであることを確認できるようにしておく必要があります」としている。旧環境を残す判断をしたなら、そこにあるデータが当時保存したものと同一であると示せる状態を維持しなければならない。凍結の手続と、更新を止めた証跡がいる。
もう一つ落とし穴がある。電子帳簿保存法第7条は、電子取引を行った場合に、その取引情報に係る電磁的記録を財務省令で定めるところにより保存しなければならないと定める。かつては出力書面等による保存を認める措置があったが、令和3年度税制改正で廃止された。**電子取引で授受したデータについては、旧システムを止めるときに紙やPDFへ逃がすという手が使えない。**運用の設計は決算実務と地続きになる（電子帳簿保存法スキャナ保存・電子取引の決算実務への落とし込み）。
明細が本当に要るのは、計算がまだ続いているものだけ
判定の基準は一つでいい。新システムの側で、過去の明細を使った計算がこれから発生するか。 発生するなら明細を持ち込む。発生しないなら残高でよい。
発生する側に並ぶものは、いつも同じ顔ぶれになる。固定資産は、取得年月日・取得価額・償却累計額・耐用年数が資産単位で残っていないと、除却や売却のたびに手作業になる。リースは、契約ごとの残存期間と割引率を引き継がないと、その後の利息費用が計算できない。長期請負は進捗度の計算のために累積の原価と収益が要る。退職給付、繰越欠損金、消費税の調整対象固定資産。ここは残高では足りない。
発生しない側も、はっきりしている。売掛金と買掛金は、未決済の明細（オープンアイテム）だけあればよい。決済済みの過去伝票は、新システムでの計算に使われない。在庫も、期末数量と評価額があれば動く。過去の売掛金明細を全件移行して、稼働後に一度も開かれないという光景は、どのプロジェクトでも起きている。
SAPの標準的な打ち手も、この線で分かれている。SAP S/4HANA migration cockpitは、マスタデータ・未決済項目・残高の移行を前提にした仕組みだ。過去の伝票明細を一定期間だけ持ち込みたい場合には、SAPのSelective Data Transition（DMLTのサービス）のように、時間で区切って過去トランザクションを移す方式を選ぶことになる。方式の選択は技術の話に見えて、実際には「何年分の明細で計算が続くか」という業務側の答えが決めている（SAP移行のデータ移行で失敗しない｜マスタ品質を上げる進め方）。
移行を機に勘定科目体系を作り直す会社では、もう一段厄介になる。旧科目のまま明細を持ち込むと、新体系での比較ができない。新体系に変換して持ち込むと、当時の帳簿と一致しなくなる。過去データの移行と体系の再設計は、同時にやると必ずどちらかが濁る。 過去は旧体系のまま旧環境に残し、新体系は残高から始めるのが素直だ（SAP移行を機にする勘定科目体系（COA）の再設計｜全社で数字を揃える）。
旧環境を残すなら、年額と終了年月を先に書く
「念のため残す」は、決めていないことの言い換えである。残す判断をしたなら、三つを紙に書く。
第一に、年額の維持費。ライセンス、インフラ、OSとデータベースのサポート、バックアップ、そして年に一度の疎通確認。第二に、終了年月。保存義務の起算日から逆算して、何年何月に落とすかを西暦で書く。第三に、その環境を触れる人。維持費より先に枯れるのは、金ではなく人である。 旧システムを操作できる担当者が退職した瞬間、その環境は「あるのに使えない」状態になる。
保守の期限も効いてくる。SAP ERP 6.0の保守には2027年末に大きな区切りが来る（時期は適用している拡張パッケージのバージョンによって異なる。全体像はSAP ERP 2027年問題とは｜いつ何を決めるべきか、移行の全体像）。保守が切れた環境を参照専用として何年も置くなら、セキュリティ上の隔離とアクセス制限をどう設計するかまでが、この判断の一部になる。
旧システムを止めながらデータを保持する方向であれば、SAPにはInformation Lifecycle Management（ILM）のRetention Warehouseという標準の枠組みがある。旧システムからアーカイブ・抽出したデータを独立した保管環境へ移し、保存期間の管理と期間満了後の廃棄まで含めて扱う考え方だ。導入の要否はさておき、「旧環境をそのまま生かす」と「データだけ残して環境は落とす」は別の選択肢だという認識を、計画の早い段階で持っておく価値がある。
中堅の機械メーカーで、基幹システムの刷新にあたり過去データの移行範囲が三か月決まらなかった。経理は「税務調査で7年分を求められる」と主張し、情シスは「全件移行するとテスト期間が倍になる」と返す。どちらの主張も正しく、突き合わせても答えが出ない。議論の材料が、年数という一つの軸しかなかったからである。
材料を増やすために配ったのは、経理・税務・法務・営業・品質保証の五部門宛の一枚の表だった。列は四つ。参照する情報、直近でそれを見た時期、そのとき残高で足りたか明細が要ったか、参照先が旧システムでよいか。二週間で回収した結果、明細を実際に開いた事例は年に十数件で、そのほとんどが製品保証のクレーム対応と、固定資産の除却時だった。この会社が過去に受けた税務調査で実際に求められたのは総勘定元帳と証憑で、システム上で伝票明細を追われた場面はなかった。ここは調査官と論点によって変わるので、自社の実績で確かめる以外にない。決めたのは三つ。固定資産と長期請負は明細で新環境へ移す。売掛金・買掛金は未決済のみ、在庫は残高のみ。それ以外の過去明細は旧環境に残し、参照は情シス経由の申請制にする。旧環境の維持費は年額を確定させて予算に載せ、終了年月を保存義務の満了から逆算して西暦で書き込んだ。移行対象のテーブル数はおよそ四割減り、テストのシナリオもその分減った。稼働から一年後、旧環境への参照申請は年間で二十件に届いていない。維持費は無駄ではなかったが、全件移行していたら払っていたであろう金額とは桁が違った。
つまずくのは「誰が判定するか」の一点
順序そのものは難しくない。参照目的を洗い、残高で足りるか明細が要るかを判定し、明細が要るものだけ移す。年数はそこから決まる。実際に止まるのは、判定を誰がやるかを決めていないときだ。
判定者は業務側の部門長に置く。情シスに置くと、移行できるかどうかの技術判断とすり替わる。経理に置くと、他部門の要求を代弁するだけになって全部が「要る」になる。判定は、その情報を使う業務に責任を持つ人がやる。 名前を一覧に書き込む。
そのうえで差し戻しのルールを一つ置く。明細が要ると書いた部門には、直近の実例を一件添えてもらう。いつ、誰が、何のために、その明細を開いたか。書けなければ差し戻す。この一行があるかないかで、移行対象の量は目に見えて変わる。 移行後にデータを使い切れないという典型的な失敗も、ここで大半が防げる（SAP移行後にデータを活かしきれない理由と、活用に踏み出す最初の一手）。
残る一つは、判定が終わったあとに誰も蒸し返さないための記録だ。判定結果と、その判定をした人の名前と日付を、移行方針書に残す。稼働直前に「やっぱり過去データが要る」という声が出たとき、戻る先がここになる。
