Windows Serverからの移行

[更新：2026年4月3日]

Windows Serverは、さくらのクラウドがライセンス込みのパブリックアーカイブを提供しているため、比較的スムーズに移行できます。

移行の基本方針 

オンプレミスのWindows Server VMをそのままイメージ変換して持ち込む方式は、ライセンスの観点から対応していません。そのため、さくらのクラウド上で新規にWindows Serverを構築し、アプリケーションやデータを移行する方式が基本となります。

現行環境のアセスメント
- インストールされているアプリケーション、ミドルウェアの一覧作成
- 各種設定値（ネットワーク、セキュリティポリシー、レジストリ等）の棚卸し
- データ容量の確認
さくらのクラウドでのサーバ作成
- パブリックアーカイブからWindows Server 2019、Windows Server 2022またWindows Server 2025を選択
- 必要なコア数、メモリ、ディスク容量を指定してサーバを作成
- SQL Serverが必要な場合は、SQL Server込みのアーカイブを選択
アプリケーション・ミドルウェアのインストール
- 現行環境と同等のアプリケーション、ミドルウェアをインストール
- 設定値を現行環境に合わせて構成
データ移行
- ファイルサーバの場合：バックアップソフトを使用してデータをコピー
- データベースの場合：SQL Serverのバックアップ・リストア機能を使用
- アプリケーションデータ：各アプリケーションの移行手順に従う
動作確認・切り替え
- 移行後の動作確認テスト
- DNS切り替え等によるサービス切り替え

SQL Serverを使用している場合、データベースの移行には以下の方式があります。

最も一般的で基本的な方法です。

概要: 移行元のサーバーでデータベースの完全バックアップを取得し、そのバックアップファイルを移行先のサーバーで復元します。システムデータベース（master, model, msdb）の移行には通常使用しませんが、ユーザーデータベースの移行には広く用いられます。
利点:
- シンプルで分かりやすい手順です。
- ほとんどの環境で利用可能です。
- 異なるSQL Serverバージョン間の移行（アップグレード）にも利用できます（ただし、下位バージョンへの復元は原則不可）。
欠点:
- バックアップ・復元にかかる時間中、ダウンタイムが発生します。データ量が多いほど時間がかかります。
- ログイン、ジョブ、リンクサーバーなどのインスタンスレベルの設定は手動で移行する必要があります。

ダウンタイムを短縮したい場合に有効な方法の一つです。

概要: プライマリサーバー（移行元）のトランザクションログを定期的にセカンダリサーバー（移行先。今回のケースではさくらのクラウドのインスタンス）にコピーし、適用することで、ほぼリアルタイムにデータを同期します。移行の最終段階で、プライマリサーバーからセカンダリサーバーへの切り替え（フェイルオーバー）を行います。
利点:
- 移行作業中のダウンタイムを最小限に抑えることができます。
- 災害復旧（DR）ソリューションとしても機能します。
欠点:
- 基本的に同じSQL Serverバージョン間の移行に限定されます。
- 設定と監視がバックアップ/復元よりも複雑です。

最新のSQL Server環境における高可用性・災害復旧ソリューションであり、移行手段としても利用できます。

概要: 移行元サーバーと移行先サーバーをAGsのレプリカとして構成し、リアルタイム同期を行います。移行先への切り替え（計画的フェイルオーバー）により、非常に短いダウンタイムでの移行が可能です。
利点:
- ダウンタイムを極めて最小限に抑えることができます。
- 移行後も高可用性構成として維持できます。
欠点:
- SQL Server Enterprise Editionが必要となる場合があります（Basic Availability GroupsはStandard Editionでも利用可能）。
- 構成が複雑で、ネットワークやWSFC（Windows Server Failover Clustering）の知識が必要です。

データ量が少なく、ダウンタイムが許容できる場合に利用できるシンプルな方法です。

概要: 移行元のサーバーでデータベースをデタッチし、物理的なデータファイル（.mdf, .ldf）を移行先サーバーにコピーした後、移行先サーバーでデータベースをアタッチします。
利点:
- バックアップ/復元よりもファイルサイズによっては高速な場合があります。
- 手順がシンプルです。
欠点:
- デタッチ中、データベースは完全に利用不可となり、ダウンタイムが発生します。
- ファイルコピーの手間がかかります。
- 移行元と移行先のSQL Serverのバージョンやパッチレベルが近い必要があります。

データベースの一部または全体をオブジェクトレベルで移行する場合や、異なるプラットフォームへ移行する場合に利用されます。

概要: SQL Serverのインポートおよびエクスポートウィザード、またはより高度なSSISパッケージを使用して、テーブルスキーマとデータを移行先サーバーへ転送します。
利点:
- データのフィルタリングや変換を伴う移行が可能です。
- 異なるバージョンのSQL Serverや、場合によっては異なるデータベースシステムへの移行にも利用できます。
欠点:
- ストアドプロシージャ、ビュー、インデックス、ユーザーなどのオブジェクトは手動で移行する必要がある場合が多いです。
- 大量のデータを扱う場合、処理時間が長くなることがあります。

どの方法を選択されるにしても、以下の要素を検討する必要があります。

インスタンスレベルのオブジェクトの移行:
- ログイン （特にWindows認証ではないSQL Serverログイン）、サーバーロール
- SQL Server Agent ジョブ
- リンクサーバー
- データベースメール の設定
- サーバーレベルのトリガー、監査
ダウンタイムの許容度: 許容できるダウンタイムの長さが、選択すべき移行方法を決定する最大の要因となります。
SQL Serverのバージョン: 移行元と移行先のバージョンが同じか、アップグレード（上位バージョンへの移行）かによって、選択肢が変わります。