WordPressのサーバー引っ越し手順｜DB移行と無停止切替

サーバーの契約更新が近い、サイトが重い、セキュリティが不安。そんな理由でWordPressのサーバー引っ越しを検討しているものの、「データベースの移行で失敗してサイトが真っ白になったらどうしよう」と手が止まっていませんか。

この記事では、WordPressサイトを別のサーバーへ引っ越す手順を、ファイルとデータベースの両方を含めて順番に解説します。プラグインを使う方法と手動で移す方法の使い分け、そして本番を止めずに切り替えるための事前確認のやり方まで書いています。

自社サイトを自分たちで管理している中小企業の広報担当・情シス担当の方に向けた記事です。読み終わる頃には、自社の構成なら「どちらの方法で・どんな順番で・どこを確認しながら」進めればいいかが判断できる状態を目指します。なお、WordPressをこれから立ち上げる段階の方は、先にWordPress初期設定の正しい順番と必須10項目を読むほうが近道です。

Contents / 目次

1. サーバー引っ越しで最初に決める3つのこと
2. データベース移行まで含めた引っ越しの全手順
3. 引っ越しで実際に起きる失敗と、その防ぎ方
4. AIをどこまで使えるか。引っ越し作業での現実的な線引き
5. 移行がうまくいったサイトに起きる変化
6. 自力でやるか、任せるか。判断の分かれ目
7. まずは棚卸しから始めてみてください

サーバー引っ越しで最初に決める3つのこと

WordPressのサーバー引っ越しは、作業を始める前に3つのことを決めた時点で、ほぼ勝負がついています。移行方法の選択、切替日の設定、そしてロールバック（元に戻す）条件です。手を動かす前にここを固めると、途中で迷わなくなります。

結論から言うと、多くの中小企業サイトは「プラグイン移行」で足ります。ただし後述する条件に当てはまる場合だけ、手動移行を選んでください。

プラグイン移行と手動移行のどちらを選ぶか

判断軸はシンプルです。サイトの容量と、構成の複雑さの2つで決まります。

比較項目	プラグイン移行	手動移行（FTP＋phpMyAdmin）
向いているサイト	数百MB程度までの一般的な企業サイト・ブログ	数GB級、サブディレクトリに複数サイト、独自の設定が多いサイト
必要な知識	管理画面の操作ができればOK	FTP・データベース・設定ファイル編集の基礎知識
詰まりやすい点	容量上限、インポート途中のタイムアウト	URL置換、wp-config.phpの書き換え、権限設定
トラブル時の原因特定	ブラックボックスになりやすい	どの工程で失敗したか切り分けやすい

作業時間は、サイトの容量・回線速度・トラブルの有無で大きく変わります。事前に「何時間で終わる」と見積もるより、途中で止まっても慌てない日程を選ぶほうが確実です。

プラグイン移行は「サイト全体をまとめて1つのファイルに固めて、新サーバーで展開する」やり方です。移行系プラグインはWordPress公式プラグインディレクトリの「migration」検索結果から探せます。無料版で扱えるファイルサイズの条件はプラグインごとに異なり、改定されることもあります。使う前に各プラグインの公式配布ページで最新の条件を確認し、あわせて自社サイトの容量も把握しておいてください。

容量の確認方法。サーバーの管理画面（ファイルマネージャー）でWordPressを設置したフォルダのサイズを見るか、FTPソフトで接続してwp-contentフォルダの容量を確認します。画像が多いサイトはここが一気に膨らみます。

切替日は「金曜の夜」ではなく平日の午前に置く

DNS切替は、平日の午前中に実施するのが現場では一番安全です。理由は単純で、問題が起きたときにサーバー会社のサポートが動いている時間だからです。

「業務に影響が出ないように金曜の夜や休日にやろう」と考える方は多いのですが、これは逆効果になりがちです。トラブルが起きた土曜の朝に、サポートも制作会社もつかまらず、月曜まで放置。そういう事故を何度か見てきました。

