Pages loaded, images loaded, but every font and icon was blocked by CORS. The page came from www and the fonts from the bare domain, because a canonical constant pinned in wp-config had forced the wrong hostname into every asset URL. Fonts are the assets browsers fetch in CORS mode, so they were the only ones to complain. Working out the right canonical automatically then went wrong twice, once by trusting a database value that had been silently overridden for years. What stuck is dull. A human writes it down, and a probe checks where the live redirect chain actually lands.

Phase seven of the migration moved the static IP to the new server. Phase eight couldn’t get a certificate. The site wasn’t reachable, and it hadn’t been before I touched it either: the domain’s DNS zone had no A records at all. Every preflight check had been about the server and none about the road to it. Preflight now resolves the domain through a public resolver before anything expensive happens, and for Cloudflare-fronted sites it checks Cloudflare can actually reach an origin. Check the assumptions your last step depends on, not just your first.

Done by hand, the fleet migration would have meant accepting an SSH host-key prompt about 300 times, and nobody reads the fingerprint on the fortieth. So the provisioning script fires a probe it expects to fail, scrapes the fingerprint out of plink’s refusal, and pins it for every connection after. It’s still trust-on-first-use, same as typing yes, but it happens seconds after creating the server through an authenticated API call. The catch turned up later. A server has more than one host key, and which one you get shown depends on what your own client has cached.

A backup plugin with a 400 MB appetite, a 1 GB server still serving live traffic, and a box that swap-thrashed until real visitors started timing out. Then the same plugin hung for six hours restoring a big multisite, doing row-by-row URL replacement across millions of rows. Too heavy at one end, too slow at the other. The fleet migration ended up with three ways to move a site, picked automatically: the plugin for ordinary sites, a streaming tar and mysqldump for the tiny boxes, and a direct database import for the giants.

All-in-One WP Migration printed “Success: Backup complete.” and wrote nothing. No archive, and no error on the command line. The admin screen told the real story: the plugin couldn’t create the guard files it drops into its backups folder, so it quietly gave up before writing a byte. On Bitnami that folder belongs to the bitnami user, but PHP runs as daemon, the group, with no write bit. The fix is the right owner plus chmod 2775, baked into the migration tooling so it never comes up again. A success message is a claim. Check the file is actually there.

Bitnami’s WordPress image on Lightsail is on its way out, which left me with roughly sixty live sites sitting on a foundation with a use-by date. This is the overview of moving all of them to AWS’s own managed blueprint. One site at a time, through a ten-phase pipeline that records every finished step to disk so a re-run picks up exactly where it broke. Old servers get stopped, not deleted, and sit there for a week in case something turns up. The constraints that shaped it, from no IAM roles on Lightsail to 300 host-key prompts, each get their own post in the series.

In August a forms plugin couldn’t write under uploads on a freshly migrated server, so I wrote a repair script for uploads. In September the migration plugin couldn’t “create” a file that already existed, nowhere near uploads. Same cause both times. Files unpacked by the admin user came out 755 and 644, and setgid on the parent carries the group across but not the permission bits. The real fix is setgid plus a umask of 002 at provision time, with a wider repair sweep for boxes already out there. When a repair script takes a path argument, be suspicious of the path.