# レガシーサーバーのクラウド移行ガイド｜NTP・コンソール・UNIXサーバー別の実務｜株式会社テクノスフィア

> レガシーマイグレーションを「サーバー種別ごとの各論」で解説。NTPサーバーはAmazon Time Sync等で代替できるか、コンソールサーバーの役割はEC2シリアルコンソールで置き換わるか、Solaris/AIXなどUNIXサーバーのリホスト可否まで。官公庁のSolaris→OCI移行を手がけたテクノスフィアが実務目線で整理します。

URL: https://technosphere.co.jp/blog/legacy-server-cloud-migration-guide

** 目次
1. はじめに：レガシーサーバーを移行すべきか、延命すべきか
2. 7R分類の実務的な使い方
3. NTPサーバーのクラウド化｜時刻同期サービスで代替できるか
4. コンソールサーバーのクラウド化｜シリアルコンソールと踏み台設計
5. UNIXサーバー（Solaris・AIX・HP-UX）のクラウド移行
6. メインフレームは「サーバーレス化」できるか
7. 移行プロジェクトの進め方と見積もりの考え方
8. まとめ

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

 「レガシーマイグレーション」で検索すると、リホスト・リライト・リビルドといった手法の解説記事は山ほど見つかります。しかし実際の移行プロジェクトで頭を悩ませるのは総論ではなく、「この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（大規模移行ガイド）に整理されています。
| 戦略 | 内容 | レガシーサーバーでの典型例 |
| Retire（廃止） | もう使われていないものを止める | 役目を終えた開発機・検証機。移行対象の1〜2割は実はこれ |
| Retain（残置） | 今回は移行しない | 専用ハード直結の装置制御サーバー、更新間近のシステム |
| Rehost（リホスト） | 構成を変えずIaaSへ「リフト&シフト」 | Linux/WindowsサーバーのVM移行。最速・最安 |
| Relocate（リロケート） | 仮想化基盤ごとクラウドへ移設 | VMware環境をハイパーバイザーごと移す |
| Replatform（リプラットフォーム） | OS・ミドルウェアを変えて載せ替え | Solaris→Linux転換、DBのマネージドサービス化。UNIX移行はほぼこれ |
| Repurchase（再購入） | SaaSに乗り換える | 自前グループウェア・メールサーバー→SaaS |
| Refactor（リファクタリング） | クラウドネイティブに作り直す | 基幹アプリのマイクロサービス化・サーバーレス化 |

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

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

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

 サーバー室の片隅で動き続けている構内NTPサーバー。クラウド移行の設計時に「これも移すのか？」と必ず話題になりますが、結論から言うと、**クラウド上のサーバー群の時刻源としては、NTPサーバーを移設する必要はほぼありません**。主要クラウドはいずれも、インスタンスからインターネット接続なしで到達できる時刻同期サービスを標準提供しているためです。
| クラウド | 時刻同期サービス | エンドポイント／方式 | 特徴 |
| AWS | Amazon Time Sync Service | NTP: `169.254.169.123`（リンクローカル） | インターネット接続不要。一部の対応インスタンス（第7世代以降の対応ファミリー＋ENAドライバ2.10.0以降のLinux）ではPTPハードウェアクロックによるマイクロ秒精度も利用可 |
| Azure | ホスト時刻同期（VMICTimeSync） | PTP: `/dev/ptp_hyperv`（Linuxはchronyのrefclockとして参照） | Azureホストの時刻をPTPクロックソースとして提供。新しめのディストリビューションは設定済み |
| OCI | OCI NTPサービス | NTP: `169.254.169.254`（VCN内） | インターネット接続不要。近年のプラットフォームイメージはchrony設定済み |
| Google Cloud | 内部NTPサーバー | NTP: `metadata.google.internal` | Google推奨の構成。うるう秒はスメア方式 |

設定も難しくありません。たとえば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など）で「単一の参照時刻源との同期」を管理・証明することが求められる環境では、時刻源の構成変更自体が監査対象になります。「クラウドの時刻サービスに変えました」で通るか、事前に監査側と握っておくべきポイントです。
  ** 実務の落とし穴：うるう秒スメアリングの混在

