[AWS] Bitnami WordPressからLightsail提供WordPressへ移行する手順

PHPの脆弱性対応をきっかけに、Lightsail上のBitnami WordPressから、Lightsailが提供するWordPressイメージへ移行しました。目的は、今後のPHP更新をOSのパッケージ管理に寄せることです。

旧環境ではOSの自動更新が動いていましたが、実際に使っていたPHPは /opt/bitnami/php 配下にあり、APTの管理対象ではありませんでした。そこで、新しいサーバーにWordPressのDBとファイルを移し、PHPなどの実行環境は新サーバー側のものを使う方法を取りました。

以下は2026年10月に実施した作業を、1サイト分の手順として整理したものです。サイト名、ドメイン、IPアドレス、インスタンス名は例示に置き換えています。

移行の概要と前提
1. 旧環境の構成と容量を確認する
2. 旧サイトの書き込みを止める
3. DB・ファイル・設定をバックアップする
4. 復旧用スナップショットを取得する
5. 新しいLightsail提供WordPressを作成・更新する
6. 旧インスタンスから新インスタンスへバックアップを転送する
1. 再現しやすい転送例：手元のPCを経由する
2. 新インスタンスで検証・展開する
7. WordPressのファイルと設定を移す
8. DBをインポートし、URLと絶対パスを確認する
9. HTTPSと証明書の自動更新を移行する
10. AIOSのログインIP制限も確認する
11. 固定IPを移す前に動作確認する
12. 固定IPを付け替えて公開する
13. 旧環境を整理し、今後の更新方法を確認する

移行の概要と前提

流れは「旧サイトの書き込み停止 → バックアップ → 新環境へ復元 → 動作確認 → 固定IPの付け替え」です。旧環境のスナップショットから新サーバーを作るとBitnami構成も戻るので、移行先は新しいWordPressイメージから作成します。

項目	旧環境	新環境
イメージ	WordPress packaged by Bitnami	WordPress（Blueprint provider: Lightsail）
PHPの管理	`/opt/bitnami/php`	DebianのAPTパッケージ
Webサーバー	Apache + PHP-FPM	Apache + mod_php
WordPress配置	`/opt/bitnami/wordpress`	`/var/www/html`
サービス操作	`ctlscript.sh`	`systemctl`

今回は単一サイト構成、同じドメインを継続利用する前提です。マルチサイト、外部DB、外部ストレージ、独自の配置を使っている場合は対象を調整してください。コマンドは各サーバーのBashで実行します。エラーが出たら次へ進まず、その時点で原因を確認します。

新環境のPHPは作業時点で 8.2.35-1~deb12u1、Web実行側も8.2.35でした。この番号を将来の更新目標に固定せず、作業時点のセキュリティ情報と利用OSの修正済みパッケージ版を確認します。

1. 旧環境の構成と容量を確認する

まず、実際に使われているPHPとWordPressの配置を確認します。

command -v php
/opt/bitnami/php/bin/php -v
dpkg-query -S /opt/bitnami/php/bin/php
sudo /opt/bitnami/ctlscript.sh status
sudo ls -ld /opt/bitnami/wordpress /opt/bitnami/wordpress/wp-content
df -h /
sudo du -shL /opt/bitnami/wordpress

dpkg-query で「no path found」となる場合、そのPHP実行ファイルはdpkgに登録されていません。apt upgrade でOSを更新していても、そのPHPまで更新されたとは判断できません。

OSの自動更新履歴は、次のログで確認できます。

sudo less /var/log/unattended-upgrades/unattended-upgrades.log
sudo less /var/log/apt/history.log

「自動更新が動いたか」に加えて「どのパッケージが更新されたか」を見ます。

2. 旧サイトの書き込みを止める

DBとファイルの時点をそろえるため、ApacheとPHP-FPMを停止します。今回はこちらを停止した状態から作業しました。

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /opt/bitnami/ctlscript.sh stop php-fpm
sudo /opt/bitnami/ctlscript.sh status