アクセスが多い時間帯を避けたいなら、平日の朝9時〜10時あたりが落としどころです。BtoBサイトなら昼前後よりアクセスが少ないことが多く、かつサポートが稼働しています。

旧サーバーはしばらく契約を残しておく

移行が終わっても旧サーバーの解約はすぐにしないでください。新旧の契約を一定期間重ねておきます。

DNSの切り替えは、世界中のネットワークに行き渡るまで時間がかかります。実際にどれくらいかかるかはレコードの設定や経路によって変わるため、契約しているドメイン管理会社・サーバー会社の公式案内で目安を確認し、その期間を踏まえて解約日を決めてください。この間、訪問者によっては旧サーバーを見ている人がいます。旧サーバーを消してしまうと、その人たちにはサイトが見えません。

加えて、移行後に「あのファイルが移ってなかった」と気づくことがよくあります。旧サーバーが生きていれば取りに行けますが、解約後だと取り返しがつきません。

データベース移行まで含めた引っ越しの全手順

ここからが記事の本題です。手動移行の手順をステップごとに書いていきます。プラグイン移行を選ぶ方も、ステップ1（事前準備）とステップ6以降（hosts確認・DNS切替・最終確認）は共通なので、そこだけ読んでも役に立ちます。

サーバー会社の管理画面はメニュー名やボタンの位置が変わることがあります。この記事では「何をするか」を書いているので、画面上の正確な名称や場所は、使っているサーバー会社の公式マニュアルを併せて確認してください。

ステップ1。移行前の棚卸しとバックアップ

最初にやるのは、今のサーバーに何が置かれているかの棚卸しです。ここを飛ばすと、後で「これも動いてたのか」という発見が必ず出てきます。

確認しておくリストはこちらです。

• PHPのバージョン：旧サーバーと新サーバーで揃えます。旧が古い場合、新サーバーで新しいPHPにするとプラグインが動かなくなることがあります
• MySQL／MariaDBのバージョン：大きく離れているとインポート時にエラーが出ます
• WordPress以外のファイル：WordPressのフォルダ外に置いた独自PHP、PDF、旧サイトのHTMLなど。意外とここが漏れます
• メールアカウント：そのサーバーで会社メールも受けている場合、移行はサイトだけの話ではなくなります
• cron（定期実行）の設定：サーバー側で設定した自動実行があれば新サーバーにも作り直します
• SSL証明書の種類：無料SSLか有料か。新サーバーで同等のものを用意できるか確認します

棚卸しが終わったら、バックアップを2種類とります。ファイル一式（FTPで全ダウンロード）と、データベース（phpMyAdminからSQLファイルとしてエクスポート）です。

隠しファイルに注意。.htaccess はドット始まりの隠しファイルなので、FTPソフトの設定で「隠しファイルを表示」にしないとダウンロードされません。パーマリンクやリダイレクトの設定が入っている大事なファイルです。

ステップ2。新サーバーでドメインとデータベースを用意する

新サーバーの契約が済んだら、DNSを切り替える前に受け入れ側を作っておきます。この段階ではまだ本番のドメインは新サーバーを向いていないので、いくら触っても現行サイトに影響はありません。

1. 新サーバーの管理画面で、本番ドメインを追加する（この時点では「まだ切り替わっていないドメイン」として登録できます）
2. MySQLデータベースを新規作成する。データベース名・ユーザー名・パスワード・ホスト名の4点をメモしておく
3. PHPのバージョンを、棚卸しで確認した値に合わせる
4. SSL証明書を発行する（ドメインがまだ旧サーバーを向いていると発行できない場合があるため、その時はDNS切替後に回します）

ここでメモした4点が、後のステップ4で必要になります。パスワードは推測されにくいものにして、メモ帳ではなくパスワード管理ツールに入れてください。

ステップ3。ファイルとデータベースを新サーバーへ運ぶ

ファイルはFTPソフトでアップロード、データベースはphpMyAdminでインポートします。

ファイル側の注意点は、アップロード先のフォルダを間違えないことです。新サーバーでドメインを追加すると、そのドメイン用の公開フォルダ（public_html や htdocs のような名前）が作られます。その中に、旧サーバーからダウンロードしたWordPressのファイル一式を、フォルダ構造を保ったまま置きます。

