The One Email That Actually Matters: Why I Finally Stopped Failing at Migrations

I spent three days last month arguing with a client about whether we should migrate their documents. Three days. We were already two weeks behind, the stakeholders were frustrated, and I was pulling apart spreadsheets trying to figure out the impact. By day three, I realized nobody actually owned the decision. It was floating in the air between four people who all had opinions but no skin in the game. That afternoon, I read an article about database migrations that made me feel seen in a way technical writing rarely does, not because it taught me something new, but because it named a problem I've been wrestling with for years.

The article walks through a real migration project from kickoff to go-live, and it's structured around a deceptively simple idea: every stage ends at a gate, and every gate requires one named person to sign off in writing that work is complete. That's it. But the implications are enormous.

The Gate System Changed How I Think About Project Control

What struck me immediately is how much permission structure matters. I've always managed migrations through status updates, burn-down charts, and weekly stand-ups. Those tools work for tracking progress, but they don't actually close anything. They just document ongoing ambiguity.

Gates are different. A gate isn't a checkpoint for information, it's a moment where a decision-maker reviews evidence and commits to moving forward. The email doesn't say "we think we're ready." It says "this stage is done, signed by the person who owns it." That means when something breaks later, you know exactly when it stopped being the previous stage's responsibility.

In the example project, the Data Owner (J. Okafor) was named on day one. Every data question went to one inbox instead of bouncing through committees. That single decision probably saved more time than any technical optimization. I've done the opposite, let questions scatter across Slack, email, and meetings, and watched the same ambiguity get solved three different ways across three different teams.

Scope Creep Isn't Evil Until Someone Owns the Date

The most practical insight in the article is how it handles change requests. When the client asked to migrate scheduling history that wasn't in scope, the response wasn't "yes" or "no." It was the cost: three more weeks, two weeks of effort. Then two options with real consequences. Do it and push go-live, or keep the date and save it for phase two.

The client chose to keep the date. Why? Because the person who owned the date was the one seeing the cost. Not the person who requested the feature. That's almost never how I've seen it work.

Usually, feature requests go through a backlog, get estimated by engineers, then resurface in planning conversations where the person who requested them doesn't understand or believe the estimate. Months later, we're either shipping late or cutting scope in a panic.

The article shows something different: cost transparency to the decision-maker, before the conversation about whether to do the work. It's not revolutionary, but it's rare.

My Take on the Paper Trail

I like that the article obsesses over documentation. Every gate produces a stored email. The field map gets frozen to a version number. Change requests get logged with impact statements. This sounds bureaucratic, but having rebuilt a failed migration where nobody could remember why certain decisions were made, I see the point.

What I'd push back on slightly: email is fragile. It gets lost, forwarded wrong, archived in accounts that get deleted. For a five-month project, I'd want something more intentional. A shared document with version control. A decision log that lives in the actual project wiki. Something that doesn't depend on someone's inbox staying organized.

The other thing I want to know is what happens when the date still slips anyway. The article catches the project mid-cutover, with go-live still unsigned. What created that pressure? Was it the gate system that failed, or something outside of gates?

What I'm Actually Doing Differently

I'm starting a new migration next month, and I'm stealing the gate structure wholesale. I'm naming a data owner on day one. I'm putting dates on every stakeholder action, not just ours. And when someone asks for scope, I'm calculating cost first, not "I'll look into it."

The part I'm changing: I'm using a shared decision log instead of relying on email threads. Every gate gets a short summary, what was reviewed, what was decided, who signed it, in a document everyone can see.

Have you done a migration where the gates worked exactly as planned, or did something about this structure break under pressure?

Source: This post was inspired by "One Migration, Start to Finish" by Dev.to. Read the original article