目次
はじめに
Kinstaから別のサーバーへ移行したい！
そんなとき、どんな点に注意すればよいでしょうか？
KinstaはWordPressに最適化された高速クラウドサーバーで、使いやすく高性能ですが、その分料金が高めであったり利用できるプラグインに制限があるなどの特徴があります。
例えばKinstaの単一サイト向けプラン（例：Single 35k）は、月額 $35（税別・USD） で、WordPress 1インストール／ストレージ20GBといった構成です。（※2026年2月12日時点）
国内レンタルサーバーでは月額1,000円程度で複数サイト・容量数百GBといったプランも一般的です。
こうした理由から、よりコストを抑えたい、自由にプラグインを使いたいといった理由で他サーバーへの移行を検討する方も少なくありません。
一方で、Kinsta固有の環境から抜け出す際には注意点も多数あります。
適切な準備と手順を踏めば、移行作業によるサイトのダウンタイムやデータ消失などのリスクを最小限に抑えることができます。
本記事では、Kinstaサーバーから他社サーバーへWordPressサイトを移管する際のポイントを、専門家の視点でやさしく解説します。
【移行前の準備】データのバックアップとスケジュール
まずは現在のサイトデータのバックアップを取得することが最優先です。
Kinstaでは標準で毎日の自動バックアップが提供されていますが、これは主にKinsta内での復元用です。
他サーバーへ移行するには、自分でサイトのファイル一式とデータベースを取得する必要があります。
注意したいのは、Kinstaではバックアップ系や移行系のプラグインが制限されている点です。
例えば「All-in-One WP Migration」のようなサイト丸ごとエクスポート用プラグインはインストール自体がブロックされてしまいます。
そのため、一般的なプラグインに頼った簡単移行ができず、代替手段を考える必要があります。
バックアップ取得の方法
それではKinstaサーバーのデータのバックアップを取る方法をいくつかご紹介します。
【方法１】MyKinstaからのダウンロードバックアップ
Kinstaの管理画面(MyKinsta)では、サイトデータ全体をZIPアーカイブで週に1回ダウンロード可能です。
このZIPにはサイトの全ファイル(publicディレクトリ内)とデータベースのSQLダンプが含まれています。
MyKinstaの「バックアップ」→「ダウンロード」から「バックアップを作成」を実行し、しばらく待つとダウンロードリンクが発行されます。
この方法ならプラグイン不要で完全なサイトデータを取得できるため、安全かつ確実です。
※ダウンロードバックアップは作成後 48時間のみダウンロード可能 です。
※ZIPにはWordPressの「ファイル＋DB」のみが含まれ、MyKinstaのリダイレクト設定やカスタムNginxルール等は含まれません。移行前にMyKinsta側の設定（リダイレクト、IP制限、PHP設定など）を別途メモしておきましょう。
【方法２】移行プラグイン（DuplicatorやMigrate Guru）の活用
Kinstaではバックアップ系プラグインは制限していますが、Kinsta公式ドキュメントでは、（主にKinstaへ移行する場合の手段として）移行プラグインの Duplicator（無料版） や Migrate Guru が案内されています。
一方で、All‑in‑One WP Migration はKinsta環境ではインストールがブロックされ、Duplicator Pro は禁止プラグインに含まれます。
Kinstaから他社サーバーへ移行する場合も同様の移行ツールを使えますが、「Kinstaの無料移行」は基本的にKinstaへ乗り換える場合の提供範囲である点に注意しましょう。
Duplicatorはサイトをパッケージ化し、インストーラとセットでエクスポートできるプラグインです。
Migrate Guruは外部のサーバー経由でデータを転送してくれるプラグインで、大容量サイトも直接新サーバーへコピーできます。
ただし、プラグインの操作に不慣れな場合やサイトが大きい場合はエラーの可能性もあるため注意しましょう。
【方法３】手動バックアップ（SFTP/SSH + phpMyAdmin/WP-CLI）
プラグインに頼らず手作業で取得する方法です。
MyKinstaからSFTP情報を確認し、FTPクライアントで接続してwp-contentフォルダを含むサイトファイル一式をダウンロードします。
また、MyKinstaの「データベース」画面からphpMyAdminを開き、エクスポート機能でデータベースのSQLファイルを取得します。
KinstaはSSHやWP-CLIも利用可能なため、慣れている方はコマンドラインでwp db exportしたり、rsyncで直接ファイルを転送する方法もあります。
手動であれば細かく制御できますが、漏れがないよう注意が必要です。
上記いずれの方法でも構いませんが、重要なのはサイトの完全なバックアップを確保してから移行作業を進めることです。
取得したデータはローカルPCなど安全な場所に保管し、移行完了までKinsta上のサイトも削除せず残しておきましょう。
Kinstaで解約手続きを行うと、サイトの本番/ステージング環境は削除され、データは復元できません。
初回30日以内は解約が即時反映される一方、30日経過後は請求期間末まで利用でき、期末に解約となります。
移行完了とバックアップ保全を確認するまでは、解約操作をしないようにしてください。
※MyKinstaのDNS（KinstaDNS）でDNS管理している場合、解約によりDNSレコード（DNS Zone含む）も削除されるため、先に別のDNSサービスへ移管してから解約してください。
移行計画とダウンタイム対策
バックアップと並行して、移行のスケジュールと手順を計画しましょう。
ポイントはサイトのダウンタイムをいかに短くできるかです。
一般に、サーバー移行では以下のような流れになります。
| ステップ | 移行前に確認・準備すること |
|---|---|
| 新サーバーの契約・準備 | 移行先サーバーのプラン契約。WordPressが動作するPHP・MySQL環境を用意（バージョン互換性に注意）。ドメインを新サーバー側に追加設定し、SSL証明書を発行可能なら取得しておく。 |
| データ移行（ファイル） | 取得したバックアップのファイル一式を新サーバーへアップロード。フォルダ構成（wp-content等）を既存のWordPressディレクトリに上書きする形で配置。 |
| データ移行（DB） | 新サーバーで空のデータベースを作成し、バックアップSQLをインポート。wp-config.phpの接続設定を新DB用に書き換え（ホスト名・DB名・ユーザー名/パスワード）。必要に応じて文字エンコードやテーブル接頭辞も確認。 |
| サイト動作テスト | 新環境上でサイトが正しく表示・動作するか確認。Hostsファイルの書き換えや一時URLを利用して、ドメインの切替前に新サーバー上のサイトをプレビューする（後述）。 |
| DNS切り替え | ドメインのDNS設定で、Aレコード等をKinsta⇒新サーバーのIPに変更。TTL値を事前に短く設定しておくと伝播が速くなる。切替実行はアクセスの少ない深夜などを推奨。 |
| 移行後のチェック | 新サーバーにアクセスが来るようになったら、サイト全体を再度チェック。デザイン崩れやリンク切れ、フォーム動作などを確認し、問題があれば修正。Kinsta特有の設定を解除（MUプラグインの削除等）。新環境でのバックアップ設定やキャッシュ設定も忘れずに。 |
上記のように整理し、段取り良く進めることが大切です。
特に「DNS切り替え」のタイミングでサイト停止が必要になるかが心配かもしれません。
しかし、方法次第では移行中もサイトを停止せず稼働させておくことが可能です。
「DNS切り替え」のポイント
DNS切り替えのポイントとして、以下の対策を検討してください。
コンテンツ更新の凍結
移行作業を行う前後の時間帯は、サイトの更新やコメント投稿などデータの変更を控えるようにします。
例えばブログサイトなら移行当日は記事投稿を休み、コメント欄も一時的にクローズするかメンテナンスモードを有効にします。
特にWooCommerceなど注文データを扱うサイトでは、移行中に注文が入るとデータ不整合が起きる恐れがあります。
できればサイトを一時メンテナンスモードにして読み取り専用状態にしておくと安全です。
どうしても常時更新が発生するサイトの場合、Kinsta側でデータを取得した後、新サーバーでサイトをテストし、本番切替直前にもう一度最新のDBをエクスポート・インポートする「差分同期」を行う方法もあります（高度な手順になりますので慎重に）。
Hostsファイルで事前テスト
DNSを切り替える前に、新サーバー上でサイトが正常動作するか事前に確認しておきます。
方法の一つは、ご自身のPCのhostsファイルを編集し、ドメイン名が新サーバーのIPアドレスを指すよう一時設定する方法です。
こうすると、自分のPCからはまだDNS未変更でも新サーバー上のサイトを閲覧できます。
デザイン表示やリンク、ログイン動作、プラグインの挙動など一通りテストし、不具合がないかチェックしましょう。
Kinstaでも同様のサイトプレビューツールが提供されており、切替前に両環境のサイトを比較検証することを推奨しています。
DNSのTTL短縮とオフピーク実施
ドメインのDNSレコードのTTL(Time To Live)を事前に短く設定しておくと、切替後の伝播が速やかに完了します。
可能であれば移行前日にTTLを数分〜数十分程度に設定しておき、移行当日は深夜や早朝などアクセスの少ない時間にDNSを書き換えるとよいでしょう。
DNS変更は数分〜数時間で反映されることも多い一方、キャッシュ状況やDNS事業者によっては 最大48〜72時間程度かかる 場合もあります。
TTL短縮は有効ですが、すべての環境で想定通りに短縮できるとは限らないため、切替後もしばらく旧環境を残しつつ監視しましょう。
この間はサイト更新を避け、旧サーバーにも新サーバーにも同じコンテンツがある状態を維持しておきます。
幸い通常のDNS伝播は近年それほど時間がかからず、数時間以内で完了するケースが多いです。
メールサービスの確認
DNS切替に関連してメールの設定にも注意が必要です。
Kinsta自体はメールホスティングを提供していないため、多くの場合、独自ドメインのメールは他社のメールサービス（GmailやMicrosoft 365など）や別サーバーで運用しているでしょう。
DNSではメール配信先を示すMXレコードがWebサイト用のAレコードとは別に管理されています。
したがってメールサーバーがウェブとは別であれば、通常ウェブの引っ越しでMXレコードを変更する必要はありません。
DNS切替時も既存のMXレコードはそのまま維持し、メールが影響を受けないようにします。
万一、旧サーバーでメールも利用していた場合（Kinsta以外の共用サーバー等から移行するケース）、新サーバーに合わせたMXレコードの変更やメールデータの移行が別途必要になりますのでご注意ください。
以上の準備をしっかり行うことで、「サイトが長時間停止してしまうのでは」「移行中にデータが欠落するのでは」といった不安をかなり解消できるはずです。
新サーバーへのデータ移行の作業と注意点
バックアップが取得でき、計画が整ったら、いよいよ新しいサーバーへデータを移す作業です。
ここではファイルとデータベースの移行、および移行後の設定調整について順に説明します。
ファイルのアップロード
新サーバー側にまだWordPressをインストールしていない場合は、あらかじめ空のWordPress環境をセットアップしておくとスムーズです（インストーラーで新規セットアップしておき、後から中身を上書きする方法でもOKです）。
移行元と移行先でWordPressのバージョンが大きく異ならないよう注意しましょう。
可能ならKinsta上で使っていたWPコアのバージョンに合わせておくか、新サーバーで最新版にしておき、後でDB更新処理を走らせても構いません。
次に、取得済みのサイトファイル一式を新サーバーへアップロードします。
KinstaからダウンロードしたZIPを使う場合、一度ローカルで解凍し、wp-contentフォルダやwp-config.php、その他必要なファイルを取り出します。
一般的なWordPress移行では、wp-content配下（プラグイン、テーマ、アップロード）のコピーと、ルート直下のwp-config.phpや.htaccessの調整が主な作業です。wp-config.phpは後述のデータベース設定で書き換えるので、ひとまずそのままアップロードして構いません。
FTP/SFTPクライアントで新サーバーに接続し、既存のwp-contentをバックアップしてから、Kinstaから持ってきたwp-contentで上書きします。
余分なプラグインやテーマが混在しないよう整理しつつアップロードしましょう。
時間短縮のコツとして、圧縮ファイルのまま新サーバーに送信し、サーバー側で解凍できる場合はその方法が高速です（ただし共有レンタルサーバーではSSH解凍が使えないこともあります）。
アップロード後、パーミッション（ファイルの属性）が適切かも確認します。一般にはファイルは644、フォルダは755が推奨ですが、新サーバーのガイドに従ってください。
データベースの移行
次にデータベース（DB）の移行です。
新サーバーのコントロールパネル（またはphpMyAdmin等）でWordPress用の空のデータベースを1つ作成し、データベース名・ユーザー名・パスワード・ホスト名を把握します。
多くのレンタルサーバーではホスト名はlocalhostですが、提供会社によっては別のホスト名になることもあります。
KinstaからエクスポートしたSQLファイルを、新サーバーのDBにインポートします。
方法は、新サーバー側のphpMyAdminで「インポート」を使うか、SSHが使える場合はmysqlコマンドやWP-CLIのwp db importなどで実行できます。
インポート時に文字コード/照合順序エラーが出る場合は、まず移行先のMySQL/MariaDBが utf8mb4（および該当のcollation）に対応しているか確認します。
WordPressは可能な場合 utf8mb4 を利用するため、安易に SET NAMES utf8; に変更すると、絵文字など4バイト文字が欠損する可能性があります。
移行先DBのアップグレード、またはSQL内の照合順序の変換など、原因に応じた対処を推奨します。
データベースのインポートが成功したら、新DBに合わせてwp-config.phpの設定を書き換えます。
具体的には、DB_NAME（データベース名）、DB_USER（ユーザー名）、DB_PASSWORD、DB_HOSTを新サーバーの情報に変更します。
Kinstaの環境で使われていたこれらの値（およびテーブル接頭辞$table_prefix）から、新環境のものへ確実に置き換えてください。
もしKinstaでは環境変数経由で設定していた場合も、新サーバーでは直接wp-config.phpに記述する形に直します。
新環境でのサイト表示確認
ファイルとDBの移行が完了し、新サーバー上でWordPressサイトが動く準備が整ったら、実際にサイトが表示されるか確認します。
まだDNSは切り替えていない段階なので、前述のHostsファイル方法や新サーバー提供の一時URLでアクセスします。
トップページが正しく表示され、管理画面にもログインできるかを確かめましょう。
ログイン確認
Kinstaから移行したばかりでは、ドメインが同一の場合ログインセッションは無効になることがあります。
その際は新サーバーのwp-login.phpから再ログインしてください。
ログインできない場合、wp-config.phpに一時的にdefine('WP_HOME','新サイトURL'); define('WP_SITEURL','新サイトURL');を追加してURLを固定する方法もあります（移行後に要削除）。
パーマリンク設定
新サーバーがApache環境の場合、.htaccessの設定が必要です。
KinstaはNginxベースのため.htaccessは参照されませんが、WordPressの管理画面からパーマリンク設定を保存した際に.htaccessが生成されているケースもあります。
念のため、新環境で管理画面＞パーマリンク設定を開き、何も変更せずに「変更を保存」ボタンを押してみてください。
正常に保存できれば.htaccessが適切に配置され、記事ページなどへのURLアクセスも動作するはずです。
404エラーになる場合は、.htaccessがないか内容がおかしい可能性があるので、WordPress公式ドキュメント記載の初期設定を記述します。
SSLの動作
新サーバーでSSL証明書を設定済みであれば、https://～でサイト表示できるか確認します。
ブラウザで証明書エラーが出る場合、証明書のインストールミスや混在コンテンツの問題が考えられます。
Kinstaでは（現行仕様として）Cloudflare統合により無料SSL証明書が自動で発行されます（ワイルドカード対応）。
以前はLet’s Encryptの案内もありましたが、Kinsta側ではLet’s Encrypt SSLはサポートされない旨が案内されています。
移行先では、移行先サーバーの方式（無料SSL／有料証明書／Cloudflare経由など）に合わせてSSLを再設定しましょう。
内部リンク・画像の確認
サイト内のリンク切れや画像表示崩れがないかチェックします。
ドメイン名が変わらない移行であれば、通常データベース内のURLを書き換える必要はありません。
ただし、メディアファイルのパスにKinsta特有の一時URL（例えば◯◯.kinsta.cloud/wp-content/...）が混ざっていた場合や、別ドメインに変更する場合は、検索置換ツールでデータベース内URLを一括置換する作業が必要です。
WordPressアドレスが変わるケースでは、シリアライズデータに注意しながらWP-CLIのsearch-replaceコマンドやプラグイン（Better Search Replace等）を使って正しいURLに更新しましょう。
ここまでで、新サーバー上でサイトが問題なく動作していれば、いよいよDNSの切り替え（本番サイトの切り替え）に移ります。
DNS切り替えと移行後の運用チェック
新旧両環境のサイトを比較し、新環境が本番運用可能と判断できたら、ドメインのDNSレコードを新サーバー向けに変更します。
具体的には、ドメイン管理画面にてAレコードやCNAMEレコードをKinstaの情報から新サーバーのIPアドレス（またはホスト名）に書き換えます。
先にTTLを短く設定していれば、変更後数分～数十分程度で多くのユーザーが新サイトへ誘導され始めます。
DNS切替後しばらくは、世界中のDNSサーバーが新しい情報を取得するまで、訪問者が旧サーバーに行く場合と新サーバーに行く場合が混在します。
この期間中も旧Kinsta側のサイトはそのまま稼働させておき、可能なら「移行中のお知らせ」など出して更新不可の旨を示しておくと親切です。
アクセスログなどで新サーバーへの流入が安定して増え、旧サーバーへのアクセスが減ってきたのを確認したら、移行はほぼ完了です。
念のため切替後24～48時間程度はKinsta側のサイトや契約を残しておくことをお勧めします。
全てのアクセスが新サーバーに来るようになり、問題がなければKinstaのサイトデータを削除し契約を解約します（繰り返しになりますが、解約するとKinsta側のバックアップも含めデータが消えるため、タイミングには注意してください）。
以上のチェックを終えれば、Kinstaから他サーバーへの移行作業は完了です。
まとめ
Kinstaサーバーから他のサーバーへ移行する際の注意点について解説しました。
ポイントを整理すると、「確実なバックアップ取得」「新旧環境の違いを把握して適切に対処」「DNS切替の工夫でダウンタイム最小化」「移行後の入念なチェック」が重要です。
Kinstaは高速で便利なホスティングですが、その分ロックインも強めなので、他のサーバーに移管するには少し手間がかかります。
しかし、事前に計画を立てて準備を進めれば、サイトを止めずに円滑に引っ越しすることも十分可能です。
初めてのサーバー移行は不安も多いかもしれませんが、本記事の内容を参考に一つ一つ対応すれば、きっと大きなトラブルなく完了できるでしょう。
万一「やっぱり自分で移行するのは心配…」と感じた場合は、専門のサポートを利用することも検討してみてください。
私たち株式会社リヒトスでもサーバー移管代行サービスを提供しております。
プロの手に任せることで、安全確実に移行を完了できますので、お気軽にご相談ください。
サイト移行後も安心して運用を続けられるよう、ぜひ力になれればと思います。
