レガシーサーバーの
クラウド移行ガイド
NTP・コンソール・UNIXサーバー別の実務

はじめに：レガシーサーバーを移行すべきか、延命すべきか

「レガシーマイグレーション」で検索すると、リホスト・リライト・リビルドといった手法の解説記事は山ほど見つかります。しかし実際の移行プロジェクトで頭を悩ませるのは総論ではなく、「このNTPサーバーはクラウドに持っていくのか？」「コンソールサーバー経由でやっていた障害対応はどうなる？」「SolarisのバイナリはEC2で動くのか？」といった、サーバー1台1台の具体的な処遇です。

本記事では、あえて総論を最小限に絞り、サーバーの種別ごとに「クラウドで何に置き換わるのか／置き換わらないのか」を整理します。対象は、レガシー環境で特に相談の多い次の4種です。

• NTPサーバー（構内の時刻同期基盤）
• コンソールサーバー（シリアル経由の帯域外管理）
• UNIXサーバー（Solaris・AIX・HP-UXなどの商用UNIX機）
• メインフレーム（「サーバーレス化したい」という相談への現実解）

移行判断の基本構図：EOL・保守費・人材 vs 移行リスク

移行を検討するきっかけはほぼ共通しています。ハードウェアの保守期限切れ（EOL）と部品調達難、年々上がる保守費、そしてそのOSを触れる技術者の枯渇です。一方で移行には、業務停止リスク・互換性検証・移行費用というコストが伴います。

判断のポイントは「移行しない場合のコスト」を正しく見積もることです。延命保守費は目に見えますが、障害時に復旧できる人がいないリスクやハード故障で業務が数週間止まるリスクは帳簿に載りません。保守契約が切れた（あるいはベンダーに更新を断られた）時点で、実質的には「いつ止まってもおかしくない資産」になっている——ここを経営層と共有できるかが、プロジェクト立ち上げの分水嶺になります。本記事の各論は、自治体のSolaris 10/SPARC基幹システムをOCIへ移行した弊社案件などで実際に判断した内容がベースです。

7R分類の実務的な使い方

移行手法の分類として現在よく使われるのが「7R」です。もともとはガートナーのリサーチノート「Migrating Applications to the Cloud: Rehost, Refactor, Revise, Rebuild, or Replace?」で示した5分類が原型で、その後AWSが6R、さらにRelocateを加えた7Rへ拡張し、現在はAWSのPrescriptive Guidance（大規模移行ガイド）に整理されています。

実務でのコツは、7Rを「どの手法を選ぶか悩むためのフレームワーク」ではなく、サーバー台帳のラベルとして使うことです。アセスメントで全サーバーに7Rのいずれかを機械的に割り付けると、「Rehostで済む8割」と「Replatform以上が必要な2割」が仕分けされ、費用も期間もこの時点でほぼ骨格が決まります。悩むべきはラベルの境界にいる少数のサーバーだけです。

そして本記事の主題であるNTP・コンソール・UNIXサーバーは、いずれも「Rehostでは済まない側」の代表格です。以降、種別ごとに見ていきます。

NTPサーバーのクラウド化｜時刻同期サービスで代替できるか

サーバー室の片隅で動き続けている構内NTPサーバー。クラウド移行の設計時に「これも移すのか？」と必ず話題になりますが、結論から言うと、クラウド上のサーバー群の時刻源としては、NTPサーバーを移設する必要はほぼありません。主要クラウドはいずれも、インスタンスからインターネット接続なしで到達できる時刻同期サービスを標準提供しているためです。

設定も難しくありません。たとえばchronyの場合、AWSとOCIではそれぞれ次の1行が時刻源の指定になります（近年の公式イメージでは最初から設定されています）。

# AWS（/etc/chrony.conf）
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

# OCI（/etc/chrony.conf）
server 169.254.169.254 iburst

# Azure Linux（ホスト時刻をPTP参照クロックとして使う場合）
refclock PHC /dev/ptp_hyperv poll 3 dpoll -2 offset 0 stratum 2

専用NTPサーバーが「残る」3つのケース

一方で、次のケースでは構内NTPサーバー（またはその後継）が残ります。移行設計で見落とすと、切替後に「オンプレ側の機器の時刻がずれていく」事故につながります。