AWSやGoogleの時刻サービスは、うるう秒を24時間かけて少しずつ吸収するスメア方式を採用しています。一方、NICTの公開NTPなど非スメアの時刻源とスメア方式の時刻源を同じサーバーの時刻源として混在させると、うるう秒前後に数百ミリ秒級の不整合が生じます。ハイブリッド構成では「クラウド側はクラウドの時刻サービス、オンプレ側は構内NTP」と系統を分け、片系統内で時刻源を統一するのが定石です。

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

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

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

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

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

EC2シリアルコンソールはデフォルト無効で、アカウント単位の許可設定とIAMポリシーの付与が必要です。またWindowsではSAC（特別管理コンソール）の事前有効化が要ります。物理コンソールサーバーは「つながっていれば使えた」のに対し、クラウドのシリアルコンソールは平時に設定・訓練しておかないと障害時に使えません。移行後の運用設計に必ず組み込んでください。

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

 コンソールサーバーが担っていた「管理アクセスの集約点・操作ログの取得点」という役割は、クラウドでは踏み台（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別の現実的な移行パス
| 移行元 | リホスト可否 | 現実的な選択肢 |
|  Solaris 11.4（x86） |  条件付きで可 |  OCI MarketplaceにOracle公式のSolaris 11.4イメージ（VM/ベアメタル）があり、OSをSolarisのまま移せる事実上唯一のパス。Oracleサポート付き。SPARC版からはアプリの再コンパイルが必要 |
|  Solaris 10（SPARC） |  不可 |  EOL済みでクラウド上の受け皿もないため、Linuxへのリプラットフォームが本命。Oracle DB中心のシステムならライセンス持ち込み（BYOL）ができるOCIが有力候補 |
|  AIX（POWER） |  専用基盤なら可 |  通常のIaaSでは不可だが、IBM Power Virtual Server（IBM Cloud）やKyndryl Cloud Uplift（旧Skytap on Azure。2026年に東京・大阪リージョンでも提供開始）などクラウド上のPOWER基盤でAIXのまま移行する選択肢がある。長期的にはLinux転換を並走させるケースが多い |
|  HP-UX（PA-RISC/Itanium） |  不可 |  クラウド上の受け皿がなく、Linuxへのリプラットフォーム一択に近い。ISVパッケージ利用時は後継製品のLinux版への乗り換えを軸に計画 |

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