DBはバックアップに必要なので、停止中ならMariaDBだけ起動します。

sudo /opt/bitnami/ctlscript.sh start mariadb

OSのcronやsystemd timerでWordPressを直接実行している場合、そのジョブも停止します。旧環境の証明書更新ジョブも控えを取り、一時停止しました。証明書更新後の処理でApacheが再起動されるのを避けるためです。

3. DB・ファイル・設定をバックアップする

WordPressのDBには投稿、ユーザー、通常のプラグイン設定などが入っています。画像・テーマ・プラグインは主に wp-content です。これに加え、ルートの独自ファイル、設定、証明書も保存します。

バックアップ先はWeb公開ディレクトリの外に作ります。以下は今回のBitnami用WP-CLIラッパーが利用できる場合の例です。このラッパーは sudo で呼び出し、内部では daemon ユーザーとして動いていました。

set -euo pipefail
umask 077
OLD_WP=/opt/bitnami/wordpress
BACKUP=$(mktemp -d "$HOME/wp-migration.XXXXXX")
wpold() {
  sudo /opt/bitnami/wp-cli/bin/wp --path="$OLD_WP" \
    --skip-plugins --skip-themes "$@"
}

wpold config get table_prefix --type=variable > "$BACKUP/table-prefix.txt"
wpold core version > "$BACKUP/wordpress-version.txt"
/opt/bitnami/php/bin/php -m > "$BACKUP/php-modules.txt"

wpold db export - --single-transaction --quick --hex-blob --add-drop-table \
  | gzip > "$BACKUP/wordpress.sql.gz"

sudo tar --dereference -czf - -C "$OLD_WP" . \
  > "$BACKUP/wordpress-files.tar.gz"

OLD_CONFIG=$(wpold config path)
sudo cat "$OLD_CONFIG" > "$BACKUP/wp-config.reference.php"
sudo tar -czf - -C /opt/bitnami/apache conf \
  > "$BACKUP/apache-conf.reference.tar.gz"

# 既存の証明書を引き継ぐ場合。配置は事前に確認する。
sudo tar -czf - -C /opt/bitnami letsencrypt \
  > "$BACKUP/letsencrypt.reference.tar.gz"

gzip -t "$BACKUP/wordpress.sql.gz"
tar -tzf "$BACKUP/wordpress-files.tar.gz" > "$BACKUP/files.list.txt"
tar -tzf "$BACKUP/apache-conf.reference.tar.gz" > /dev/null
tar -tzf "$BACKUP/letsencrypt.reference.tar.gz" > /dev/null

(
  cd "$BACKUP"
  sha256sum wordpress.sql.gz wordpress-files.tar.gz \
    wp-config.reference.php apache-conf.reference.tar.gz \
    letsencrypt.reference.tar.gz table-prefix.txt \
    wordpress-version.txt php-modules.txt files.list.txt > SHA256SUMS
  sha256sum -c SHA256SUMS
  touch BACKUP_COMPLETE
)
printf 'Backup: %s\n' "$BACKUP"

Bitnamiでは wp-content が別ディレクトリへのシンボリックリンクになっていることがあります。今回は tar --dereference でリンク先の実体を保存しました。実行前にリンク先を確認し、不要な別領域まで取り込まないようにします。

DBパスワードをコマンドに直接書く必要はありません。DBダンプ、wp-config、証明書の秘密鍵を含むので、バックアップの公開や権限の緩和はしません。

4. 復旧用スナップショットを取得する

DBの書き出し後にMariaDBも停止します。

sudo /opt/bitnami/ctlscript.sh stop mariadb
sudo /opt/bitnami/ctlscript.sh status

Lightsailコンソールで旧インスタンスを開き、「スナップショット」から手動スナップショットを作成します。状態が利用可能になるまで確認します。

