WordPressサーバー移行チェックリスト: ファイルとDBの複写より後に確認すること

2026年8月時点のWordPressの実行環境

新しいサーバーでトップページが正常に開くからといって、WordPressの移行が終わったわけではありません。その状態はたいてい、ファイルとデータベースが新環境でも読めるという最初の確認に近いものです。安全な移行は、移行の直前までに生まれたデータがすべて反映されたか、実際のトラフィックが新環境へ入るか、TLSとメール、Cron、キャッシュ、外部連携が新環境で動くか、問題が起きたときどの時点までどう戻すかを検証して初めて終わります。最後には既存環境の書き込みを止め、バックアップと資格情報、DNS、ファイアウォール、監視まで片づけます。

だからWordPressの移行は、ファイル複写とDBのImportではなく、Preflight、Rehearsal、Cutover、Validation、Decommissionの五段階で管理するほうが安全です。

WordPressの最新版は7.1です。公式のRelease Archiveの7.1 Branchにはまだ7.1だけが載っており、この時点では7.1系の保守リリースが確認できません。^[7]

WordPress Hosting Handbookは、運用環境にPHP 8.4以上を勧めます。PHP 8.5もWordPress 6.9以上で対応すると説明します。PHP 8.2と8.3はPHP ProjectでSecurity Supportの段階であり、8.4と8.5はActive Supportの状態です。^[2]

DBでは文書のあいだの基準を分けなければなりません。WordPress RequirementsのMySQL 8.0以上は広い互換の基準ですが、MySQL 8.0のEOLの日付はすでに2026年4月を過ぎています。^[8]MariaDB 10.6もHosting Handbookに記されたEOLの日付が2026年7月6日です。新しい環境は現在支援中のLTS系を選び、WordPress Coreが対応するという事実を、PluginやCustom Queryまで自動で互換だという意味に読んではいけません。^[2]

WordPress Core

現在の公式の状態: 最新版7.1 / 新しい移行先に当てる基準: 最新版という理由だけで移行と同時に上げない

PHPの公開推奨

現在の公式の状態: 8.3以上 / 新しい移行先に当てる基準: 最低線ではなく現代的な推奨基準

PHPの運用推奨

現在の公式の状態: Hosting Handbookは8.4以上を推奨 / 新しい移行先に当てる基準: 全Plugin・Theme・Custom Codeの検証後に8.4を既定候補とする

PHP Coreの最小

現在の公式の状態: WordPress 7.1はPHP 7.4以上 / 新しい移行先に当てる基準: 実行可能な下限であり、新規運用環境の目標版ではない

PHP 8.5

現在の公式の状態: WordPress Core 7.1が対応し、PHP ProjectのActive Support / 新しい移行先に当てる基準: すべての拡張コードとPHP Extensionの検証を通ったときに選ぶ

DBの公開推奨

現在の公式の状態: MariaDB 10.11以上またはMySQL 8.0以上 / 新しい移行先に当てる基準: DB製品の現在の支援期間まで併せて確認する

DBのLegacy下限

現在の公式の状態: MySQL 5.5.5以上で実行可能 / 新しい移行先に当てる基準: EOLのため新規の対象には使わない

現在のLTS候補

現在の公式の状態: MySQL 8.4、MariaDB 10.11・11.4・11.8 / 新しい移行先に当てる基準: Plugin・Custom Query・文字集合・Collation・SQL Modeのテスト後に決める

HTTPS

現在の公式の状態: WordPress Requirementsの基本条件 / 新しい移行先に当てる基準: 証明書の発行だけでなくRedirect・Proxy Header・Callback URLまで検証

Coreのアップグレードとインフラ移行を一度にしない理由

サーバーとOSの変更、PHP 8.1から8.5への変更、MySQL 8.0から8.4への変更、WordPress 7.0から7.1への変更、PluginとThemeの同時更新を一つのCutoverに束ねる場合を考えます。誤りが出ると、原因がサーバー構成かPHPの互換性かDBの挙動の違いかCoreの変更かPluginの更新かを分けにくくなります。より大きな問題は、一部の更新がDBの構造や保存データを変えた後は、既存環境へトラフィックだけ戻す方式が安全なロールバックにならない点です。