データベース側は、エクスポートしたSQLファイルを新サーバーのphpMyAdminから読み込みます。ここでよく起きるのが「ファイルサイズが大きすぎてアップロードできない」問題です。

この場合の対処法を挙げます。

• 圧縮してインポート：エクスポート時に圧縮形式を選ぶとファイルサイズを小さくできます。どの圧縮形式でエクスポート・インポートできるかは環境によって変わるので、phpMyAdmin公式ドキュメントのインポート・エクスポート解説で対応形式を確認してください
• サーバー側のツールを使う：SSH接続が使えるサーバーなら、コマンドでインポートするほうが確実です。容量制限やタイムアウトの影響を受けにくくなります

ステップ4。wp-config.phpを新しい接続情報に書き換える

wp-config.php は、WordPressがデータベースに接続するための設定ファイルです。ここを書き換えないと、新サーバーではサイトが表示されません。「データベース接続確立エラー」と出る原因の大半がこれです。

書き換えるのは次の4か所です。ステップ2でメモした値に置き換えてください。

<?php
// wp-config.php の該当箇所を書き換えます
// ステップ2で控えた新サーバーの情報に差し替えてください

define( 'DB_NAME', 'ここに新しいデータベース名' );      // ［新サーバーで作成したDB名］
define( 'DB_USER', 'ここに新しいユーザー名' );          // ［DBユーザー名］
define( 'DB_PASSWORD', 'ここに新しいパスワード' );      // ［DBパスワード］
define( 'DB_HOST', 'localhost' );                     // ［サーバーによって mysql◯◯.xxx.jp のような値になる］

// 補足：DB_HOST はサーバー会社によって指定値が異なります。
// 「localhost」で動かない場合は、契約サーバーのDB情報画面に記載のホスト名を使ってください。

wp-config.php を編集するときは、必ず編集前のファイルを別名で保存してから作業してください。文字コードはUTF-8（BOMなし）を維持します。Windowsのメモ帳で保存するとBOMが付いて画面上部に余白や警告が出ることがあるので、VS Codeなどのテキストエディタを使うのが安全です。

ステップ5。データベース内のURLを新しい状態に整える

同じドメインのまま引っ越す場合、URL置換は基本的に不要です。置換が必要になるのは、ドメインを変える場合か、httpからhttpsに切り替えるタイミングを兼ねる場合です。

ここで大事な注意点があります。データベース内のURLは、単純な文字列置換をすると壊れることがあります。WordPressはテーマやプラグインの設定などをシリアライズした文字列としてデータベースに保存しており、シリアライズ形式は文字列の長さを含む構造になっています（PHPマニュアルのserialize）。長さの情報だけが古いまま中身が変わると、読み出し時に整合が取れなくなります。

だから、SQLの単純なREPLACE文で一括置換するのは避けてください。使うのは次のどちらかです。

• WP-CLI（コマンド）：SSHが使えるサーバーなら最も確実です
• 置換用プラグイン：コマンドが使えない環境では、シリアライズ対応をうたった置換プラグインを使います。実行前に必ずDBバックアップを取ります

WP-CLIを使う場合のコマンド例は次のとおりです。オプションの正確な仕様と対象テーブルの指定方法は、実行前に必ずWP-CLI公式の search-replace ドキュメントで確認してください。特に、WordPress標準以外のテーブルも対象にするかどうか、対象URLの表記ゆれ（www有無、httpとhttps）をどう扱うかは、自社の環境に合わせて指定が変わります。

# 前提：SSHで新サーバーに接続し、WordPressのインストールフォルダに移動していること
# 前提：WP-CLI が使えること（wp --info でバージョンが表示されれば利用可能）

# まずは書き換えずに確認する用途のオプション（--dry-run）を付けて実行する
# ※オプションの挙動と対象範囲は上記の公式ドキュメントで確認してから使うこと
wp search-replace 'http://old-example.com' 'https://new-example.com' --dry-run

