A few weeks after writing that CURLOPT_TIMEOUT of zero is never the right value, I typed it in myself. An itinerary build streams for several minutes with live searches in the middle, and a 300-second total cap was cutting off a stream that was still delivering. A total timeout can’t tell working from dead — both look like still open, still not finished. So measure silence instead: no total cap, and a low-speed watchdog that gives up after two minutes below a byte a second. That only works because the upstream sends pings while it thinks, so check before you lean on it. Match the timeout to the thing you’re actually measuring.

A migrated multisite where three of the five subsites sit on their own external domains. Front end perfect everywhere, login dead on the mapped three, and WordPress blaming the browser. It was never the browser. With no COOKIE_DOMAIN defined, WordPress stamps every auth cookie with the network’s primary domain, and no browser will accept a cookie scoped to an unrelated apex. Authentication succeeded; the cookie simply wasn’t allowed to land. One constant, scoped to the host the request arrived on, fixes it — at the cost of network-wide single sign-on. The old server had this hand-patched years ago. A migration copies files and databases, not undocumented config edits.

Two JSON files cached side by side from the same feed, pulled by the same importer, using id and parentId in opposite senses. Nothing in either file tells you which one you’re holding. That single wrong assumption produced two failure modes: an admin dropdown that threw a TypeError the day it appeared, and a second one that had been silently collapsing twelve hundred ships into one row per cruise line for years. The loud one got reported in an afternoon. The quiet one just looked like a short list, and nobody counts the options in a dropdown. There’s a third copy of the same loop still cached on the front end.

The site wasn’t down, which was the confusing part. It answered, forty seconds at a time, in waves. The PHP-FPM slow log pointed every stuck request at the same curl_exec(), talking to a travel API that was having a bad afternoon. Our cURL options carried CURLOPT_TIMEOUT set to zero, which doesn’t mean no time — it means no limit. Slow calls held FPM workers until the pool filled, and then pages that never touched that API queued up behind them too. The fix is a total timeout, a connect timeout, and actually handling the error when it fires. Leave it at zero and you’ve handed a stranger the power to freeze your site by being slow.

On EC2 you’d attach an IAM role and never see a key. Lightsail can’t do that, and during the migration both servers needed to reach S3. The setup: a dedicated IAM user with a tightly scoped policy, keys kept on the operator laptop only, and credentials handed over as environment variables for a single SSH command, never written to disk. Writing it up, I found a few things I’d got wrong, not least that the servers were getting far more permission than they needed. The fix is fifteen-minute, single-bucket credentials from STS.

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.