1. オンプレに残る機器群の時刻源：クラウド移行後も、ネットワーク機器・入退室管理・監視カメラ・製造装置などはオンプレに残ります。クラウドのリンクローカル時刻サービスはインスタンス内部からしか使えないため、残置機器の時刻源として構内NTP（または上位としてNICTの公開NTP ntp.nict.jp 等）が引き続き必要です。
2. GPS時刻源・Stratum 1が要件のシステム：GPS/GNSS受信機を持つStratum 1アプライアンスを自前運用しているのは、外部ネットワークに依存しない時刻源が要件だからです。この要件自体が変わらない限り、クラウドの時刻サービスでは代替になりません。
3. 閉域網・監査要件：インターネット非接続の閉域網では公開NTPが使えず、また監査・認証（ISO/IEC 27001やPCI DSSなど）で「単一の参照時刻源との同期」を管理・証明することが求められる環境では、時刻源の構成変更自体が監査対象になります。「クラウドの時刻サービスに変えました」で通るか、事前に監査側と握っておくべきポイントです。

コンソールサーバーのクラウド化｜シリアルコンソールと踏み台設計

コンソールサーバー（シリアルコンソール集約装置）の役割は、「ネットワーク経由でログインできなくなったサーバー・機器に、シリアルポート経由の最後の入口を確保する」帯域外（アウトオブバンド）管理です。OSがブートしない、ファイアウォール設定を誤って自分を閉め出した——そんなときの命綱でした。

クラウドではこの役割が2つに分解され、それぞれ標準機能で置き換わります。

「最後の入口」はクラウドのシリアルコンソール機能へ

主要クラウドは仮想マシンに対するシリアルコンソール接続を提供しています。AWSのEC2シリアルコンソールは、インスタンスのネットワーク状態に関係なく、シリアルポート直結相当の接続でブートログの確認やシングルユーザーモードでの復旧作業ができます。Azureにもシリアルコンソール、OCIにもインスタンス・コンソール接続があり、「SSHできなくなったら詰み」という状況は物理時代と同様に回避できます。

平常時の管理アクセスは踏み台設計へ

コンソールサーバーが担っていた「管理アクセスの集約点・操作ログの取得点」という役割は、クラウドでは踏み台（Bastion）設計に引き継がれます。近年はSSHポートを一切開けずにブラウザ・CLIから接続できるAWS Systems Manager Session Manager、Azure Bastion、OCI Bastionのようなマネージド踏み台が主流で、操作ログの保全・接続の認可をIAMで一元管理できます。「誰がいつどのサーバーに入ったか」の証跡は、物理コンソールサーバー時代より格段に取りやすくなりました。

残置ハードとのハイブリッド構成

もうひとつ。コンソールサーバー自体は完全には無くなりません。オンプレやコロケーションに残るルーター・スイッチ・ストレージ・UPSなどのシリアル管理ポートには、引き続き物理的な接続手段が必要です。実務では「クラウド側はシリアルコンソール機能＋マネージド踏み台」「オンプレ残置機器には小型コンソールサーバーを残す（回線断に備えLTE等の別経路を持たせる）」というハイブリッドに落ち着くケースが多く、台数を10分の1に減らして役割を限定するのが落ち着きどころです。

UNIXサーバー（Solaris・AIX・HP-UX）のクラウド移行

レガシー移行で最も技術的なハードルが高いのが商用UNIXです。まず前提から。AWS・Azureの通常のIaaSでは、Solaris・AIX・HP-UXは動きません。x86 Linux/Windows前提のハイパースケーラーに、SPARC・POWER・PA-RISC/Itaniumのバイナリをそのまま持ち込むことはできないのです。

OS互換の壁：何がそのまま動かないのか

• CPUアーキテクチャ：SPARC（Solaris）・POWER（AIX）のバイナリはx86では実行できません。ソースコードからの再コンパイルが必須で、ソースが失われている場合は再開発かエミュレーションの検討になります。
• エンディアン：SPARC・POWERはビッグエンディアン、x86はリトルエンディアン。バイナリ形式のデータファイルや独自形式のDBは、単純コピーでは読めません。DBはエクスポート／インポート（論理移行）が基本です。
• 文字コード：古いUNIX環境はEUC-JPやShift_JISが多く、移行先LinuxはUTF-8が標準。ファイル名・DB・帳票・連携ファイルの文字コード変換とテストが工数の山になります。
• OS固有機能：Solaris Zones、ZFS、SMF、AIXのLPAR/WPARなど、OS固有機能に依存した構成は移行先での代替設計（コンテナ化・VM分離など）が必要です。シェルの方言（Solaris shとbashの差異、/usr/bin/awkと/usr/xpg4/bin/awkの挙動差など）も地味に効いてきます。

OS別の現実的な移行パス