手順3のバックアップは、この時点では旧インスタンスのディスク内だけにあります。mktemp が作った /home/bitnami/wp-migration.XXXXXX が保存先で、実際の末尾はコマンドの出力を控えます。スナップショット作成だけでは、新しいWordPress環境へファイルは転送されません。

次の手順で新インスタンスを作成してから、手順6でバックアップディレクトリ一式を転送します。転送・復元・動作確認が終わるまで、旧インスタンスは削除しません。

スナップショットは旧環境の復旧用、SQLとファイルは新環境への移行用です。Bitnamiのフルバックアップ手順を使って新環境へ丸ごと復元すると、旧ランタイムも戻ってしまうため、今回は必要なデータを取り出して移します。

5. 新しいLightsail提供WordPressを作成・更新する

作成画面でWordPressを選び、Blueprint providerがLightsailであることを確認します。今回は1GB RAM・2vCPU・40GBの構成を使用しました。

まだ本番の固定IPは移しません。作業中は新環境の80/443を閉じるか、作業者だけに制限します。IPv6側のルールも確認し、SSH接続は維持します。

新環境へ admin ユーザーで接続し、構成と更新対象を確認します。

whoami
cat /etc/os-release
command -v php
command -v wp
wp --path=/var/www/html config path
systemctl list-units --type=service --all 'apache2*' 'php*-fpm*' 'mariadb*'

sudo systemctl stop apache2
sudo apt update
sudo apt-get -s upgrade
sudo apt upgrade
php -v
php -m
dpkg-query -W php8.2-cli libapache2-mod-php8.2

最後のパッケージ名は今回のPHP 8.2・mod_php構成の例です。FPM構成なら、実際に使われているFPMパッケージも確認します。APT更新中にサービスが起動する場合があるため、作業中のネットワーク制限は維持します。

旧環境と php -m を比較し、必要な拡張はAPT側のパッケージで追加します。旧PHPの実行ファイルや .so はコピーしません。CLIだけでなく、公開前にWeb実行側のPHPも確認します。AWSのWordPress更新手順

6. 旧インスタンスから新インスタンスへバックアップを転送する

今回の実作業では、CloudShellから旧・新インスタンスの両方へSSH接続し、旧側のバックアップをtarストリームとして新側へ渡しました。CloudShellは中継点であり、バックアップ一式をCloudShellのホーム領域へ保存してはいません。

旧インスタンス
  /home/bitnami/wp-migration.XXXXXX/
    wordpress.sql.gz、wordpress-files.tar.gz、設定、SHA256SUMS など
        ↓ SSHで読み出し
CloudShell（ストリームを中継。バックアップ一式は保存しない）
        ↓ SSHで転送
新インスタンス
  /home/admin/wp-migration-source/
        ↓ SHA256検証 → ファイル展開・DBインポート
  /var/www/html と新環境のWordPress用DB

図のディレクトリ名は記事用の例です。実作業ではLightsailの一時SSH認証情報を取得する作業用ヘルパーを使い、ホスト鍵の検証と転送後のSHA256照合を行いました。作業時だけ追加したSSH許可は、移行後に除去しています。

再現しやすい転送例：手元のPCを経由する

専用ヘルパーを使わずに行うなら、手元のPCへ一度取得してから新インスタンスへ送る方法が分かりやすいです。以下は旧・新サーバーではなく、手元のPCのBashで実行します。PCにもバックアップ分の空き容量が必要です。

旧・新インスタンスへ鍵認証でSSH接続できることを前提にしています。ファイアウォールでは作業端末からのSSHを許可し、初回接続時は接続先のホスト鍵を確認します。下記のIPは説明用の予約アドレス、鍵とバックアップのパスも例です。自分の環境に置き換えます。

set -euo pipefail
umask 077
OLD_IP=203.0.113.10
NEW_IP=203.0.113.20
OLD_KEY="$HOME/.ssh/old-lightsail.pem"
NEW_KEY="$HOME/.ssh/new-lightsail.pem"
OLD_BACKUP=/home/bitnami/wp-migration.XXXXXX
LOCAL_BACKUP=$(mktemp -d "$HOME/wp-migration-copy.XXXXXX")

