WordPress Multisite の環境移行 (AWS Lightsail/PHP 8.2)

11月 3, 2026AWS,Lightsail,Web製作 & WordPress

Contents

1. はじめに
2. 移行前後の構成
3. 移行の方針と全体の流れ
4. 事前確認(旧環境の棚卸し)
5. 新インスタンスの作成
- 5.1. ファイアウォールの確認
6. 新環境の初期設定
7. データ移行のリハーサル
8. 動作確認
9. 本番切り替え
10. 切り替え後の確認と後片付け
11. まとめ
- 11.1. チェックリスト

はじめに

こんにちは、新川です。このブログは、AWS Lightsail 上の WordPress Multisite で運用しています。

ある日、WordPress のダッシュボードに「PHP の更新が必要です」という警告が出ていました。サイトヘルスで確認すると、PHP は 7.3、OS は Ubuntu 16.04 で、どちらもサポートが終了していました。

折しも PHP の重大な脆弱性が公表された時期で、PHP 7.3 のような古いバージョンには修正版が提供されません。早めに PHP を更新して、脆弱性に対処したいと考えました。

ただ、既存の環境は Bitnami 提供のブループリントで、PHP・Apache・DB が、OS のパッケージとは別にまとめて同梱されています。そのため、OS のパッケージマネージャー(apt)で PHP だけを更新することはできません。OS 自体も古いため、更新を重ねるよりも、インスタンスごと新しくする方が安全だと判断しました。

この記事は、その移行の備忘録です。Lightsail の Bitnami 版 WordPress Multisite を使っている方が参考にできるよう、必要な手順と確認方法を中心に残します。範囲は、PHP 8.2 の新環境へ切り替えるところまでです。PHP 8.3 への更新は、次回の記事にまとめます。

移行前後の構成

旧環境は Bitnami 提供のブループリント、新環境は Lightsail 提供のブループリントです。主な違いは次のとおりです。

項目	移行前	移行後
ブループリント	WordPress Multisite(Bitnami 提供)	WordPress Multisite(Lightsail 提供)
OS	Ubuntu 16.04.7 LTS	Debian 12 (bookworm)
PHP	7.3.14(php-fpm)	8.2.35(Apache モジュール)
データベース	MySQL 8.0.18	MariaDB 10.11
WordPress	6.9.11	7.1.4
スペック	1GB メモリ / 1 vCPU	1GB メモリ / 2 vCPU

WordPress の詳しい構成は、ダッシュボードのツールからサイトヘルスを選択して確認が可能です。

新環境の PHP 8.2.35 は、2026年10月21日に公開された重大な脆弱性(CVE-2026-109618、CVE-2026-109619)の修正版です。PHP 7.3 には、修正版が提供されません。(参考: PHP2Shell の解説)

前提とした構成は次のとおりです。

WordPress Multisite(サブドメイン型)
前段に CloudFront を置き、DNS は Route 53 で管理
Lightsail の静的 IP を使用

移行の方針と全体の流れ

Bitnami 提供のブループリントの WordPress は、PHP だけを単体で更新する手段がありません。AWS の公式回答でも、新しいインスタンスを作ってデータを移す方法が案内されています。また、Bitnami 提供のブループリントは 2026年5月19日以降の更新が止まっており、11月19日以降は新規作成もできなくなります。

そこで、Lightsail 提供の最新ブループリントで新しいインスタンスを作り、データを移す方針にしました。OS と PHP をまとめて新しくでき、旧インスタンスをそのまま残せるため、切り戻しもしやすい方法です。

静的 IP で公開している構成では、切り替えは、静的 IP を旧インスタンスから新インスタンスへ付け替えるだけです。接続先の IP アドレスが変わらないため、DNS の変更は不要です。

全体の流れは次のとおりです。

旧環境の棚卸しとスナップショットの取得
新インスタンスの作成
新環境の初期設定
データ移行のリハーサル(DB と wp-content)
動作確認
本番切り替え(最終同期と静的 IP の付け替え)
切り替え後の確認と後片付け

参考:

事前確認(旧環境の棚卸し)

移行の前に、旧環境の状態を確認します。

WordPress のバージョンと Multisite の設定

cat /opt/bitnami/apps/wordpress/htdocs/wp-includes/version.php | grep wp_version
grep -E "MULTISITE|SUBDOMAIN_INSTALL|DOMAIN_CURRENT_SITE|PATH_CURRENT_SITE" /opt/bitnami/apps/wordpress/htdocs/wp-config.php