WordPress 7.1のField Guideも、一部の内蔵ライブラリの変更がそれを使うPluginの挙動や見た目に影響するためテストが要ると説明します。WordPress CoreのPHP互換性の表はCoreの範囲の判断であり、導入済みのPluginやTheme、MU Plugin、Custom Codeの互換性まで語るものではありません。^[9]

安全な基本の順序は三つです。既存のWordPress・Plugin・Themeのバージョンを置いて、新しいインフラをまずRehearsalします。インフラの移行を終えてObservation Windowを通過します。CoreとPHP、DBまたはPluginのアップグレードは別の変更として行います。

既存のPHPやDBが新環境で提供されず変更が避けられないなら、これを単純なサーバー移行ではなく、インフラ移行とランタイムのアップグレードが結びついた変更として記します。環境ごとのAcceptance CriteriaとRollback Triggerも別々に分けます。

Bulk Copy → Final Sync → Traffic Cutover

切替は三つの動作に分かれます。Bulk Copyはファイルとuploads、DBを新環境へ最初に複写します。この状態の新環境はRehearsalの対象であり、外部のメールと決済、Webhook、Cronは遮断するかテストモードにします。そのあいだ既存環境では実際の変更が続きます。

次がWrite Freezeです。管理者とフォーム、コメント、REST API、決済のCallback、Cron、Queueの書き込みを統制したうえで、Final Syncによって最終のDBとUploads Delta、その他の可変ファイルを移します。この状態の新環境がCutover Candidateであり、ここでSmoke Testとデータの整合を確認します。

最後がTraffic Cutoverです。DNSやReverse Proxy、Load Balancerを切り替えて新環境が読み書きを受け、既存環境はWrite BlockedかつCron・Queue Disabledの状態に置きます。Observation Windowを通過して初めて既存環境をDecommissionします。

Bulk Copy以降に既存サイトで注文と会員、コメント、ファイルのアップロードが続いていたなら、最初に複写したデータはCutover時点の最新の状態ではありません。Final Syncなしにトラフィックだけ変えると、「接続はできるが最近のデータが消えたサイト」になります。

Master Migration Checklist

以下の五段階がこの記事の本文です。Preflightは何を移すかを確定します。Rehearsalは切替を一度最後まで行い、Cutoverは最新のデータと実トラフィックを一緒に移します。Validationは画面ではなく機能と運用の証跡で承認します。Decommissionは既存サーバーを止めることまで移行作業として扱います。

各段階の表は実際の値を埋めて使う雛形です。項目ごとにOwnerとEvidenceを残して初めて、次の人が同じ判断を繰り返さずに済みます。

1. Preflight — 何を移すかを先に確定する

Preflightの目的はサーバーの情報を集めることにとどまりません。どの状態が複写の対象で、何が外部システムに残り、Cutoverの前後でどの環境が正本かを決める段階です。

Environment Compatibility Matrixは実際の値を埋めて使う雛形です。MATCHは単純な一致、TEST_REQUIREDはRehearsalが必要、BLOCKはCutoverの前に解決すべきことを意味します。既存環境と新環境の値を並べて記し、判定を残します。

WordPress Hosting Handbookはjsonとmysqliを必須のPHP Extensionとして説明します。遠隔の要求とメディア、文字の処理、TLS、圧縮などに要る複数のExtensionは別に勧めます。PHPのバージョンが同じというだけでサーバー環境が同じだと判断できない理由です。^[2]

下記Preflight Checklistの23項目を個別に確認し、完了印とEvidenceを残します。

環境・Plugin・Theme・Custom Codeに続き、書込経路・Uploads・Cache・Cron・Queueを確認します。

Mail・外部連携・DNS・TLS・Proxy・Security Rule・Restore可能性を確認し、正本と切替承認条件を確定します。各項目にEvidence様式を対応付けています。