# 出力された件数と対象テーブルを見て問題なければ、--dry-run を外して実行
wp search-replace 'http://old-example.com' 'https://new-example.com'

# ［old-example.com / new-example.com は自社の実際のドメインに変更してください］
# www有無・http/https の表記ゆれがある場合は、それぞれの表記について実行が必要になります
# WordPress標準以外のテーブルを使っている場合は、対象テーブルの指定も公式ドキュメントで確認してください

httpsへの統一やリダイレクト設定を同時にやる場合は、.htaccessでhttpをhttpsへ301リダイレクトする設定も合わせて確認しておくと、切替後の手戻りが減ります。

ステップ6。hostsファイルで新サーバーだけを先に確認する

移行作業でいちばん重要なのがこのステップです。hostsファイルを使えば、DNSを切り替える前に、自分のパソコンだけを新サーバーに向けて表示確認ができます。訪問者には旧サーバーが見えたまま、自分だけ新サーバーをチェックできる状態です。

ひとことで言うと、引っ越し先の家に自分だけ先に入って、電気と水道が出るか確かめてから住所変更届を出す、というイメージです。

やり方はこうです。

1. 新サーバーの管理画面で、サーバーのIPアドレスを調べる
2. パソコンのhostsファイルを管理者権限で開く（Macは /etc/hosts、Windowsは C:\Windows\System32\drivers\etc\hosts）
3. 末尾に「IPアドレス（半角スペース）ドメイン名」の行を追記して保存する
4. ブラウザのキャッシュを消すか、シークレットウィンドウでサイトにアクセスする
5. 確認が終わったら、追記した行を削除して元に戻す（消し忘れると、切替後もずっと同じIPを見続けてしまいます）

追記する内容の例です。

# hosts ファイルに追記する行（例）
# 前提：管理者権限で編集する（Macは sudo、Windowsは管理者としてメモ帳を起動）

203.0.113.10  example.com
203.0.113.10  www.example.com

# ［203.0.113.10］は新サーバーのIPアドレスに置き換えてください
# ［example.com］は自社のドメインに置き換えてください
# 確認が終わったらこの2行は必ず削除する

この状態でチェックするリストを置いておきます。ここを丁寧にやるほど、切替当日が静かになります。

• トップページの表示：デザイン崩れ、画像抜けがないか
• 下層ページ：会社概要・サービス・記事詳細を数ページ開く（パーマリンクが効いているかの確認）
• 管理画面ログイン：wp-adminに入れるか。入れない場合はDB接続かURL設定を疑う
• 問い合わせフォーム：実際に送信して、自社に届くか・自動返信が飛ぶかを確認
• SSL：鍵マークが出るか。「保護されていない通信」が出るなら混在コンテンツを疑う
• プラグイン：特に決済・予約・会員系は動作確認を厚めに
• 検索・カテゴリ一覧：アーカイブページが真っ白になっていないか

ステップ7。DNSを切り替えて最終確認をする

hostsでの確認が全部通ったら、DNSを切り替えます。ドメインを管理している会社の画面で、ネームサーバーを新サーバーのものに変更するのが基本です。

切替後にやることを挙げます。

1. hostsファイルの追記行を削除して、本当のDNSで新サーバーが見えているか確認する
2. スマホの回線（Wi-Fiを切ってモバイル通信）でもサイトを開いて、別ネットワークからも見えるか確認する
3. Google Search Consoleでサイトマップを再送信し、数日後にクロールエラーが増えていないか確認する

Search Consoleをまだ登録していない場合は、Search Console登録手順と所有権確認のやり方を先に済ませておくと、移行後の異常に早く気づけます。

引っ越しで実際に起きる失敗と、その防ぎ方

ここでは、現場で繰り返し見てきた失敗を挙げます。どれも「知っていれば防げた」ものばかりです。

失敗1。会社メールが止まって、問い合わせが消える

いちばん被害が大きいのがこれです。サイトのことばかり考えていて、同じサーバーで受けていた会社のメールアカウントを忘れる。