サブドメイン型か、サブディレクトリ型かを確認します。各サイトのドメインは DB に保存されているため、移行後も同じドメインを使えば、URL の置換は不要です。

データ量と空き容量

sudo du -sh /opt/bitnami/apps/wordpress/htdocs/wp-content
sudo du -sh /opt/bitnami/mysql/data
df -h /

wp-content と DB の容量を確認します。転送にかかる時間や、新インスタンスのプランを決める目安になります。

DB の照合順序

MySQL から MariaDB へ移すため、テーブルの照合順序を確認します。MySQL 8 の既定の照合順序(utf8mb4_0900_ai_ci など)が含まれていると、MariaDB にそのままでは取り込めない場合があります。

sudo /opt/bitnami/mysql/bin/mysql -u root -p -e "SELECT table_collation, COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','sys','information_schema','performance_schema') GROUP BY table_collation;"

スナップショットの取得

最後に、旧インスタンスのスナップショットを手動で取得します。切り戻しの安全網になります。

新インスタンスの作成

Lightsail コンソールで、次の設定で新しいインスタンスを作成します。

項目	設定
リージョン	旧インスタンスと同じ(静的 IP を付け替えるため、同じリージョンにします)
ブループリント	WordPress Multisite(提供元: Lightsail)
ネットワーク	デュアルスタック
プラン	1GB メモリ / 2 vCPU / 40GB SSD(旧インスタンスと同じ 1GB メモリのプラン)

ブループリントは、Bitnami 提供ではなく、提供元が Lightsail のものを選びます。サブドメイン型の Multisite を移すため、「WordPress」ではなく「WordPress Multisite」を選びます。

プランは、旧インスタンスと同じ 1GB メモリのプランで始めました。足りなければ、あとから上げる想定です。インスタンス名は、あとから変更できないため、分かりやすい名前を付けます。

ファイアウォールの確認

作成直後のファイアウォールを確認します。SSH(22番)を「Lightsail ブラウザ SSH のみ」に限定し、公開に必要なポートだけが開いていることを確認します。SSH を外部に開く必要はありません。

新環境の初期設定

新インスタンスにブラウザ SSH で接続し、次の設定を行います。

環境の確認

php -v
cat /etc/os-release | head -3
mariadb --version
free -m

出力(抜粋):

PHP 8.2.35 (cli) (built: Oct 21 2026 06:29:51) (NTS)
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
mariadb  Ver 15.1 Distrib 10.11.19-MariaDB, for debian-linux-gnu (x86_64)

PHP は 8.2.35、OS は Debian 12、DB は MariaDB 10.11 でした。なお、新インスタンスのメモリは約 1GB で、スワップは 0 です。

セキュリティ更新とスワップの追加

sudo apt update && sudo apt upgrade -y
sudo fallocate -l 1G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -m

PHP の設定(旧環境に合わせる)

標準の php.ini は触らず、追加の設定ファイルを置きます。

sudo tee /etc/php/8.2/apache2/conf.d/99-custom.ini >/dev/null <<'EOF'
memory_limit = 256M
max_execution_time = 120
max_input_time = 300
post_max_size = 40M
upload_max_filesize = 40M
EOF
sudo systemctl restart apache2

画像処理モジュールの追加

旧環境で使っていた Imagick と、intl を追加します。

sudo apt install -y php-imagick php-intl
sudo systemctl restart apache2
php -m | grep -Ei "imagick|intl"

Apache の設定

メモリ 1GB に合わせて、同時プロセス数を抑えます。

sudo tee /etc/apache2/conf-available/99-tuning.conf >/dev/null <<'EOF'
ServerName localhost
<IfModule mpm_prefork_module>
    StartServers            3
    MinSpareServers         2
    MaxSpareServers         5
    MaxRequestWorkers       15
    MaxConnectionsPerChild  500
</IfModule>
EOF
sudo a2enconf 99-tuning
sudo apache2ctl configtest && sudo systemctl restart apache2

旧環境で付けていた X-Frame-Options ヘッダーも、新環境で揃えます。

sudo a2enmod headers
sudo tee /etc/apache2/conf-available/99-headers.conf >/dev/null <<'EOF'
<IfModule mod_headers.c>
    Header always setifempty X-Frame-Options SAMEORIGIN
