I count the posts three times before flipping a WordPress host migration

Three passes, not one

I started out planning to compare counts only. A thousand on the old side, a thousand on the new. That felt sufficient.

It was not. Equal counts do not mean equal contents.

I settled on three passes because I built the two-pass failure myself and watched it slip through. That is the next section.

Here is the comparison script I actually run. It writes one line per post — ID, modified time, and body length in bytes — from each side, then diffs them.

#!/usr/bin/env bash
# Compare every WordPress post on the old and new servers before cutover.
# Production: ./wp-migration-diff.sh example.com 203.0.113.10 198.51.100.20
# Local test: BASE_OLD=http://127.0.0.1:8801 BASE_NEW=http://127.0.0.1:8802 ./wp-migration-diff.sh example.com
set -uo pipefail
 
DOMAIN="${1:?domain required}"
OLD_IP="${2:-}"
NEW_IP="${3:-}"
PER_PAGE=100
STATUSES="publish,future,draft,pending,private"
 
# Counting drafts and scheduled posts needs authentication.
# Put "user:application_password" in WP_AUTH.
AUTH_ARGS=()
[ -n "${WP_AUTH:-}" ] && AUTH_ARGS=(--user "$WP_AUTH")
 
fetch() {  # $1=old|new  $2=path
  local side="$1" path="$2"
  if [ "$side" = old ]; then
    if [ -n "${BASE_OLD:-}" ]; then
      curl -sS --max-time 30 "${AUTH_ARGS[@]}" "${BASE_OLD}${path}"
    else
      curl -sS --max-time 30 "${AUTH_ARGS[@]}" --resolve "${DOMAIN}:443:${OLD_IP}" "https://${DOMAIN}${path}"
    fi
  else
    if [ -n "${BASE_NEW:-}" ]; then
      curl -sS --max-time 30 "${AUTH_ARGS[@]}" "${BASE_NEW}${path}"
    else
      curl -sS --max-time 30 "${AUTH_ARGS[@]}" --resolve "${DOMAIN}:443:${NEW_IP}" "https://${DOMAIN}${path}"
    fi
  fi
}
 
# Matching counts will not surface a post that arrived with an empty body.
# Take the length as well.
dump() {
  local side="$1" page=1 out n
  : > "/tmp/wpdiff-${side}.tsv"
  while : ; do
    out="$(fetch "$side" "/wp-json/wp/v2/posts?per_page=${PER_PAGE}&page=${page}&status=${STATUSES}&_fields=id,modified_gmt,content&orderby=id&order=asc")" || return 1
    n="$(printf '%s' "$out" | python3 -c '
import sys, json
rows = json.load(sys.stdin)
if isinstance(rows, dict):   # WordPress returns an error object past the last page
    rows = []
for r in rows:
    body = (r.get("content") or {}).get("rendered", "")
    print("%s\t%s\t%d" % (r["id"], r.get("modified_gmt", ""), len(body.encode("utf-8"))))
print("__COUNT__%d" % len(rows), file=sys.stderr)
' 2>/tmp/wpdiff-n)" || return 1
    printf '%s' "$n" | sed '/^$/d' >> "/tmp/wpdiff-${side}.tsv"
    grep -q '__COUNT__0' /tmp/wpdiff-n && break
    grep -q "__COUNT__${PER_PAGE}" /tmp/wpdiff-n || break
    page=$((page + 1))
  done
  sort -n -o "/tmp/wpdiff-${side}.tsv" "/tmp/wpdiff-${side}.tsv"
}
 
dump old || { echo "Failed to read the old server"; exit 2; }
dump new || { echo "Failed to read the new server"; exit 2; }
 
OLD_N=$(wc -l < /tmp/wpdiff-old.tsv | tr -d ' ')
NEW_N=$(wc -l < /tmp/wpdiff-new.tsv | tr -d ' ')
echo "count: old ${OLD_N} / new ${NEW_N}"
 
cut -f1 /tmp/wpdiff-old.tsv | sort > /tmp/wpdiff-old.ids
cut -f1 /tmp/wpdiff-new.tsv | sort > /tmp/wpdiff-new.ids
 
MISSING="$(comm -23 /tmp/wpdiff-old.ids /tmp/wpdiff-new.ids)"
EXTRA="$(comm -13 /tmp/wpdiff-old.ids /tmp/wpdiff-new.ids)"
SHRUNK="$(join -t$'\t' -j1 /tmp/wpdiff-old.tsv /tmp/wpdiff-new.tsv \
  | awk -F'\t' '$5 != $3 || $4 != $2 { printf "%s old %s bytes / new %s bytes\n", $1, $3, $5 }')"
 