正本は一文で定めます。時点ごとにどこが正本かを下のように記しておきます。WordPress DBだけが正本と書くと足りません。Uploadsがファイルシステムにあり、決済の結果が外部のPGにあり、メールの状態が送信事業者にあるなら、移行の対象はすでに複数のシステムに散らばっています。

□ Preflight 1 / スコープ文書

インフラ変更・URL変更・Core/PHP/DB更新の範囲を区別

□ Preflight 2 / Environment Matrix

WordPress・PHP・DB VersionとPHP Extensionを記録

□ Preflight 3 / Plugin Inventory

有効・無効Plugin全体、Version、要求PHP、Custom Tableを記録

□ Preflight 4 / Theme Inventory

Parent・Child Theme、Custom Template、ビルド成果物を記録

□ Preflight 5 / MU Plugin・Drop-in一覧

mu-plugins、object-cache.php、advanced-cache.php、その他Drop-inを確認

□ Preflight 6 / Custom Code Register

functions.php、Snippet、別PHP、配備ScriptなどCustom Codeを確認

□ Preflight 7 / Network Map

Multisite、サイト数、Domain Mapping、Subdomain/Subdirectory構造を確認

□ Preflight 8 / Writer Inventory

WooCommerce・予約・会員・コメント・FormなどWrite-heavy機能を分類

□ Preflight 9 / Uploads Inventory

wp-content/uploads、別Upload経路、外部Storage、最近の変更量を測定

□ Preflight 10 / Cache Map

Page Cacheの所在とBypass Routeを確認

□ Preflight 11 / Object Cache Map

Object CacheのPrefix・DB・Drop-in・共有を確認

□ Preflight 12 / CDN Configuration

CDNのOrigin・Cache Rule・Purge経路を確認

□ Preflight 13 / Cron Inventory

WP-CronかSystem Cronか、どのサーバーで何を実行するか確認

□ Preflight 14 / Queue Snapshot

Plugin Queue、Pending・Failed作業、Worker所在を確認

□ Preflight 15 / Mail Flow Map

SMTP・Mail API・発信Domain・認証・返送確認経路を記録

□ Preflight 16 / Integration Register

Form・Webhook・Payment Callback・外部APIのEndpointとSecretを確認

□ Preflight 17 / DNS Export

DNS Record、現在TTL、Proxy、権限保有者を確認

□ Preflight 18 / Certificate Inventory

全HostnameのTLS証明書と更新責任を確認

□ Preflight 19 / Proxy Contract

Reverse Proxyが渡すHost・Scheme・Client IP Headerを確認

□ Preflight 20 / Security Rule Export

Admin・REST・Webhookに影響するWAF・アクセス制御規則を確認

□ Preflight 21 / Restore Evidence

DB・ファイル・設定Backupの存在と実Restore可能性を確認

□ Preflight 22 / Source-of-Truth Table

DB・Uploads・外部取引データのSource of Truthを宣言

□ Preflight 23 / Cutover Runbook

Acceptance Criteria、Rollback Trigger、承認者、連絡経路を確定

Rehearsal中

WordPress DBとUploadsの正本は既存環境です。Cron・Queueは既存環境だけで実行し、外部の決済とメールは実システムを使います。

Write Freeze後のFinal Sync中

DBとUploadsの正本は依然として既存環境ですが、書き込みが止まった状態です。Cron・Queueは停止またはDrainし、受信中のCallbackは別に統制します。

Cutover Candidate

DBとUploadsの正本候補が新環境へ移ります。Cron・Queueはまだ実行を保留し、外部連携はテスト要求のみ許します。

Acceptance通過後

DBとUploadsの正本が新環境になります。Cron・Queueも新環境だけで実行し、新しいEndpointとの整合を確認します。

Observation Window

正本も実行も新環境にあり、外部システムとの照合を続けます。

2. Rehearsal — 実際の切替の前に一度最後まで行う

Rehearsalは新しいサーバーでトップ画面を出すテストではありません。Cutoverと同じ順序で複写とImport、設定、検証を行い、かかる時間と失敗の地点を記す作業です。