ネームサーバーを新サーバーのものに変えると、そのドメインのDNSレコードを管理する場所ごと新サーバー側に移ります。メールの宛先を決めるMXレコードも新サーバー側の設定に従うことになるため、メールの受信先が変わる可能性があります。

実際にどうなるかは新旧サーバーの設定次第です。切替前に必ずJPNICのMXレコード解説で仕組みを押さえたうえで、契約先サーバー会社の公式マニュアルでメールの扱いを確認してください。

新サーバーにメールアカウントを作っていなければ、その日から届いたメールは行き先を失うおそれがあります。取引先からの発注メールが受け取れない、という事故になります。

防ぎ方を挙げます。

• 事前に同じアドレスを作る：DNS切替の前に、新サーバー側で同じメールアドレスを全部作っておきます
• メールをサーバーから分離する：Google WorkspaceやMicrosoft 365などの外部サービスにメールを移し、サーバー移行の影響を受けない構成にします。こうしておくと、次回以降の引っ越しがぐっと楽になります

移行後にフォームのメールが届かなくなるケースも定番です。原因はサーバーのメール送信仕様の違いにあることが多く、WordPressでメールが届かない原因とSMTP設定で解説している方法で送信経路を明示すると安定します。

失敗2。.htaccessを忘れて、下層ページが全部404になる

「トップページは出るのに、会社概要をクリックすると404 Not Found」。これは.htaccessの移行漏れか、パーマリンク設定が反映されていないケースです。

起きる理由はこうです。WordPressの「/company/」のようなきれいなURLは、Apache環境では.htaccessに書かれたリライトの記述で成立しています。この仕組みと、パーマリンク設定を保存したときの.htaccessの扱いについてはWordPress公式の.htaccess解説にまとまっています。

.htaccessは隠しファイルなのでFTPでダウンロードし忘れやすく、新サーバーに置かれないまま切り替わると、トップ以外が見つからなくなります。

Apache環境での直し方は、WordPress管理画面のパーマリンク設定を開いて、何も変更せずに保存ボタンを押すことです。この操作でパーマリンク用の設定が書き出し直されます。書き出しの条件（.htaccessに書き込み権限があること、対象となる記述の範囲）は、上記のWordPress公式の.htaccess解説に記載があるので、実行前に一度目を通してください。パーマリンク構造そのものの考え方はWordPress公式のパーマリンク解説にまとまっています。

それでも直らない場合は、書き込み権限がないか、サーバーが.htaccessを読まない設定になっている可能性があります。なお、Nginxなど.htaccessを使わないサーバーではこの方法は効きません。その場合はサーバー側のリライト設定が必要になるので、サーバー会社の公式マニュアルを確認してください。

失敗3。画像だけが表示されない

ページは出るのに画像だけリンク切れ。これはURL置換の漏れか、ファイルの転送漏れ、あるいはパーミッション（権限）の問題です。

切り分け方はこうです。表示されない画像を右クリックして画像URLをコピーし、ブラウザで直接開いてみます。出てきた結果で原因が分かれます。

• 旧ドメインのURLが出てくる：データベースの置換漏れです
• 新ドメインなのに404：ファイルが転送されていません
• 403が出る：パーミッション（権限）の問題です

FTPでの大量転送は、途中で通信が切れて一部だけ落ちることがよくあります。wp-content/uploads のフォルダは特に容量が大きいので、転送後にファイル数を新旧で比べる習慣をつけると安心です。

失敗4。旧サーバーを消してしまい、戻せなくなる

「移行できたから」と当日に旧サーバーを解約してしまうパターンです。前述のとおりDNSの浸透には時間がかかるうえ、移行漏れは数日経ってから見つかることが多いです。

もうひとつ怖いのが、移行後に旧サーバー側のWordPressを触ってしまい、記事や注文データが二重に存在する状態です。旧サーバーを見ている人が問い合わせを送ると、旧サーバー側のDBに保存されて誰も気づきません。

防ぎ方として、切替が完了したら旧サーバー側のWordPressをメンテナンスモードにするか、旧サーバーの.htaccessで新サーバーへリダイレクトする設定を入れておく方法があります。ただしIP指定のリダイレクトは設定を誤るとループするので、不安なら旧サーバー側を「アクセス不可」にするだけでも十分です。