# 1. 旧インスタンス → 手元のPC
scp -i "$OLD_KEY" -r \
  "bitnami@$OLD_IP:$OLD_BACKUP/." "$LOCAL_BACKUP/"

# 2. 手元で転送内容を検証
test -f "$LOCAL_BACKUP/BACKUP_COMPLETE"
( cd "$LOCAL_BACKUP"; sha256sum -c SHA256SUMS )

# 3. 新インスタンスに非公開の受け取り先を作る
# 同名ディレクトリが既にある場合は停止し、内容を確認する
ssh -i "$NEW_KEY" "admin@$NEW_IP" \
  'umask 077; mkdir -m 700 /home/admin/wp-migration-source'

# 4. 手元のPC → 新インスタンス
scp -i "$NEW_KEY" -r \
  "$LOCAL_BACKUP/." "admin@$NEW_IP:/home/admin/wp-migration-source/"

# 5. 新インスタンス側でもSHA256を検証
ssh -i "$NEW_KEY" "admin@$NEW_IP" \
  'cd /home/admin/wp-migration-source && test -f BACKUP_COMPLETE && sha256sum -c SHA256SUMS'

sha256sum がない作業端末では同等のSHA256検証ツールを使います。SSH秘密鍵は手元に置いたままで、旧・新サーバー同士へコピーする必要はありません。SFTPクライアントで同じ2段階の転送をしても構いませんが、チェックサムと付属ファイルも含めてディレクトリ全体を移します。

新インスタンスで検証・展開する

以下は新規作成した移行先専用のVMで行います。既存の別サイトには実行しません。BACKUP は転送先へ置き換えてください。

set -euo pipefail
umask 077
NEW_WP=/var/www/html
BACKUP=/home/admin/wp-migration-source

test -f "$BACKUP/BACKUP_COMPLETE"
( cd "$BACKUP"; sha256sum -c SHA256SUMS )

NEW_BACKUP=$(mktemp -d "$HOME/wp-before-restore.XXXXXX")
NEW_CONFIG=$(wp --path="$NEW_WP" config path)
sudo cat "$NEW_CONFIG" > "$NEW_BACKUP/wp-config.php"
wp --path="$NEW_WP" db export "$NEW_BACKUP/initial-database.sql"

STAGE=$(mktemp -d "$HOME/wp-restore-stage.XXXXXX")
tar --no-same-owner -xzf "$BACKUP/wordpress-files.tar.gz" -C "$STAGE"
gzip -dc "$BACKUP/wordpress.sql.gz" > "$STAGE/wordpress.sql"

圧縮ファイル、展開済みファイル、復元先を同じディスクに置くため、途中でも df -h / を確認します。容量に余裕がない場合は、外部の保管先や転送方法を先に調整します。

7. WordPressのファイルと設定を移す

今回は移行と同時にWordPressの大きなバージョン変更をせず、新環境のコアを旧サイトと同じ版にそろえました。WordPressコアは公式配布物を使い、チェックサムを検証します。旧版自体が未修正なら、その版へ戻す手順は採用せず、修正版で互換性を確認します。

wp --path="$NEW_WP" core version
cat "$BACKUP/wordpress-version.txt"
wp --path="$NEW_WP" core verify-checksums

版をそろえる必要があり、その版を採用してよいと確認できた場合は、新環境で wp core download --version=採用する版 --force --skip-content を実行します。配置先を間違えないよう --path=/var/www/html も付け、改めてチェックサムを確認します。これは新規移行先のコアを公式配布物で置き換える操作です。

wp-content を復元します。以下は新環境の配置が通常のディレクトリの場合です。