</IfModule>
EOF
sudo a2enconf 99-headers
sudo apache2ctl configtest && sudo systemctl restart apache2

phpMyAdmin の公開を止める

新環境のドキュメントルートには、phpMyAdmin へのシンボリックリンクがあります。使わない場合は、リンクを削除して、公開を止めます。

sudo rm /var/www/html/phpmyadmin

データ移行のリハーサル

本番の切り替えの前に、DB と wp-content を新環境へ移して、一通り動くことを確認します。新環境はまだ公開されていないため、本番への影響はありません。

SSH 鍵の準備

新環境の SSH は、Lightsail のブラウザ SSH のみ許可しています。そのため、旧環境から新環境へは、鍵認証でプライベート IP 経由で接続します。

以降のコマンドの <NEW_PRIVATE_IP> は新環境のプライベート IP、<PUBLIC_KEY> は公開鍵 1 行、<FILE_NAME> はコピーするファイル名に置き換えてください。

旧環境で、鍵を作ります。

ssh-keygen -t ed25519 -f ~/.ssh/migrate_key -N "" -C "migrate-old-to-new"
cat ~/.ssh/migrate_key.pub

新環境で、表示された公開鍵を登録します。

echo '<PUBLIC_KEY>' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

旧環境から接続を確認します。初回は yes と入力します。

ssh -i ~/.ssh/migrate_key admin@<NEW_PRIVATE_IP> hostname

新環境のホスト名が表示されれば成功です。

DB の移行

旧環境で、ダンプを取り、新環境へ送ります。

sudo /opt/bitnami/mysql/bin/mysqldump -u root -p --single-transaction --quick --default-character-set=utf8mb4 --hex-blob bitnami_wordpress | gzip > ~/wp_rehearsal.sql.gz
scp -i ~/.ssh/migrate_key ~/wp_rehearsal.sql.gz admin@<NEW_PRIVATE_IP>:~/

新環境で、DB を作り直して取り込みます。

sudo mariadb -e 'DROP DATABASE `wordpress-db`; CREATE DATABASE `wordpress-db` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;'
zcat ~/wp_rehearsal.sql.gz | sudo mariadb wordpress-db

Multisite のサイトが登録されていることを確認します。

sudo mariadb wordpress-db -e "SELECT blog_id, domain, path FROM wp_blogs;"

各サイトのドメインが、本番のドメインで表示されれば成功です。

wp-config.php の修正

新環境の wp-config.php は、/var/www/wp-config.php にあります。新環境のものを土台にして、次の 3 点を変更します。

DOMAIN_CURRENT_SITE を、本番のドメイン(example.com)に変更する
WP_HOME と WP_SITEURL の 2 行を削除する
CloudFront などのリバースプロキシ経由の HTTPS 判定を追記する

sudo cp -p /var/www/wp-config.php ~/wp-config.php.orig
cat > /tmp/cf_block.php <<'EOF'

