古い業務システムの中身を知る人がいない…クラウド移行の前に棚卸しする6つのことと進め方

2026年8月28日2026年10月8日

長年使ってきた社内の業務システム。作った人はもう社内におらず、開発会社の担当者も代わり、「このシステムが何をしているのか」を説明できる人が誰もいない。そんな状況でクラウド移行の話が出ると、何から手をつければいいのか途方に暮れてしまいます。

「古い業務システムの中身を知る担当者がいない。クラウド移行の前に何を棚卸ししればいいのか分からない…」

先に結論をお伝えします。移行の見積もりを取る前に、「何が動いているか」「何とつながっているか」「誰がいつ使っているか」を、A4数枚の一覧表にまとめておきましょう。ソースコードを読める人がいなくても、この棚卸しの大半は発注者側で進められます。そして棚卸しの結果しだいで、移行しない・やめる・作り直すという選択肢まで見えてきます。

この記事では、棚卸しが必要な理由、発注者が進める6つの項目、開発会社に頼むべきこと、そのまま使えるチェックリストと質問例を解説します（執筆時点：2026年10月）。

なぜ「移行の前に棚卸し」が必要なのか

見積もりの前提が「分からないこと」だらけになる

システムの中身が分からないまま「クラウドに移したい」と相談すると、開発会社は分からない部分を多めに見積もるか、「調査してみないと分かりません」と答えるしかありません。結果として、見積もりが高くなる、あるいは移行作業の途中で想定外の発見が続いて追加費用や遅れにつながります。

動かしてみて初めて分かる「隠れた依存」がある

古いシステムでは、設計書に載っていないつながりがよく見つかります。たとえば、毎晩決まった時刻に動く自動処理、別の部署のExcelから読み込まれるファイル、特定のサーバーの住所（IPアドレス）に固定された外部システムとの連携などです。これらは移行後に動かなくなって初めて気づかれがちです。

公的なガイドも「まず棚卸し」を前提にしている

AWS（アマゾンウェブサービス）が公開している移行ガイドでも、移行の最初の段階で、対象の一覧（アプリケーションとインフラの目録）を作り、依存関係を把握し、システムごとに移行のやり方を決める流れが示されています。

📰 出典：AWS Prescriptive Guidance「Discovery acceleration and initial planning」

このガイドでは、最初の一覧づくりでデータの抜けを洗い出すこと、一覧の情報の「正」を1か所に決めておくこと、依存関係が少ない単純なものから始めることが挙げられています。大企業向けの内容ですが、考え方は中小企業の業務システムにもそのまま使えます。

発注者が進める6つの棚卸し項目

1. 何が動いているか：システムの一覧

まずは「どのシステムが、どこで動いているか」を表にします。社内でWindowsのサーバーが1台あるのか、パソコン上のAccessやExcelマクロで動いているのか、レンタルサーバーに置いてあるのかを確かめます。

システム名（社内での呼び名でかまいません）
動いている場所（サーバー、レンタルサーバー、特定のパソコンなど）
使っているソフト（OS、データベース、プログラミング言語。分かる範囲で）
契約している会社（保守・サーバー・ドメイン）

分からない欄は空欄のままで構いません。「分からない」と分かること自体が、棚卸しの成果です。

2. 誰がいつ使っているか：利用状況

次に、実際に使われているかを確かめます。AWSのガイドでは、移行対象から外す（廃止＝Retire）候補の目安として、CPUやメモリの利用がごくわずかなシステムや、過去90日間に外部からの接続がないシステムが例に挙げられています。

📰 出典：AWS Prescriptive Guidance「About the migration strategies」

ここでは専門ツールがなくても、「ログインしている人は月に何人か」「最後に使われたのはいつか」「月末だけ動く処理はあるか」を担当部署に聞くだけで、かなり見えてきます。使われていないシステムを移行するのは、お金の無駄です。

3. 何とつながっているか：連携と自動処理

古いシステムで一番見落としやすいのがここです。

他のシステムとのデータのやり取り（会計ソフト、販売管理、取引先とのファイル交換など）
夜間・月末に自動で動く処理（バッチ処理）
メールの送信、帳票の自動出力、FAXやプリンターとの連携
担当者が手作業で行っている「毎月この日にこのファイルをここに置く」といった運用

AWSのガイドでも、依存関係には通信量などの技術的なものだけでなく、運用面の事情といった技術以外のつながりも含まれ、どれを同時に移す必要があるかの判断材料になると説明されています。

📰 出典：AWS Prescriptive Guidance「Portfolio analysis and migration planning」

4. どんなデータを持っているか：データの種類と重要度

個人情報、取引先情報、財務データなど、扱っているデータの種類と、止まった・漏れたときの影響を整理します。AWSのガイドでも、データを国内に置く必要がある場合など、セキュリティや法令の事情は「移行しない（Retain）」判断の理由になりうるとされています。個人情報の取り扱いについては、法令の個別判断が必要な場合は専門家に確認してください。

5. 壊れたら誰が困るか：重要度と止められる時間

「半日止まっても大丈夫か」「月末の3日間は絶対に止められないか」を、業務側の人と決めます。この答えによって、移行の方法（一度に切り替えるのか、並行運転するのか）と費用が変わります。

6. 誰が持っているか：契約・権限・ソースコード

最後に、権利と鍵の確認です。

ソースコードや設計書が手元にあるか（開発会社が持っていないか）
サーバーやドメインの契約名義と、管理画面のIDとパスワードの管理者
利用しているソフトのライセンスは、クラウド上で使えるか（契約確認が必要）
保守契約の範囲と終了時期

ソースコードが見当たらない場合は、移行ではなく作り直しを含めて検討する必要が出てきます。

棚卸しの結果で、進め方が変わる

AWSの移行戦略では、移行のやり方を「そのまま移す（Rehost）」「一部を最適化して移す（Replatform）」「作り直す（Refactor）」「入れ替える（Repurchase）」「やめる（Retire）」「今は移さない（Retain）」などに分けて考えます。同じガイドには、作り直しは最も複雑で費用がかかるため、大規模な移行では他の方法が難しいときに選び、可能なら移行後に段階的に改善するのがよいとされています。

棚卸しで分かったこと	考えられる方向
ほとんど使われていない	廃止（やめる）も候補。データだけ保管する
使われているが中身は触りたくない	まずそのまま移す。改善は移行後に
ソフトが古すぎて動かし続けられない	一部を新しくして移す、または入れ替える
特殊な機器や制約がある	今は移さず、他を先に進める
ソースコードがなく、誰も直せない	作り直しや市販サービスへの入れ替えを検討

どれが正解かは状況しだいです。開発会社には、棚卸しの一覧を渡したうえで、システムごとにどの方向がよいか、理由と費用感を出してもらうのが現実的です。

やりがちな失敗

担当者がいないからと、棚卸しを丸ごと開発会社に任せる：調査費がかさむうえ、業務の事情（月末だけ動く処理など）は現場にしか分かりません
サーバーの中身だけ見て、人の手作業を見落とす：「毎月Aさんがファイルを置く」運用に依存していると、移行後に止まります
全部を一度に移そうとする：AWSのガイドでも、依存が少なく単純なものから始めることが勧められています
使われていないシステムまで、そのまま移す：クラウドでは動かすだけで毎月費用がかかります。移行後の費用の見方はクラウド移行したらサーバー代が高くなった…移行前に比べておくべき5つの費用も参考にしてください
「移行すべきか」の判断を棚卸しの前にする：そもそも移行すべきかはオンプレの業務システムをAWSへ移行すべき？の視点で考えますが、その判断材料は棚卸しで集まります