つまりUNIXサーバーの移行は、7RでいうReplatform（OS転換を伴う載せ替え）が主戦場です。リホストのつもりで見積もると、互換性対応・再テストの工数が丸ごと漏れます。逆に「全部作り直し（Refactor）しかない」と思い込むのも早計で、ミドルウェアから上の互換性を丁寧に検証すれば、アプリ資産を活かしたOS転換で済むことは珍しくありません。

なお、ハードウェアEOLを機に古い資産を移行するという構図は、組込み分野のマイコンでも同じです。SuperHマイコンのEOL対応をまとめたSH（SuperH）マイコン移行ガイドも併せてどうぞ。サーバーもマイコンも、「動いているうちに、資産が読めるうちに」動くのが鉄則です。

メインフレームは「サーバーレス化」できるか

「メインフレームをサーバーレスにしたい」という相談を受けることがあります。一足飛びのサーバーレス化は現実的ではありません。バッチ・オンライン(CICS等)・JCL・データセットが密結合したモノリスを一括変換するリスクが大きすぎるためです。

落としどころは、段階的モダナイゼーションです。

1. まずクラウドで動かす：AWS Mainframe Modernizationのようなサービスで、リプラットフォーム（メインフレーム互換ランタイムでの稼働）または自動リファクタリング（COBOL→Java変換）によりクラウド上に移す。国内でも基幹システムでの活用事例が公表されています。
2. 周辺から剥がす：帳票・照会系・バッチの一部など、切り出しやすい機能からAPI化してマネージドサービスやサーバーレスに置き換える。いわゆるストラングラーフィグ（絞め殺しの木）パターンで、移行中は新旧が連携しながら共存します。
3. コアは最後に：勘定系・基幹バッチの中核は、周辺の置き換えでリスクと規模を十分に削ってから着手する。

「サーバーレス」は最初のゴールではなく、クラウド移行後の継続的な改善の到達点と捉えるのが健全です。提案書では『サーバーレス化』を最終形の絵として置き、初年度のスコープは『クラウドで現行同等に動かす』までに切る——この二段構えにしないと稟議も工程も持ちません。

移行プロジェクトの進め方と見積もりの考え方

種別ごとの各論を踏まえた上で、プロジェクト全体はアセスメント→PoC→段階移行の3段階で進めます。

Step 1. アセスメント（現状調査）

全サーバーの台帳を作り、OS・ミドルウェア・依存関係・データ量・利用状況を棚卸しして、1台ごとに7Rのラベルを付けます。レガシー環境では「ドキュメントがない」「作った人がいない」が普通なので、構成管理ツールの出力だけでなく、実機のプロセス・cron・接続先の実態調査が欠かせません。この段階でRetire（実は使われていない）を洗い出せると、移行対象そのものが減ります。

Step 2. PoC（技術検証）

リスクの高い1〜2システムを選び、小さく移行して検証します。UNIX移行なら「主要アプリが移行先OSでビルド・動作するか」「DBの論理移行が業務停止許容時間内に終わるか」、NTP・コンソールのような基盤系なら「切替後の運用手順が回るか」。PoCの結果で本移行の見積もりを確定させる——この順番を崩さないことです。

Step 3. 段階移行

影響の小さいシステムから数回のウェーブに分けて移行します。基幹系は並行稼働期間（新旧同時稼働での突合）を設け、切り戻し手順を用意した上で、業務カレンダー上の閑散期に本番切替を行います。前述の自治体案件では、税務の年度末繁忙期を避けた10月〜1月に工期を設定し、2週間の並行稼働を経て週末夜間に切り替えました。

見積もりの考え方

費用は概ね次の構造で積み上がります。

発注側として見積もりの妥当性を測るなら、「7Rの内訳を提示しているか」「PoCフェーズが切られているか」「停止許容時間を確認してきたか」の3点を見てください。この3つを聞かずに一式いくらを出してくるベンダーの見積もりは、ほぼ確実に後で膨らみます。

相見積もりを取る前に、最低限これだけ揃えてください。①サーバー一覧（ホスト名・OS/バージョン・ハード保守期限）②主要ミドルウェアとライセンス形態（Oracle DB等はBYOL可否に直結）③連携先システムの一覧 ④業務ごとの許容停止時間 ⑤データ量。この5点があるだけで、初回見積もりの精度と速度がまったく変わります。

まとめ

レガシーサーバーの移行は、「総論」ではなく1台ごとの各論の積み重ねです。自社の台帳を前に判断に迷うサーバーがあれば、お気軽にご相談ください。

よくある質問（FAQ）