運用ドメインがそのまま維持されるなら、テストのためにDB全体のURLを一時ドメインへ変えるより、承認されたテスト機材でHosts Overrideや一時的なProxy Routingを使うほうが不要なDBの変更を減らします。一時的なHostnameを使うなら、検索エンジンの遮断だけでなく、実際のメールと決済、Webhook、Cronが実行されないよう別に止めます。

URLが変わる場合を見ます。WordPressのOptionとWidget、Themeの設定、PluginのデータにはPHPのSerialized Dataが入ります。直列化された文字列には値の長さも一緒に保存されるため、長さの違うURLをRaw SQLの全体のREPLACE()で置き換えるとデータが壊れます。WordPressの公式Migration文書はこれを警告します。WP-CLIのsearch-replaceはSerialized Dataを認識して処理すると説明します。^[1]

安全な基本の手順は、新環境の複製でまずDry Runを行うことです。wp search-replaceに旧アドレスと新アドレスを与え、--skip-columns=guidと--dry-runを付けて変更の対象と件数だけを確認します。結果とDBのBackupを検討したうえでのみ、同じコマンドから--dry-runを外します。PluginがWordPressに登録されていないCustom Tableを使うなら、テーブルをまず確認してから--all-tables-with-prefixの使用を決めます。Multisite全体を対象にするときは--networkが要りますが、これだけでNetworkの構造の検討が終わるわけではありません。WP-CLIの既定の動作は現在のサイトに登録されたテーブルを対象とし、--networkと--all-tables-with-prefixは範囲を広げる選択肢です。^[3]

guidはURLのように見えても変えません。WordPressはこれをPostの持続的な識別子として使い、Domainが変わってもそのまま残すよう公式文書で明示します。guidを変えると、Feed Readerが既存の記事を新しい記事として認識する問題が起きます。^[1]

Dry Runの成功も最終の証跡ではありません。変更の後はメニューとBlock・Widgetの設定、CSSの背景画像、メディアのURL、SEOのMetadata、PluginのCustom TableとRedirectを実際の画面とDBで確認しなければなりません。

StagingまたはTemporary Hostを運用トラフィックから分ける

Pass Criteria: 一般利用者が到達せず、検索の索引と実際の外部Side Effectが遮断される

実際の目標のPHP・DB・Web Serverで実行

Pass Criteria: Fatal ErrorとDeprecatedの急増なくCritical Flowが動く

ファイルの所有者と権限の復元

Pass Criteria: WordPressが必要なディレクトリにだけ書き、過度な全体書き込み権限がない

DBのExport・Importの実施

Pass Criteria: Import Errorがなく、主要なTable・Entityの数が想定の範囲と一致

URL変更のDry Runと適用

Pass Criteria: Serialized Dataが保たれ、guidが変わらない

Permalink・Rewriteの構成

Pass Criteria: 投稿・固定ページ・REST API・Adminの経路が正しく応答

Uploadの生成とサムネイル処理

Pass Criteria: 原本と派生画像が生成され、公開URLから読める

Plugin・Theme・MU Plugin・Custom Codeの実行

Pass Criteria: Critical FlowごとのAcceptance Criteriaを通過

メール・Webhook・決済はテストモードで検証

Pass Criteria: 運用の利用者や実取引にSide Effectがない

Bulk CopyとFinal Syncの所要時間の測定

Pass Criteria: 計画したMaintenance Windowの内側で実施できる

Rollbackのリハーサル

Pass Criteria: Traffic Reversalと既存環境の再有効化が文書どおりに行える

Rollback Triggerの確定

Pass Criteria: 誰がどの証跡でいつ中断するかが明確

3. Cutover — 最新のデータと実トラフィックを一緒に移す

Cutoverは12段階で進めます。Bulk Copyの確認から始まり、Write FreezeとCron・Queueの統制、Final DB SyncとFinal Upload Sync、設定の最終適用、Smoke Testを経てトラフィックを切り替えます。続いてTLSとキャッシュを確認したうえで新環境の書き込みを開きます。

