Why projects die
The 5 killers that tank enterprise migrations (and how to dodge every single one before they burn your team, budget, and sanity)
This article is part of the Plan and scope like a data product manager playlist. Click here to explore the full series.
I just exited a failed project.
Not one of those “well, we learned a lot“ kind of failures. A full-blown, dragged-out, slow-motion collapse. The kind where everyone’s exhausted, the budget’s cooked, and the thing we set out to build is still… not live.
I didn’t lead it. I wasn’t even there from the start. But for the last year and a half, I helped in every way I could, migrations, cleanup, edge-case triage, whatever needed doing.
The project had been running for years before I joined, and even back then, people were already whispering that it might never ship.
The thing is, you can feel when a project is doomed. You see the warning signs. You hear them in meetings. You spot them in JIRA tickets. You feel them in your gut.
And yet, the train keeps moving.
No one pulls the brake. No one changes course. And slowly, predictably, it all falls apart.
But I’ve also worked on several successful migrations. Projects that shipped, worked, and got adopted without burning everyone out.
That contrast taught me a lot.
What I’m about to share are the five patterns I’ve seen ruin migration projects over and over again. These are the killers that sneak in early, hide in plain sight, and quietly wreck the whole thing.
You’ve seen them too. You just might not have had names for them yet.
Let’s change that.
1. No one owns the damn thing
Everyone’s involved, but no one’s responsible. That’s how these things start.
You get the kickoff doc. A Notion dashboard. Twenty-five people on the first call. Everyone smiling. Everyone aligned. Everyone excited to “collaborate.”
Then it begins.
Designs stall. Tickets pile up. Questions float. Someone says, “Let’s escalate this”. Another says, “Let’s park it for now”. And somehow, every decision needs another meeting.
Because there’s no single person with real authority.
There are “workstream leads” and “product partners” and “sponsors” and “technical owners”. But there’s no one whose ass is actually on the line. No one empowered to say, “Cut this scope”, or “Ship this now”, or “No, we’re not doing that”.
And without that kind of ownership, every decision turns into a negotiation. Every delay becomes “understandable”. Every missed deadline becomes “just part of the process”.
I’ve seen projects drag on for years because no one wanted to be the one to make the hard call.
Instead of one pissed-off decision-maker, you get six polite blockers.
You want your migration to ship? Give someone the power, and the expectation, to own it.
Not a steering committee. Not a Slack channel. A name.
That’s where clarity begins.
2. You never define what success looks like
I’ve seen projects spin with dozens of people building “progress” in completely different directions. Because no one stopped to ask the simplest question: What does done look like?
You’d think that would be obvious. It never is.
You’ll hear vague goals like “complete the migration”, “cover all use cases”, “ensure nothing breaks”.
Great. Now ask ten different people what that actually means, and you’ll get ten different answers.
One team’s building for parity. Another is chasing “platform modernization”. A third wants to clean up tech debt.
Suddenly you’re doing three projects at once under the same budget, same timeline, and same release plan.
That’s how you end up with a solution that’s overbuilt in some areas, duct-taped in others, and never quite ready to go live. Because someone always thinks, “We can’t ship yet. We still haven’t finished X”.
And they’re right, because no one ever agreed on where the finish line is.
I’ve been in those meetings where you’re 90% “done”, but you’re still debating what counts as success.
Nobody feels confident. Nobody wants to greenlight the launch. The team’s burned out, and leadership’s confused why this thing isn’t live yet.
Here’s the truth:
Most migration projects don’t suffer from bad execution. They suffer from fuzzy direction.
If you don’t define success up front, you can’t prioritize. You can’t cut scope. You can’t win.
Before you plan a sprint, define what winning looks like. In a single sentence. Make it boring. Make it clear. Make it measurable if you can.
Then pin it to the wall and fight to protect it.
3. You see it’s not working… and keep going anyway
Everyone knows it’s not working. You feel it in your bones.
The timeline is fake. The scope is out of control. The team’s stuck in meetings, context-switching between half-baked priorities, while the original “go-live” date is a running joke.
And yet, no one stops. No one challenges the plan. You just keep pushing, even though nobody believes in the thing anymore.
Why? Because sunk cost thinking takes over.
You’ve already spent six months on this. You’ve already written the code. You’ve already told leadership it’s almost done.
So now, instead of admitting it’s off track, you start doubling down on the plan that got you here.
More meetings. More rework. More pressure. Less clarity.
This is the death spiral of a migration: when momentum turns into inertia. When continuing feels easier than fixing. When the calendar matters more than the outcome.
And it’s always avoidable.
Build in checkpoints. Real ones. Not “demo days” or executive updates, but moments where the team stops and says: “Should we keep going? Should we change course? Should we kill this?”
Make it safe to pause. Make it normal to question the plan. If the thing you’re building doesn’t make sense anymore, stop. Not later. Now.
Otherwise, you’ll spend another three months polishing a project that should have been buried two quarters ago.
4. You replace execution with meetings
This one sneaks up on you.
At first, it’s just a couple check-ins to “keep alignment tight”. Then a few working groups. A standup or two. A sync with the PMs. A weekly update with leadership. A follow-up to the sync. A retro. A pre-read for the weekly.
Before you know it, the people doing the work are spending more time talking about it than building it.
I’ve been on migration projects where engineers had three or more meetings a day. Not optional. Not short. Not useful. Just recurring, bloated, calendar-filling chaos.
Because meetings feel like momentum. You show up. You provide your update. You nod through decisions that should’ve been made offline. You leave with ten new action items and zero deep work hours left on the clock.
And execution happens at night. Or on weekends. Or not at all.
And the longer this goes on, the slower the project gets. But nobody panics, because the status updates still look fine. The slide spreadsheet moves forward.
This is how projects rot: in perfectly formatted sheets and beautifully color-coded dashboards.
Don’t let that happen.
Protect your builders. Standups should be 15 minutes max. Weekly status updates should be async. Ad hoc questions belong to Slack or a quick call.
If your meetings need meetings, you’ve already lost half your engineering hours to overhead.
Get ruthless about the calendar. Because your project’s velocity lives or dies inside it.
5. You treat launch as the finish line
There’s this magical thinking that happens near the end of a migration.
People start saying things like “we’re almost done”, “go-live is around the corner”, or “just a bit more testing and we’re good”,
Everyone’s exhausted. Leadership wants it off the books. So you pick a date, lock it in, and call it done.
Then you flip the switch. And everything breaks.
I’ve seen it happen more than once. You ship the MVP, but there’s no real plan for what comes next. No backup. No rollback path. No second phase. No owner for the cleanup. And definitely no one watching how adoption’s going.
The dashboards light up with errors. Users complain. Execs ask why things are missing. Engineers panic and start patching in prod.
Meanwhile, the project team is already off to the next initiative, and you’re left holding a half-migrated mess.
Because somewhere along the way, launch became the goal. Not the beginning of a new stage, but the end of a sprint.
That mindset is a killer.
A real migration plan doesn’t stop at go-live. It builds checkpoints into every phase:
What’s in scope for v1?
What’s the definition of done for v2?
What happens if adoption stalls?
Who owns support and follow-up?
What metrics tell you this thing actually worked?
You don’t need a 90-slide launch plan. You need clarity on what happens the day after.
Without that, go-live is just the start of your next disaster.
Final thoughts
It’s almost never one big mistake.
Migrations fail because five small things creep in early, get ignored, and pile up until there’s no clean way out.
Ownership gets vague. Goals stay fuzzy. The plan stops working but no one adjusts. Calendars fill up. Everyone celebrates go-live… and nobody sticks around for the cleanup.
You’ve seen it. You’ve probably lived it. So have I.
But here’s the good news: these failures are preventable. They’re patterns. And patterns can be broken as long as you name them early, call them out, and course-correct before the damage compounds.
That’s the job. Not just shipping the system, but protecting the team that builds it.
If your migration feels stuck, overcooked, or somehow “off”, one of these five killers has already slipped in.
Find it. Fix it. Don’t let it spread.
Thanks for reading,
Yordan
PS: In the paid tier, subscribers get my exact step-by-step guide on building projects that secure stakeholder buy-in.
Ruthless focus and combined with slash and burn approach to fluff and non-essentials is how I avoid the problem.