失敗5。セキュリティプラグインに自分がブロックされる

移行作業中、短時間に大量のログイン試行やファイル操作をすると、セキュリティプラグインが「攻撃だ」と判断して自分のIPをブロックすることがあります。

作業前にセキュリティ系プラグインを一時的に無効化しておき、移行完了後に有効化し直すのが定石です。無効化したプラグイン名は必ずメモしておいてください。戻し忘れて何か月も無防備、という状態が実際によく起きます。移行後の守りを固めるところまで含めて、WordPress乗っ取り対策と二段階認証の手順もセットで確認しておくのがおすすめです。

AIをどこまで使えるか。引っ越し作業での現実的な線引き

結論から言うと、サーバー引っ越しにおけるAIの使いどころは「作業の代行」ではなく「エラーの読み解き」と「チェックリストの作成」です。AIにサーバーの管理画面を操作してもらう、という発想は現時点では現実的ではありません。

AIに任せると効くのはエラーメッセージの解読

移行中に出るエラーは、英語で意味が分かりにくいものが大半です。ここはAIが強い領域です。

使い方はシンプルで、エラー文をそのまま貼って状況を添えるだけです。

WordPressをサーバー移行中に次のエラーが出ました。
原因の候補を、確認しやすい順に並べて教えてください。

【エラー文】
（ここにエラーメッセージをそのまま貼る）

【状況】
・旧サーバー：［サーバー名］／PHP［バージョン］
・新サーバー：［サーバー名］／PHP［バージョン］
・ドメイン変更：［あり／なし］
・どの作業中に出たか：［DBインポート中／サイト表示時 など］

# これは出発点のたたき台です。返ってきた候補に対して
# 「1つ目を確認する具体的な手順を教えて」と対話で掘り下げてください。

ここで人がやるべきことは、AIの回答をそのまま実行しないことです。返ってきた候補のうち「壊す可能性のない確認作業」から先に試します。データベースを直接書き換える提案が出てきたら、必ずバックアップを取ってからにしてください。

AIに任せてはいけないのは、本番環境の破壊的な操作

AIが提示するSQL文やコマンドを、意味を理解せず本番のデータベースに貼り付けるのは危険です。特にDELETE、DROP、UPDATE を含むものは、一度実行すると元に戻せません。

判断基準は「このコマンドを実行して失敗したとき、自力で戻せるか」です。戻せないなら実行しない。これだけで大事故のほとんどを避けられます。

AI活用の現実的な使い方。自社サイトの構成（サーバー・プラグイン一覧・フォーム・メール環境）をAIに伝えて、移行チェックリストを作らせるのは有効です。抜け漏れの発見に役立ちます。ただし最終的な実行判断は人が持ってください。

移行がうまくいったサイトに起きる変化

サーバー移行の効果は、体感よりも数字に出ます。特に表示速度は、測れば分かります。

移行前後で必ず測っておきたいのが、Googleが公開している指標です。Google検索セントラルのCore Web Vitalsの解説によると、ページの読み込み・応答性・視覚的安定性の3つがユーザー体験の指標として扱われています。サーバーのスペックは、このうち特に読み込みの速さに直結します。

移行前にPageSpeed Insightsでスコアを記録しておき、移行後に同じページを測る。この比較があるだけで、社内で「引っ越してよかったのか」を説明できます。測り方はCore Web Vitals改善と表示速度を自分で測る手順にまとめています。

速度以外に効いてくる3つの変化

表示速度以外にも、移行で改善しやすいポイントがあります。

• 管理画面の軽さ：記事を書く担当者の作業効率に直結します。保存や画面遷移の待ち時間が短くなると、更新作業のストレスが減ります
• アクセス集中への耐性：プレスリリースやテレビ放映でアクセスが跳ねたときに落ちるかどうか。せっかくの機会を取りこぼさなくなります
• セキュリティの土台：古いPHPのままだと、既知の脆弱性が放置された状態になります。サポート中のPHPバージョンで動かせること自体が守りになります