Write Freezeは管理者への告知だけでは終わりません。WordPressの書き込みの経路は/wp-admin/だけにありません。コメントと会員登録、問い合わせ・予約・調査のForm、REST API、admin-ajax.php、決済・配送・CRMのCallback、予約公開とWP-Cron、PluginのQueueと再試行のWorker、外部プログラムのApplication PasswordとAPIの要求がすべて書き込みの経路です。管理画面にMaintenanceの案内を出しても、WebhookとCronが動き続ければFinal DB Syncの後にデータがまた変わります。Write-heavyなサイトでは書き込みの主体をすべて止めるか、止められない書き込みを別の台帳に記して再調整します。

短いWrite Freezeさえ許されないサイトなら、このRunbookの単純なFinal Dumpの方式だけでは足りません。Replicationや変更データの追跡、Callbackの再処理と整合の照合を含む別のOnline Migrationの設計が要ります。

DNSのTTLは完了の時刻を定めてくれません。TTLをあらかじめ下げると、既存のキャッシュが切れた後に新しいRecordをより早く引くようになります。しかしすでに取得したResolverのTTLは残りの時間だけ減り続け、一部のResolverは障害回避のため期限切れのデータを一時的に返すこともあります。したがって「TTLを300秒に下げたから5分後に世界中が新しいサーバーを見る」といった形でCutoverの時刻を約束してはいけません。^[6][10] 切替の後は複数のResolverとネットワークで結果を確認します。要求がどのBackendへ届いたかは、サーバーのログやテスト用のDeployment Markerで見分けます。MarkerにはOrigin IPや内部のHostnameのような機微な情報を入れません。

TLSとProxy、WAFでは七つを見ます。すべての実際のHostnameが証明書に入ったか、EdgeとOriginのあいだのTLSも正常か、HTTPからHTTPSへのRedirectがLoopを作らないか、Reverse Proxyが元のHostとHTTPSのSchemeをWordPressへ正しく渡すか、新しいOrigin IP・Port・Health Checkが反映されたか、WAFがLoginとAdmin、REST API、Webhook、Payment Callbackを誤って塞がないか、既存のOriginへ直接つないで書き込みを作れないかです。

4. Validation — 画面ではなく機能と運用の証跡で承認する

検証は「担当者が見て回ったが大丈夫だった」で終えません。項目ごとのOwnerとPass Criteriaをあらかじめ定めます。そして要求IDとログ、受信の結果のように再び確認できるEvidenceを残します。

WP-CronとSystem Cronは別のものです。WP-Cronは伝統的なSystem Cronのように動き続けるSchedulerではありません。既定の動作ではPage Loadが起きたときに予定の作業があるかを検査します。トラフィックがなければ定めた時刻より遅れて実行されます。^[11] System Cronでwp-cron.phpやWP-CLIを定期的に呼ぶよう構成したサイトでは、Page Loadに基づく呼び出しをDISABLE_WP_CRONで止めることがあります。移行するときは、WordPressの中に予定のEventがそのままあるかと、新しいサーバーのOS Schedulerが実際にWordPressのCronを呼ぶかをそれぞれ確認します。wp cron testはWP-Cron Spawnの動作を検査する道具です。System Cronを使う構成では、OS Schedulerの実行ログと実際のEventの完了の記録まで別に確認します。既存サーバーと新サーバーが同時にCronを実行すると、メールと購読、予約、在庫の同期が重複して処理されます。^[4]

メール関数の成功と受信の成功は違います。WordPressのwp_mail()がtrueを返しても、受信者がメールを受け取ったという意味ではありません。公式の関数の文書も、その値は使われた送信の方式が要求を誤りなく処理したという意味にすぎないと明示します。^[5] メールの検証には六つのEvidenceが要ります。WordPressやPluginが送信の要求を生成したか、SMTP・Mail APIのProviderが要求を受け入れたか、送信ドメインと認証が正常か、実際のTest Mailboxへ届いたか、Spam・Bounce・Blockの有無はどうか、パスワード再設定と注文、Formなどテンプレートごとに確認したかです。PHPのmail()の呼び出しやwp_mail()の返り値だけを見てPassを与えません。