test ! -L "$NEW_WP"
test ! -L "$NEW_WP/wp-content"
test -d "$STAGE/wp-content"
sudo mv "$NEW_WP/wp-content" "$NEW_BACKUP/wp-content.before"
sudo mv "$STAGE/wp-content" "$NEW_WP/wp-content"
sudo chown -R admin:www-data "$NEW_WP/wp-content"
sudo find "$NEW_WP/wp-content" -type d -exec chmod 2775 {} +
sudo find "$NEW_WP/wp-content" -type f -exec chmod 0664 {} +

これは今回の admin / www-data 構成に合わせた権限です。他の実行ユーザーなら調整します。WordPressルート全体へ一律に書き込み権限を付ける操作ではありません。

wp-config.phpは新環境のものを使い、DB接続情報を維持します。旧ファイルを上書きせず、次の項目を個別に確認します。

$table_prefix：旧DBの接頭辞と一致させる。
WP_HOME / WP_SITEURL：本番URLに合わせる。サブディレクトリ構成なら両者を区別する。
WP_CONTENT_DIR、キャッシュ、WAF：旧環境の絶対パスを修正する。
SMTPや外部APIの独自定数：設定ファイルにあるものは個別に移す。
SALT：新しい値では既存ログインセッションが失効する。SALTを暗号化に使うプラグインがあれば移行要件を確認する。

今回のwp-config.phpはroot権限で更新する必要があったため、設定変更だけ sudo wp --allow-root を使用しました。

OLD_PREFIX=$(cat "$BACKUP/table-prefix.txt")
[[ "$OLD_PREFIX" =~ ^[A-Za-z0-9_]+$ ]]
sudo wp --allow-root --path="$NEW_WP" config set table_prefix "$OLD_PREFIX" --type=variable
sudo wp --allow-root --path="$NEW_WP" config set DISABLE_WP_CRON true --raw

検証中のメール・外部API連携も、各プラグインの設定や検証用フックで抑止しました。DISABLE_WP_CRON だけでは、それらすべては停止しません。解除する設定を記録しておきます。

.htaccess、robots.txt、独自のルートファイルも内容を確認して移します。object-cache.php、advanced-cache.php、mu-pluginsは旧環境のパスやサービスへの依存を確認し、必要な設定を直します。

8. DBをインポートし、URLと絶対パスを確認する

接続先が新しい移行先専用DBであることを確認してからインポートします。同名テーブルは置き換わります。

wp --path="$NEW_WP" config get DB_NAME
wp --path="$NEW_WP" config get DB_HOST

wp --path="$NEW_WP" db import "$STAGE/wordpress.sql"
wp --path="$NEW_WP" db check
wp --path="$NEW_WP" --skip-plugins --skip-themes core update-db
wp --path="$NEW_WP" --skip-plugins --skip-themes option get home
wp --path="$NEW_WP" --skip-plugins --skip-themes option get siteurl
wp --path="$NEW_WP" --skip-plugins --skip-themes plugin list
wp --path="$NEW_WP" --skip-plugins --skip-themes theme list

同じドメインを使う場合でも、旧DBのhome/siteurlがIPやループバックになっていないか確認します。必要なら、DBの値とwp-configの定数を本番URLへそろえます。以下はルート配置の例です。

DOMAIN=example.com  # 実際のドメインへ置き換える
wp --path="$NEW_WP" --skip-plugins --skip-themes option update home "https://$DOMAIN"
wp --path="$NEW_WP" --skip-plugins --skip-themes option update siteurl "https://$DOMAIN"
sudo wp --allow-root --path="$NEW_WP" config set WP_HOME "https://$DOMAIN"
sudo wp --allow-root --path="$NEW_WP" config set WP_SITEURL "https://$DOMAIN"

DB内に旧絶対パスが残っていた場合は、まずdry-runで置換対象を確認します。

wp --path="$NEW_WP" --skip-plugins --skip-themes search-replace \
  /opt/bitnami/wordpress /var/www/html \
  --all-tables-with-prefix --skip-columns=guid --precise --dry-run

対象を確認後、--dry-run を外して実行します。/bitnami/wordpress のような別表記も必要に応じて確認します。SQLファイルへの単純置換ではシリアライズされた値を壊すことがあるため、WP-CLIのsearch-replaceを使います。