// リバースプロキシ(CloudFront など)経由の HTTPS 判定
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
} elseif (isset($_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO']) && $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}
EOF
sudo sed -i \
  -e "s/[0-9.]*\.nip\.io/example.com/" \
  -e "/define( 'WP_HOME'/d" \
  -e "/define( 'WP_SITEURL'/d" \
  -e "/define( 'WP_AUTO_UPDATE_CORE'/r /tmp/cf_block.php" \
  /var/www/wp-config.php
rm /tmp/cf_block.php
sudo php -l /var/www/wp-config.php

新環境の wp-config.php には、公開 IP アドレスに .nip.io を付けたドメイン(例: 203.0.113.10.nip.io)が書かれています。sed では、この部分を本番のドメインに置換しています。DB 名やパスワード、認証キーは、新環境の値をそのまま使います。

あわせて、SUBDOMAIN_INSTALL、PATH_CURRENT_SITE、SITE_ID_CURRENT_SITE、BLOG_ID_CURRENT_SITE が、旧環境と同じ値になっているかも見比べます。

wp-content の転送

旧環境から新環境へ、rsync で転送します。新環境にもともと入っているプラグイン(Jetpack など)を残さないよう、--delete を付けます。キャッシュ、一時ファイル、過去のバックアップは除外します。

SRC=/opt/bitnami/apps/wordpress/htdocs/wp-content/
EXC="--exclude=/cache/ --exclude=/wpo-cache/ --exclude=/upgrade/ --exclude=/upgrade-temp-backup/ --exclude=/ai1wm-backups/ --exclude=/blogs.dir/ --exclude=/ewww/"
nohup nice -n 19 ionice -c 3 rsync -a --delete --stats --no-owner --no-group --chmod=D2775,F664 \
  -e "ssh -i ~/.ssh/migrate_key" $EXC \
  $SRC admin@<NEW_PRIVATE_IP>:/var/www/html/wp-content/ > ~/rsync_wpcontent.log 2>&1 &

容量が大きいため、バックグラウンドで転送します。旧環境は稼働中のため、nice と ionice で優先度を下げています。進み具合は、次のコマンドで確認します。

pgrep -x rsync >/dev/null && echo 実行中 || echo 完了

完了後は、新環境で転送結果を確認します。

sudo du -sh /var/www/html/wp-content
ls /var/www/html/wp-content /var/www/html/wp-content/plugins /var/www/html/wp-content/themes /var/www/html/wp-content/mu-plugins

旧環境で有効だったプラグイン、テーマ、MU プラグインがそろっていれば成功です。

ドキュメントルートの独自ファイル

テーマやプラグインが、wp-content の外(ドキュメントルート直下)にファイルを置いていることがあります。旧環境のドキュメントルートを確認し、WordPress 標準以外のファイルがあれば、新環境へコピーします。wp-config.php のバックアップなど、機密情報を含むファイルは、コピーしません。

ls -la /opt/bitnami/apps/wordpress/htdocs

旧環境で、ファイルを送ります。

cd /opt/bitnami/apps/wordpress/htdocs
scp -i ~/.ssh/migrate_key <FILE_NAME> admin@<NEW_PRIVATE_IP>:~/

新環境で、配置します。

sudo mv ~/<FILE_NAME> /var/www/html/
sudo chown www-data:www-data /var/www/html/<FILE_NAME>

DB の更新と権限の調整

WordPress 本体が上がるため、DB を更新します。そのあと、wp-content の所有者を Apache の実行ユーザー(www-data)に揃えます。

cd /var/www/html
wp core update-db --network --skip-plugins --skip-themes --url=https://example.com
sudo chown -R www-data:www-data /var/www/html/wp-content
sudo find /var/www/html/wp-content -type d -perm -o+w -exec chmod o-w {} +

update-db の出力は、次のようになります。

WordPress database upgraded successfully from db version XXXXX to YYYYY on example.com/
...
Success: WordPress database upgraded on N/N sites.

動作確認

新環境はまだ公開していないため、HTTPS で公開したときと同じ状態を再現して、新環境自身に問い合わせて確認します。

各サイトのトップページ

for h in example.com sub1.example.com sub2.example.com; do
  curl -s -o /dev/null -w "$h  %{http_code}  %{size_download}bytes\n" \
    -H "Host: $h" -H "X-Forwarded-Proto: https" http://localhost/
done

すべてのサイトで 200 が返れば OK です。

個別記事・フィード・検索など

cd /var/www/html
ID=$(wp post list --url=https://example.com --post_type=post --post_status=publish --posts_per_page=1 --field=ID --skip-plugins --skip-themes)
P=$(wp post url $ID --url=https://example.com --skip-plugins --skip-themes | sed -E 's#https?://[^/]+##')
for p in "$P" /feed/ /sitemap.xml /robots.txt "/?s=test" /no-such-page/ /wp-login.php; do
  curl -s -o /dev/null -w "%{http_code}  %{size_download}b  $p\n" -H "Host: example.com" -H "X-Forwarded-Proto: https" "http://localhost$p"
done

存在しないページ(/no-such-page/)だけが 404 で、そのほかは 200 であれば、想定どおりです。サブサイトのフィードと sitemap も、同じ要領で確認します。

プラグインとテーマ

wp plugin list --network --skip-plugins --skip-themes --url=https://example.com
wp theme list --network --skip-plugins --skip-themes --url=https://example.com

旧環境で有効だったプラグインとテーマが、そのまま有効になっていることを確認します。

ログの確認

sudo tail -n 20 /var/log/apache2/error.log

致命的なエラー(Fatal error)が出ていないことを確認します。古いプラグインでは、PHP 8 の仕様変更により、警告(Warning)が出ることがあります。

本番切り替え

切り替えの時間帯は、記事の投稿やコメント対応を止めて、次の順に進めます。静的 IP を付け替えるまでは、本番に影響しません。ただし、最終ダンプから切り替えまでの間に、旧環境へ書き込まれた内容は新環境に反映されないため、続けて短時間で進めます。

最終ダンプを取り、新環境へ送る(旧環境)

sudo /opt/bitnami/mysql/bin/mysqldump -u root -p --single-transaction --quick --default-character-set=utf8mb4 --hex-blob bitnami_wordpress | gzip > ~/wp_final.sql.gz
scp -i ~/.ssh/migrate_key ~/wp_final.sql.gz admin@<NEW_PRIVATE_IP>:~/

uploads の最終同期(旧環境)

リハーサルのあとに追加された画像を同期します。同期するのは uploads だけです。新環境側のファイルの所有者が www-data のため、受信側を sudo で動かし、所有者を揃えます。

rsync -rlt --stats --chmod=D2775,F664 --exclude='wpo/' \
  --rsync-path="sudo rsync" --chown=www-data:www-data \
  -e "ssh -i ~/.ssh/migrate_key" \
  /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/ admin@<NEW_PRIVATE_IP>:/var/www/html/wp-content/uploads/

DB の取り込みと更新(新環境)

sudo mariadb -e 'DROP DATABASE `wordpress-db`; CREATE DATABASE `wordpress-db` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;'
zcat ~/wp_final.sql.gz | sudo mariadb wordpress-db; echo "exit status: ${PIPESTATUS[1]}"
cd /var/www/html
wp core update-db --network --skip-plugins --skip-themes --url=https://example.com
sudo chown -R www-data:www-data /var/www/html/wp-content/uploads

exit status: 0 と、Success: WordPress database upgraded on N/N sites. が出れば成功です。

新旧の内容が一致していることを確認

投稿の件数と最終更新日時、コメント数、uploads のファイル数を、新旧で突き合わせます。新旧で同じ値になれば OK です。

Multisite では、サイトごとにテーブルが分かれています。メインサイトは wp_posts、2 つ目以降は wp_2_posts のように、サイト ID が入ります。サイト ID は wp_blogs で確認し、サイトの数だけ UNION ALL で並べます(次の例は、サイト ID が 1、2、3 の場合です)。

新環境:

sudo mariadb wordpress-db -e "
SELECT 1 AS blog_id, COUNT(*) AS posts, MAX(post_modified) AS last_mod, (SELECT COUNT(*) FROM wp_comments) AS comments FROM wp_posts
UNION ALL
SELECT 2, COUNT(*), MAX(post_modified), (SELECT COUNT(*) FROM wp_2_comments) FROM wp_2_posts
UNION ALL
SELECT 3, COUNT(*), MAX(post_modified), (SELECT COUNT(*) FROM wp_3_comments) FROM wp_3_posts;"
find /var/www/html/wp-content/uploads -type f -not -path '*/wpo/*' | wc -l

旧環境:

sudo /opt/bitnami/mysql/bin/mysql -u root -p bitnami_wordpress -e "
SELECT 1 AS blog_id, COUNT(*) AS posts, MAX(post_modified) AS last_mod, (SELECT COUNT(*) FROM wp_comments) AS comments FROM wp_posts
UNION ALL
SELECT 2, COUNT(*), MAX(post_modified), (SELECT COUNT(*) FROM wp_2_comments) FROM wp_2_posts
UNION ALL
SELECT 3, COUNT(*), MAX(post_modified), (SELECT COUNT(*) FROM wp_3_comments) FROM wp_3_posts;"
find /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads -type f -not -path '*/wpo/*' | wc -l

静的 IP の付け替え

一致を確認できたら、Lightsail コンソールで静的 IP を付け替えます。

旧インスタンスの「Networking」タブで、静的 IP の「Detach static IP」を実行する
新インスタンスの「Networking」タブで、「Attach static IP」から、同じ静的 IP を選んで「Attach」を実行する

接続先の IP アドレスは同じままです。DNS の変更は不要で、付け替えた時点で、新インスタンスにアクセスが届きます。

なお、デタッチからアタッチまでの間は、数十秒ほど接続できなくなります。また、切り替え後に旧環境へ切り戻すと、新環境で書き込まれた内容は旧環境に反映されません。切り戻す場合は、この点に注意してください。

切り替え後の確認と後片付け

新環境に切り替わったことの確認

新環境で、静的 IP が付いたことを確認します。新インスタンスは IPv6 も持つため、-4 を付けて IPv4 を指定します。

curl -4 -s ifconfig.me; echo

元の静的 IP が表示されれば OK です。

手元の PC から、公開しているサイトにアクセスします。

for u in https://example.com/ https://sub1.example.com/ https://sub2.example.com/; do
  curl -s -o /dev/null -w "%{http_code}  %{size_download}b  $u\n" $u
done
curl -sI https://example.com/ | grep -iE "^(HTTP|x-powered-by|x-frame|x-cache)"

ヘッダーの出力は、次のようになります。

HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-Cache: Miss from cloudfront

旧環境は X-Powered-By: PHP/7.3.14 を返していましたが、新環境では返らなくなり、切り替わったことが分かります。

ブラウザでは、管理画面にログインし、サイトヘルスの「情報」タブで、サーバーの情報を確認します。PHP 8.2.35、Apache(Debian)、WordPress 7.1.4 と表示されます。

新環境の認証キー(wp-config.php のキーとソルト)は、旧環境とは別の値です。そのため、管理画面は再ログインが必要になる場合があります。

移行用の SSH 鍵の削除

移行が終わったら、移行用の鍵を削除します。

新環境で、公開鍵を削除します。

sed -i '/migrate-old-to-new/d' ~/.ssh/authorized_keys
grep -c migrate-old-to-new ~/.ssh/authorized_keys

0 と表示されれば完了です。

旧環境で、秘密鍵を削除します。

shred -u ~/.ssh/migrate_key && rm -f ~/.ssh/migrate_key.pub

移行用ファイルの削除

DB のダンプや wp-config.php のバックアップには、ユーザー情報や DB の認証情報が含まれます。移行が終わったら、両環境から削除します。

新環境で、削除します。

shred -u ~/wp_rehearsal.sql.gz ~/wp_final.sql.gz
sudo shred -u ~/wp-config.php.orig

旧環境で、削除します。

shred -u ~/wp_rehearsal.sql.gz ~/wp_final.sql.gz
rm -f ~/rsync_wpcontent.log

旧環境の公開を止める

旧インスタンスのファイアウォールから、HTTP と HTTPS のルールを削除し、SSH(Lightsail ブラウザ SSH のみ)だけを残します。旧インスタンスは、しばらく残して、切り戻しに備えます。切り戻しが必要になったら、ルールを開き直して、静的 IP を付け替えるだけで戻せます。

まとめ

PHP 7.3 / Ubuntu 16.04 の旧環境から、PHP 8.2 / Debian 12 の新環境へ、WordPress Multisite を移行できました。

ポイントは次のとおりです。

パッケージマネージャーで更新できない Bitnami 版の環境は、インスタンスごと新しくすることで、OS と PHP を一度に更新できました
静的 IP の付け替えだけで切り替えられるため、DNS の変更は不要でした
旧インスタンスを残しているため、切り戻しも静的 IP の付け直しで済みます
MySQL 8 から MariaDB への移行は、今回の環境では、照合順序を事前に確認しておくことで、問題なく取り込めました

チェックリスト

☐ 移行前に、旧インスタンスのスナップショットを取得する
☐ MariaDB へ移す場合は、DB の照合順序を確認する
☐ 新環境の wp-config.php は、新環境のものを土台にし、Multisite の設定と HTTPS 判定だけを追記する
☐ wp-content の外(ドキュメントルート)にある、テーマやプラグインのファイルを確認し、コピーする
☐ 新環境の phpMyAdmin のリンクを削除する
☐ 切り替え前に、投稿・コメント・ファイルの件数を、新旧で突き合わせる
☐ 旧インスタンスのドキュメントルートに、古い設定ファイルなどが残っていないか確認する
☐ 移行用の鍵、DB のダンプ、wp-config.php のバックアップを削除する
☐ 旧インスタンスは、しばらく残して、公開を止める

AWS,Lightsail,Web製作 & WordPressLightsail,PHP,Wordpress,Wordpress Multisite

Posted by takaaki

Home

Zed起動時にClaude Code連携が失敗する課題の解決策