Site Healthがすべて緑でも全体のAcceptanceではありません。Site HealthはWordPressとPlugin、Theme、Server、DB、Filesystem Permissionなどの構成の情報と既知の問題を確認するのに有用です。Uploadの無効化、Loopbackの失敗、古いPHP、HTTP Requestの遮断のような問題も捉えます。^[12]しかし注文の決済と実際のメールの受信、外部のWebhook、Analytics、最新のデータの整合、DNSの切替とロールバックの可否を代わりに検証はしません。したがってSite Healthがすべて緑という事実は、Migration Acceptanceの一項目であって全体の証跡ではありません。

5. Decommission — 既存サーバーを止めることも移行作業である

新環境が正常だと判断した直後に既存サーバーを消してはいけません。逆に既存環境を無期限に生かしておくことも安全ではありません。古いServerとPlugin、Credential、Firewall Ruleが管理されないまま残り、新しい攻撃面と運用の混乱を作るからです。

Observation Windowの長さをすべてのサイトに同じく当てることはできません。少なくとも中核の予約作業の一周期、実際または承認された合成のWrite Flow、メールとWebhook、決済のCallback、キャッシュの失効と再生成、運用時間帯の実トラフィック、BackupとMonitoringの定期実行を実際に観測できる期間でなければなりません。毎月一度実行されるCritical Jobがあるなら、二日間トップページが正常だという理由だけでその作業を検証したとは見なせません。

Observation Windowの運用

終了条件: 未解決のCritical Issueがなく、終了の基準を満たす

既存環境のWrite Block

終了条件: 迂回のDomain・IP・管理経路からも新しいデータが生じない

既存のCron・Queueの停止

終了条件: 外部のSide Effectと重複作業が生じない

既存環境の最終Backup

終了条件: DB・ファイル・設定のRestore可能な複製と識別子を保存

Backup Retentionの確定

終了条件: 法的・契約・運用の方針に合う削除日とOwnerの指定

Credential Rotation

終了条件: 既存サーバーが持っていたDB・SMTP・API・Webhookの秘密情報を必要な範囲で交換

DNS Cleanup

終了条件: Old Record、Temporary Host、検証用Entryの除去

TLS Cleanup

終了条件: 使わないCertificate・Challenge・更新作業の整理

Firewall・Allowlist Cleanup

終了条件: 既存のIP・Port・管理アクセスの許可を除去

Monitoring Cleanup

終了条件: 重複するAlertの除去と、必要なHistorical Dataの保存

Backup・Security Agent Cleanup

終了条件: 不要な費用・権限・重複作業の除去

Shutdown Approval

終了条件: Business・Application・Infrastructure Ownerの承認の記録

Server Termination

終了条件: 終了時刻、資産ID、最終の証跡の記録

事後の文書更新

終了条件: Runbook・Architecture・Credential Owner・Asset Registryの最新化

WordPress-specific Rollback Contract

Rollback Contractは「問題が起きたらDNSを元に戻す」という一文ではありません。WordPressではDBとUploads、Cron、Queue、Form、注文、メール、Callbackが同時に状態を変えるため、どの時点まで単純な復帰が可能かを先に定めなければなりません。

新環境がまだ実際の書き込みを受けていないなら、おおむね既存環境へトラフィックを戻し、Write Blockを解く手順が可能です。この段階がもっとも単純なRollback Windowです。

新環境で書き込みが始まった後は、注文と決済の状態、会員・ログイン・パスワードの変更、コメント・投稿・予約、アップロードしたファイル、Formの送信、Webhookの処理結果、Cron・Queueが作った変更、外部へ送られたメールが新環境に生まれています。この状態でトラフィックだけ既存サーバーへ戻すと、新環境で生じたデータが利用者から消えて見えたり、同じCallbackとQueueが二度処理されたりします。

したがって四つのうち一つが要ります。新しい書き込みを既存環境へ安全に再反映するか、外部の台帳と両方のDBを照合して手作業で調整するか、既存環境へ戻す代わりに新環境でForward Fixを行うか、危険が解けるまで新しい書き込みを再び閉じて制限運用をするかです。どの方法が可能かはCutoverの前に定めます。Rollbackの時点で初めて議論すれば、すでにデータが分かれた後です。