9. HTTPSと証明書の自動更新を移行する

今回は旧環境の有効な証明書と秘密鍵、ACMEアカウントを新環境へ引き継ぎました。証明書はドメインに対するもので、旧VMを削除しても、新環境へ正しく配置されていれば使えます。

行った作業は次のとおりです。

証明書の対象ドメイン・有効期限・秘密鍵との対応を確認する。
証明書とACMEアカウントを、Web公開外の /etc/lego へ配置する。
秘密鍵やアカウント情報をroot専用にする。
新ApacheのVirtualHostへ証明書パスと本番ドメインを設定する。
APT版のlegoを導入し、新しいパスに合わせて更新ジョブを作る。

sudo apt install lego
sudo openssl x509 -in "/etc/lego/certificates/$DOMAIN.crt" \
  -noout -subject -dates -ext subjectAltName
sudo apache2ctl configtest

旧Apacheの設定一式は上書きしません。HTTP-01で更新するため、80番の /.well-known/acme-challenge/ が新環境のWebルートに届くように設定し、そのパスはログイン制限や一律リダイレクトの影響を受けないようにします。

更新処理は /usr/local/sbin/wordpress-renew-certificate にまとめました。次は、既存ACMEアカウントを配置済みの場合の例です。ドメインとメールアドレスは置き換え、スクリプトはroot所有・モード700で保存します。

#!/bin/sh
set -eu
/usr/bin/lego --path /etc/lego \
  --email admin@example.com --domains example.com \
  --http --http.webroot /var/www/html renew --days 30
/usr/sbin/apache2ctl configtest
/bin/systemctl reload apache2

/etc/systemd/system/wordpress-cert-renew.service：

[Unit]
Description=Renew WordPress TLS certificate
After=network-online.target apache2.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/wordpress-renew-certificate

/etc/systemd/system/wordpress-cert-renew.timer：

[Unit]
Description=Check WordPress certificate renewal twice daily

[Timer]
OnCalendar=*-*-* 04,16:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

スケジュールはサーバーのタイムゾーン基準です。本番切り替え後にタイマーを有効化し、更新判定を実行します。

sudo systemctl daemon-reload
sudo systemctl enable --now wordpress-cert-renew.timer
sudo systemctl start wordpress-cert-renew.service
systemctl is-enabled wordpress-cert-renew.timer
systemctl is-active wordpress-cert-renew.timer
systemctl show wordpress-cert-renew.service -p Result -p ExecMainStatus
systemctl list-timers wordpress-cert-renew.timer --no-pager

今回は有効期限に余裕があり、更新判定は成功しましたが、証明書の再発行は強制していません。再発行まで成功したという確認とは分けて記録しています。

10. AIOSのログインIP制限も確認する

All-In-One Security（AIOS）の設定はDBとファイルの復元で引き継ぎました。ただし、今回はPHP-FPMからmod_phpへ変わるため、ファイルのコピーだけで終わらせず、読み込み方法も確認しました。

ホワイトリストの有効状態と許可IPを確認する。
ログインURL変更の設定を確認する。
aios-bootstrap.php とmu-pluginの旧絶対パスを修正する。
mod_phpでは .user.ini が読み込まれないため、Apache側へ必要な設定を移す。

今回のApache側の設定例です。既存の auto_prepend_file がある場合は競合を確認し、利用するAIOSの設定方法に合わせます。

<Directory /var/www/html>
    php_value auto_prepend_file /var/www/html/aios-bootstrap.php
</Directory>

<FilesMatch "^(wp-config\.php|\.user\.ini)$">
    Require all denied
</FilesMatch>

設定テスト後、許可された接続元からログインできることと、許可外からログイン画面が拒否されることを確認します。今回は未許可のループバックから403になることを確認しました。これはログイン画面の検査であり、全APIやログイン済みセッションへの一律IP制限を意味するものではありません。