弊社が担当した自治体様の案件では、SPARC T5240＋Solaris 10＋Oracle DB 11gの税務・住民台帳連携システムを、OCIベアメタル＋Oracle Linux 8＋Oracle DB 19cにリプラットフォームしました（事例ページではRe-host + Upgradeと表記しています）。既存のOracle DBライセンスをBYOLでOCIに持ち込んでコストを抑え、Data Pumpで約850GBのDBを論理移行、Data Guardで東京—大阪のDR構成まで含めて約4ヶ月・計画停止は週末夜間2時間。ハードウェア維持費は年間約480万円からゼロ（移行後のOCI利用料は別途発生しますが、ハード更改費を含む5年TCOで比較して削減）になり、可用性99.95%を達成しています。詳細は[事例ページ「Solaris/SPARCで動く税務系基幹システムをOCIへ移行」](https://technosphere.co.jp/cloud-migration/government-solaris-oci)をご覧ください。

 なお、ハードウェアEOLを機に古い資産を移行するという構図は、組込み分野のマイコンでも同じです。SuperHマイコンのEOL対応をまとめた[SH（SuperH）マイコン移行ガイド](https://technosphere.co.jp/blog/superh-sh-migration-guide)も併せてどうぞ。サーバーもマイコンも、「動いているうちに、資産が読めるうちに」動くのが鉄則です。

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

 「メインフレームをサーバーレスにしたい」という相談を受けることがあります。**一足飛びのサーバーレス化は現実的ではありません**。バッチ・オンライン(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の内訳。Rehost 1に対しReplatformは数倍の工数が目安。ネットワーク（閉域接続・VPN）設計も含む |
| データ移行 | データ量より許容停止時間が支配的。停止ゼロ要件は差分同期の仕組みが必要になり跳ね上がる |
| テスト・並行稼働 | 連携先システムの数。レガシー基幹は連携テストが工数の過半を占めることも |
| 移行後ランニング | クラウド利用料。BYOL（ライセンス持ち込み）や リザーブド/コミット割引の設計で大きく変わる |

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

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

## まとめ

###  上司に説明するなら、この3点です
- 商用UNIXはAWS/AzureのIaaSでは動かないため、リホスト前提の概算は必ず膨らむ
- 費用は7Rの内訳と許容停止時間でほぼ決まる
- NTP・コンソールはクラウド標準機能で置き換わるが、オンプレ残置分の設計を忘れると事故る

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

### Solaris・UNIX・レガシーサーバーのクラウド移行

官公庁のSolaris/SPARC→OCI移行をはじめ、AWS / Azure / GCP / OCI / さくらのクラウドへの移行を受託しています。アセスメント（現状調査）だけのご依頼も歓迎です。初回ヒアリング・概算見積もりは無料。  [クラウド移行サービスを見る](https://technosphere.co.jp/cloud-migration) [移行の無料相談](https://technosphere.co.jp/contact)

## よくある質問（FAQ）   ** SolarisサーバーはAWSやAzureにそのまま移行できますか？

できません。AWS・Azureの通常のIaaSは商用UNIX（Solaris/AIX/HP-UX）をサポートしていません。x86版のOracle Solaris 11.4はOCI Marketplaceの公式イメージで稼働できますが、SPARC版のバイナリはx86上でそのまま動かないため、多くの案件ではLinuxへのリプラットフォーム（OS転換＋再構築）が現実解になります。   ** NTPサーバーはクラウド移行後も必要ですか？

クラウド上のサーバーの時刻同期は、Amazon Time Sync Service（`169.254.169.123`）やOCIのNTPサービス（`169.254.169.254`）など各クラウド標準の時刻同期サービスで代替でき、専用NTPサーバーの移設は不要なことがほとんどです。ただしオンプレに残る機器群の時刻源、GPS受信機を持つStratum 1環境、閉域網、時刻源の指定がある監査要件では構内NTPが残ります。   ** コンソールサーバー経由の障害対応はクラウドでどうなりますか？

OSが起動しない・ネットワーク設定を壊したという場面には、EC2シリアルコンソールやAzureシリアルコンソール、OCIのインスタンス・コンソール接続が用意されており、物理コンソールサーバーの主用途を代替できます。平常時の管理アクセスは踏み台（Bastion）やAWS Systems Manager Session Managerに寄せる設計が一般的です。ネットワーク機器などオンプレに残るハードには引き続きコンソールサーバーが必要です。   ** メインフレームをサーバーレス化することは可能ですか？

一足飛びのサーバーレス化は現実的ではありません。まずAWS Mainframe Modernizationなどでリプラットフォームまたは自動リファクタリング（COBOL→Java変換）を行い、クラウド上で稼働させた後、周辺機能から段階的にマネージドサービスやサーバーレスへ置き換えるストラングラーフィグ（段階的置換）型のアプローチが推奨されています。   ** レガシーサーバーのクラウド移行費用はどうやって見積もりますか？

サーバー台帳をもとに1台ごとに7R（リホスト・リプラットフォーム等）のラベルを付け、パターン別の移行工数×台数で積算するのが基本です。リホストとリプラットフォームでは工数が数倍違うため、アセスメントでこの仕分けを先に確定させることが見積もり精度を左右します。弊社では[初回ヒアリングと概算見積もりを無料](https://technosphere.co.jp/contact)で行っています。      # レガシーマイグレーション # クラウド移行 # UNIXサーバー # Solaris # NTPサーバー # コンソールサーバー # OCI # 7R

##   次に読む｜クラウド移行・レガシー関連
-  [移行実績 公共・自治体｜Solaris/SPARCの税務系基幹システムをOCIへ移行 本記事で紹介したSolaris 10→OCI移行の事例詳細（4ヶ月・可用性99.95%）](https://technosphere.co.jp/cloud-migration/government-solaris-oci)
-  [サービス クラウドマイグレーション・コスト最適化 AWS / Azure / GCP / OCI / さくらのクラウド対応。逆移行（クラウド→オンプレ）も](https://technosphere.co.jp/cloud-migration)
-  [レガシー移行シリーズ SH（SuperH）マイコン移行ガイド EOLマイコンの移行という「組込み版レガシーマイグレーション」](https://technosphere.co.jp/blog/superh-sh-migration-guide)
-  [レガシー移行シリーズ 8051・Z80レガシーマイコン移行ガイド 数十年モノの資産を安全に現行環境へ移すノウハウ](https://technosphere.co.jp/blog/8051-z80-legacy-migration-guide)
    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)