コードと設定、DB、トラフィックにまたがる一般的なRollback Architectureは別の文書が扱います。この記事は、その原則をWordPressのDB・Uploads・Cron・Plugin・外部Callbackの状況に当てはめた実行の契約に集中します。

サイトの種別ごとの追加項目

基本のチェックリストの上に、種別ごとに足す項目があります。六つに分けて見ます。

WordPressの公式Migration文書も、MultisiteはDBの複数の場所にサーバー名と経路があり単一サイトより複雑だと説明します。wp_siteとwp_blogs、サイトごとのOptions、SUBDOMAIN_INSTALLのような設定は別に検討しなければなりません。^[1]

一般のコンテンツサイト

基本チェックリストに足すこと: コメント・会員登録・Formが実際に書き込みを作るかの確認、予約公開とSitemapの更新、最近のUploads Delta

Write-heavyなサイト

基本チェックリストに足すこと: Write Freezeの対象APIの全体、注文・予約・在庫・購読の台帳、Payment CallbackのRetryとIdempotency、Queue Drain、Final Entity Count、Cutover以降の新規Writeの追跡

WooCommerce

基本チェックリストに足すこと: 注文・決済・返金・在庫・クーポン・メール・Webhook・Scheduled Actionをそれぞれ検証し、外部PGの台帳と状態を照合

Membership・LMS

基本チェックリストに足すこと: ログインのSession、権限・受講状態・進度・購読更新・パスワードのメール・Background Jobの検証

Multisite

基本チェックリストに足すこと: wp_site、wp_blogs、各サイトのOptions、Domain Mapping、Network-activated Plugin、Upload Path、Wildcard DNS・TLS、Cookie Domain、Network Adminの検証

MultisiteのURL変更

基本チェックリストに足すこと: WP-CLIの--networkの範囲の確認、各サイトのhome・siteurlとUploadの設定、Network Tableの手作業での確認、Subdomain・Subdirectoryの切替の有無の確認

Observation Log Template

Observation LogにはCredentialと個人データ、決済情報の全体を写しません。必要なら識別できる最小のRequest IDや内部のEvidence IDだけを残します。一行に一つの観測を記し、TimestampとObserver、Test ID、Observedの値、結果、ActionとOwnerも併せて埋めます。

Observation Windowを閉じるときは、少なくとも観測の開始と終了の時刻、観測した中核の流れと予約作業、メールの受信の確認、Webhookと決済の照合の結果、既存環境で検知された書き込みの有無、未解決の事象、ロールバックの成果物の検証の有無、終了の承認者を記します。

Cutover

機能・イベント: Login / 処理したBackend: New / Expected: ログインとSessionの維持 / Evidence: Log ID

Validation

機能・イベント: Upload / 処理したBackend: New / Expected: 原本とサムネイルの生成 / Evidence: Screenshotまたはログ

Validation

機能・イベント: Mail / 処理したBackend: New / Expected: 実際の受信 / Evidence: Provider Message ID

Observation

機能・イベント: Cron・Queue / 処理したBackend: New / Expected: 定時に一度だけ実行 / Evidence: EventまたはJob ID

Observation

機能・イベント: Error Review / 処理したBackend: New / Expected: 基準に対して異常な増加がない / Evidence: Dashboard

移行完了の基準

「新しいサーバーでサイトがよく見える」ということは、Validationの最初の行に近いものです。安全にMigrationが終わったと言うには、六つの問いにすべて答えられなければなりません。最終のデータはどの環境にあるか。既存環境と新環境で同時に書き込みが起きなかったか。利用者と管理者、外部システムの実際の機能が通ったか。メールとCron、Queue、Cache、Webhookが新環境だけで動くか。障害が起きたらどの時点までどう戻すか。既存サーバーとCredentialをいつどの承認で取り除くか、です。

まずこの記事のMaster Migration Checklistを実際のRunbookへ写し、OwnerとEvidenceを埋めます。一般的なロールバックの設計とバックアップ・復元の可否はそれぞれ別の文書が扱い、移行後のWordPressの運用責任の配分も別の運用文書で管理します。