FAIL=0
[ -n "$MISSING" ] && { echo "missing on the new server:"; echo "$MISSING" | sed 's/^/  id /'; FAIL=1; }
[ -n "$EXTRA" ]   && { echo "missing on the old server:"; echo "$EXTRA"   | sed 's/^/  id /'; FAIL=1; }
[ -n "$SHRUNK" ]  && { echo "body or modified time differs:"; echo "$SHRUNK" | sed 's/^/  id /'; FAIL=1; }
 
if [ "$FAIL" -eq 0 ]; then
  echo "No differences. Safe to cut over."
else
  echo "Differences found. Hold the cutover."
fi
exit "$FAIL"

I include drafts and scheduled posts in status because counting published posts only means a missing scheduled post stays invisible until its publish time arrives. It costs an authentication step, but this runs once on migration night, so I lean toward including them.

I broke it locally before pointing it at production

As an indie developer I usually have nothing but production data to test against. But a script like this one has to be watched failing first, or you will read "no output" as a pass. I nearly did exactly that.

So I stood up two fake WordPress REST endpoints on my own machine first. One plays the old server, one plays the new, and I introduced two kinds of loss on purpose:

• One post present on the old side and absent on the new — standing in for the article published after the copy snapshot
• One post with a matching ID and modified time whose body was empty

Running the script against that pair gives:

count: old 6 / new 5
missing on the new server:
  id 6
body or modified time differs:
  id 3 old 203 bytes / new 0 bytes
Differences found. Hold the cutover.

Pointed at identical data, it stays quiet:

count: old 6 / new 6
No differences. Safe to cut over.

This is the part that went against what I expected. A count-only comparison lets id 3 through as a match. Adding the ID comparison changes nothing. Only the body length brings it to the screen.

Put another way: matching counts prove the numbers agree, not that the content arrived. It took me two rebuilds of the fake servers before I could write that sentence with any confidence.

Moving the A record alone leaves your mail on the old host

Even once the posts line up, you are halfway. Cutover means editing DNS, and the A record is not the only thing that has to move.

Fixing a record you forgot is easy while the old server is still alive, and impossible once it is gone. That is why cancelling the old host sits last in my order of operations.

SPF is the one I missed. The old server's hostname was written in directly with a:, and it sat there untouched after the switch. This small script prints out what the current SPF record actually points at:

# Pull the current SPF record and list every host it references.
dig +short TXT example.com | tr -d '"' | grep '^v=spf1' | python3 -c '
import sys, re
txt = sys.stdin.read()
for tok in txt.split():
    m = re.match(r"^(?:\+|~|-|\?)?(a|mx|ip4|ip6|include|redirect)[:=](.+)$", tok)
    if m:
        print("%-8s -> %s" % (m.group(1), m.group(2)))
    elif tok in ("a", "mx"):
        print("%-8s -> (this domain)" % tok)
'

Any old-host names in that output are homework waiting for you after the switch. I run it the day before and write the lines I need to change on paper before migration night.

What I hand to an agent, and what I do not

This is the part I thought about most.

I hand over the work that is high in volume and free of judgment: enumerating and comparing every post, taking inventory of DNS records, crawling for broken links after the switch. Each has exactly one right answer and far too many items for me to eyeball. Give it the procedure and the same result comes back every time.

I keep the moves that cannot be undone: the migration tool's switch button, the actual DNS edit, and deleting the old server. Those I press myself. Knowing the exact minute I pressed them is worth something on its own.

Recounting goes to the agent; the irreversible press stays on my own finger. That line is the one I hold to hardest on the nights I am tired.

In practice I run the scripts in the embedded terminal, read the output on the spot, and chase down any difference before moving on. I wrote about building that verification loop in Building a verification loop for agent changes in the Antigravity 2.10.0 embedded terminal. Deciding in advance how much reading is auto-approved keeps the night from stalling; Redrawing the workspace surface once review mode auto-approves reads covers that side.

The first thirty minutes after the switch

There is still work after you press it, and the order matters.

1. If you shortened the DNS TTL, confirm propagation before restoring it. Query dig +short example.com @8.8.8.8 and @1.1.1.1 until both return the new address
2. Purge any cache sitting in front. Reading a stale response and concluding the migration failed is the most wasteful misdiagnosis available that night
3. Run the comparison script again — this time with the old server pinned by IP and the new one reached through DNS. That confirms the side your readers actually see
4. Send yourself a message through the contact form. One real message is the fastest way to settle whether MX and SPF are right
5. Do not delete the old server yet. I keep mine for at least a week

If you take one item from that list, take the third. Once before the switch and once after: the same script, run twice, separates "the data moved" from "readers are reaching it."

If you are migrating tonight, start by pulling X-WP-Total from both sides just once. A mismatch is a reason to stop. If the numbers agree, the body lengths can wait until after your next cup of coffee.

Thank you for reading this far. If any of it saves someone else's late night, I would be glad.