脆弱性対策の重要性については、IPA（情報処理推進機構）の安全なウェブサイトの作り方でも、ソフトウェアを最新に保つことが基本対策として示されています。サーバー移行は、この「土台を新しくする」機会でもあります。

成果を数字で残すために移行前にやること

移行の効果を後から説明できるようにするには、移行前の状態を記録しておく必要があります。作業当日は慌ただしいので、前日までに済ませてください。

1. 主要5ページのPageSpeed Insightsスコア（モバイル・PC両方）をスクリーンショットで保存
2. Search Consoleの「ページのインデックス登録」の数値を記録
3. アクセス解析の直近1か月の平均ページ表示速度を記録

この3つがあれば、移行後1か月の時点で「何がどう変わったか」を社内に報告できます。

自力でやるか、任せるか。判断の分かれ目

正直に言うと、WordPressのサーバー引っ越しは「やってみたらすぐ終わった」ケースと「何日もかかって結局戻した」ケースの差が激しい作業です。ここでは、その分かれ目になる条件を率直に書きます。

自力でやって問題ないケース

次の条件がそろっているなら、この記事の手順で進めて問題ありません。

• サイトが数百MB以内：プラグイン移行が使える容量に収まっている
• ドメインが変わらない：URL置換の複雑さが一気に減ります
• メールは外部サービス：Google Workspaceなどを使っていて、サーバー付属のメールアカウントを使っていない
• 会員機能・決済がない：一般的な会社案内サイト、ブログ、採用サイトなど
• 数時間止まっても業務影響がない：万一のときに落ち着いて対処できる

外注を検討したほうがいいケース

逆に、次のどれかに当てはまるなら、外部に任せるほうが結果的に安く済むことが多いです。

• ECサイト・予約サイト：移行中の注文や予約が消えると、金銭的な損害と信用の問題になります
• 会社メールを同じサーバーで受けている：切り替えの段取りが一段複雑になります
• サブディレクトリに複数サイトがある：1つの引っ越しが複数サイトに影響します
• 誰も構成を把握していない：前任者が辞めた、制作会社と連絡がつかない、という状態
• マルウェア感染の疑いがある：そのまま移すと感染ごと引っ越すことになります

見落としがちなコスト

費用の話でよく抜けるのが、移行作業そのもの以外にかかるコストです。

ひとつは、旧サーバーと新サーバーの二重契約期間の費用です。前述のとおり一定期間は契約を重ねるので、その分の月額が発生します。金額はプランと契約形態で変わるので、契約中のサーバー会社の料金表で確認してください。ここをケチって旧サーバーを消すと、戻せなくなるリスクのほうが大きくなります。

もうひとつは、社内の人件費です。担当者が何日も悩みながら作業すると、その時間だけで外注費を上回ることがあります。作業そのものより、トラブル時の調査時間が読めないのが厄介なところです。

「制作会社に頼んだのに、その後サーバーの管理情報を教えてもらえない」という相談を受けることがあります。移行を依頼する場合は、契約前に「サーバー・ドメイン・データベースの管理情報を自社で保有できるか」を確認してください。ここが自社にないと、次回の引っ越しで同じ苦労を繰り返します。

まずは棚卸しから始めてみてください

今日すぐできる最初の一歩は、FTPソフトで自社サーバーに接続して、WordPressのフォルダ外に何が置かれているかを見ることです。5分で終わりますが、ここに移行の落とし穴が集中しています。

移行と合わせてサイト自体を作り替えたい場合は、リニューアル要件定義をAIで整理する5ステップも参考にしてください。

ここまで読んで「自社の構成だと自力は厳しそうだ」と感じた方や、そもそも今のサーバーが適切なのか判断がつかない方は、一度状況を聞かせてください。コレットラボのAI業務システム化支援では、サイトの構成整理から移行後の運用の内製化まで、社内でどこまでやるかを一緒に決めるところから伴走しています。AI業務システム化の詳細はこちらから、現状の整理だけでもお気軽にご相談ください。