Landing a Time-Sensitive API Migration

A platform API was being retired on a hard deadline. Customers who hadn't migrated by that date would break — not degrade gracefully, break. The affected population was large, spread across agencies with wildly different technical capacity, and a month in it was clear that broadcast emails weren't going to get there.

Government customers don't ignore migration notices out of negligence. The notice lands in a shared inbox, the person who ran the integration left two years ago, and nobody currently on staff knows which systems call which APIs.

I built readiness tracking so we always knew exactly who stood where: migrated, in progress, unresponsive, blocked. Communications went out in waves matched to status rather than one-size-fits-all blasts.

Then the part that actually moved the number: I personally worked the long tail, agency by agency — finding the right human, walking them through what the migration meant for their specific configuration, and escalating real blockers into services. The last stretch of a migration doesn't respond to another email. It responds to a person.

Nearly the entire customer population converted by the deadline, and the stragglers were known cases with plans — not surprises.

What I learned: migration success is an operations discipline. The technical work is table stakes; the outcome is decided by segmentation, communication cadence, and the willingness to do individual outreach at the tail. This is the muscle I bring to any platform transition, deprecation, or customer-landing problem — and it's why forward-deployed and implementation-heavy work feels native to me.