11. 固定IPを移す前に動作確認する

新環境でApacheの設定テストを行い、一般公開を制限したまま起動します。FPM構成の場合は、先に対応するFPMサービスを起動してください。

sudo apache2ctl configtest
sudo systemctl start apache2
curl --fail --silent --show-error \
  --resolve "$DOMAIN:443:127.0.0.1" "https://$DOMAIN/" -o /dev/null \
  -w 'HTTP=%{http_code} TLS_VERIFY=%{ssl_verify_result}\n'

これは新サーバー上で実行する例です。証明書検証を省略する -k は付けません。管理画面を手元から確認する場合は、作業端末のhostsなどで本番ドメインを新サーバーへ向け、作業者のアクセスだけ許可します。

確認した項目は次のとおりです。

トップページ、記事、固定ページ、パーマリンク。
画像、添付ファイル、サムネイル。
WordPress管理者のログインと権限。
テーマ、プラグイン、キャッシュ、AIOSの動作。
Web実行側のPHPバージョンと必要な拡張。
HTTPからHTTPSへの転送、証明書の検証。
Apache/PHP/DBログ、空き容量。

DBの検査成功だけで復元完了とはせず、記事や画像も実際に開きます。PHP確認用の一時ファイルを作った場合は、確認後に削除します。

12. 固定IPを付け替えて公開する

確認できたら、Lightsailで旧インスタンスの静的IPv4を新インスタンスへ付け替えます。同じ固定IPを使うため、今回はDNSのAレコード変更は不要でした。

新環境のPHP修正・DB復元・HTTPS・動作確認が済んでいることを確認する。
旧環境の書き込みが停止したままであることを確認する。
静的IPv4を新環境へ付け替える。
AAAAレコードやCDNを使っている場合は、その接続先も確認する。
新環境の80/443を公開し、手元のhosts設定を元へ戻す。
検証用のWP-Cron・メール・外部通信抑止を解除する。
新環境の証明書更新タイマーを有効化する。
外部から表示・ログイン・画像アップロードを確認する。

通常のWP-Cronを使っていた場合、今回追加した抑止設定を戻します。OSのcron運用なら、その運用に合わせて再設定します。

sudo wp --allow-root --path="$NEW_WP" config delete DISABLE_WP_CRON

固定IPv4の付け替えだけではIPv6の接続先は変わりません。AAAAレコードを使っている場合は忘れずに確認します。メールや外部APIは、実通知や二重処理が起きないテスト方法で個別に確認します。

13. 旧環境を整理し、今後の更新方法を確認する

公開後の表示、ログイン、画像アップロードを確認してから、旧インスタンスと不要になったスナップショットを削除しました。停止中のLightsailインスタンスや保管中のスナップショットにも料金がかかるため、残すものと消すものを明確にします。

移行用バックアップは検証が終わるまで保持し、その後の保管先・保持期間を決めます。今回は動作確認後、容量整理のため新環境内の移行元アーカイブを削除したサイトもあります。同じVM内のコピーだけではVM消失への備えにならないため、継続運用のバックアップは別途考える必要があります。

以後のPHP更新は、新環境でAPTの更新内容を確認して適用できます。

sudo apt update
apt list --upgradable
sudo apt-get -s upgrade
sudo apt upgrade
php -v
dpkg-query -W php8.2-cli libapache2-mod-php8.2

Web用PHPへの反映に再起動が必要なら、メンテナンス時間にApacheを再起動し、Web側の版とサイトの動作を確認します。自動更新の有無は unattended-upgrades の設定とログで確認します。APT管理になっても、PHPのメジャー更新やOSのサポート期限まで自動で解決するわけではありません。

移行先の構成を確認したうえで、DB・ファイル・証明書・セキュリティ設定を分けて移すのが今回の要点でした。特に、旧絶対パス、PHPの実行方式、証明書更新ジョブは、WordPressのバックアップを戻すだけでは確認が終わらない部分です。