A customer asking who set up their domain turned into finding that our migration tracker was wrong about 85 sites, five days before we were due to switch off the address 96 of them still point at.
What I did about the tracker
I filed the tracker fix, and a plan to keep those sites alive rather than let them go dark. I also built the per-domain research for the personal outreach.
The contact source was wrong for nearly half
We sent a personalised domain-migration warning to 94 customer accounts (216 people) whose sites go dark when the old server address is retired. We built the audience from scratch when the contact source we had assumed turned out to be wrong for nearly half of them. Along the way we found and excluded customers who had already left the platform, customers whose domains were no longer registered, and customers who had already migrated.
A warning for blocked domain forwarding
We shipped a change to production that warns customers when domain forwarding is blocking the change they are being asked to make, names their registrar, and shows the same detail to support staff.
I filed two tickets covering the stale mailer deadlines and the twelve customers who need a different message.
Recovery emails that would have said the same thing to everyone
I also sent recovery emails to 26 customers whose site-expiration notices had hard-bounced during a reverse-DNS outage, and confirmed every one of them was actually delivered.
The prepared drafts would have sent everyone the same email. People had originally been sent three different versions, depending on how far along they were. Reading the real send log instead of the account flags fixed that, and it also caught one person the system had already re-contacted.
AI Skills
Use this lesson with the AI assistant you already use
Five days before retiring an old server address, a live DNS check showed the migration tracker was wrong about 85 sites. Rebuilding the warning audience from scratch produced 94 accounts and 216 people after excluding customers who had left, domains no longer registered, and accounts that had already migrated.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON ยท paste into your AI coding agent
LESSON: Re Derive Every Cutoff Inventory From Live State Before An Irreversible Send
SOURCE: dxdev.com/blog/2026-09-26_inventory-audit-near-cutoff
WHAT HAPPENED: A customer asked who had set up their domain, and checking the migration tracker against live DNS showed the tracker was wrong about 85 sites, five days before the old server address was due to be switched off. The contact source assumed right for account owners was wrong for nearly half the accounts, so the warning audience was rebuilt from scratch, per domain, then customers who had left, domains no longer registered and accounts already migrated were excluded. Separately, reading the real send log instead of the account flags showed that 26 recovery emails needed different message versions than the prepared drafts would have sent. The warning went to 94 customer accounts and 216 people.
THE RULE: Before an irreversible cutoff or customer warning, rebuild the relevant inventory from current source records instead of relying on an older summary field. Check both who should receive the message and which version of it they should get, from the real records.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For every item marked complete, compare the tracking status with the current live state that determines whether it is actually complete.
2. Build warning recipients from records tied to the affected resource, then remove accounts that have already migrated, left, or no longer own the resource.
3. Before sending, check the real send log and live state for each recipient's message variant, not only the account flags.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.