I’ve watched dozens of IT modernization projects over the past two decades, and there’s a pattern that’s almost too consistent to ignore. Projects start strong, make excellent progress for the first few months, and then around 60-70% completion, they just… stop. Not officially. They keep burning budget and holding status meetings. But the actual forward momentum grinds to a halt.

This isn’t a coincidence. There’s a specific set of forces that converge at this point in every modernization effort, and if you don’t recognize them, you’ll end up with another “ongoing initiative” that’s still ongoing three years later.

The Easy Wins Are Gone

The first 60% of any modernization project is, frankly, the fun part. You’re replacing the obvious pain points. That ancient Oracle database that costs a fortune to maintain? Gone. Those batch processes that take 12 hours to run? Re-architected. The low-hanging fruit gets picked quickly, and everyone’s happy.

But then you hit the messy middle. The stuff that’s deeply woven into your business processes. The custom integrations that nobody documented. The workflows that exist because “that’s how Sandra does it,” and Sandra’s been here for 18 years. This is where projects stall.

According to McKinsey’s research on digital transformations, only 30% of transformation efforts succeed. The primary reason? They underestimate the organizational change required once you get past the technical quick wins.

Change Fatigue Sets In

Your team was excited at the start. New technology, modern stack, promises of better ways of working. But by month six, they’re exhausted. They’re maintaining the old systems, building the new ones, and dealing with all the integration headaches in between.

I’ve seen change fatigue manifest in subtle ways. Suddenly there are more questions about whether we really need to modernize this particular component. Maybe the old way isn’t so bad after all? The business starts asking if we can “just pause for a quarter” to let things settle.

This is the exact moment where most projects die. Not with a bang, but with a collective exhale and a quiet agreement to stop pushing so hard.

The Business Case Gets Fuzzy

When you’re planning modernization, the business case is crystal clear. Faster deployments, reduced maintenance costs, better scalability. Everyone nods along in the steering committee meetings.

But as you approach that 60% mark, something interesting happens. The benefits you’ve already delivered get normalized. Teams forget how painful the old way was. Meanwhile, the remaining 40% of work looks increasingly expensive and disruptive for benefits that seem less tangible.

I worked with the Team400 team on a client engagement last year where this exact dynamic played out. We had to go back and re-quantify the value of completing the modernization versus the cost of running a hybrid estate indefinitely. Turns out, stopping at 60% was the most expensive option by far.

How to Push Through

So what actually works? Here’s what I’ve seen succeed:

Break the remaining work into smaller milestones. Stop talking about “completing the modernization.” Start talking about “migrating the billing system by June” or “deprecating the legacy API by Q3.” Make the next chunk of work feel achievable.

Celebrate technical debt paydown. The last 40% of modernization is often boring infrastructure work. Database migrations, API versioning, documentation. This stuff doesn’t feel like progress, but it’s critical. Make it visible. Track it. Treat it like the important work it is.

Rotate your team. If possible, bring in fresh people who haven’t been grinding on this project for the past year. They’ll bring new energy and won’t be carrying the accumulated frustration of every setback.

Get ruthless about scope. That legacy report that three people use once a year? Maybe it doesn’t need to be migrated. Maybe those users can just get read-only access to the old system for another six months. Perfect is the enemy of done, and at this stage, done matters more.

The Real Enemy Is Ambiguity

The fundamental problem at the 60% mark is that you’re in limbo. You can’t fully retire the old systems yet, but you also can’t stop maintaining the new ones. You’re paying for both, and the end date keeps slipping.

The solution isn’t to work harder or push your team to put in more hours. It’s to get absolutely clear about what “done” means, communicate it relentlessly, and protect your team from scope creep.

I’ve never seen a modernization project that stalled at 60% and then magically recovered without a significant intervention. Either leadership needs to recommit with real resources and clear timelines, or you need to acknowledge you’re stopping here and make peace with a hybrid operational model.

The middle ground—that ongoing initiative that’s perpetually “almost done”—is where budgets go to die and IT careers get stalled. Don’t let your project become one of them.

What This Means for IT Leaders

If you’re planning a modernization effort, assume you’ll hit this wall. Build it into your planning. Budget for it. Warn your stakeholders it’s coming. And most importantly, plan your quick wins so they keep coming throughout the project, not just at the start.

The projects that succeed are the ones where leadership recognizes the 60% stall before it happens and takes action early. By the time everyone’s openly talking about the slowdown, you’re already six months behind where you need to be.

Modernization is hard. But it’s a lot harder when you don’t see the predictable challenges coming.