3 Steps To Rescue A Broken Business Central Project

Published on:  
October 14, 2025

When Projects Go Wrong

The call always starts the same way.

The project is behind schedule. Way behind. The go-live date passed months ago. The team is frustrated. Leadership is asking hard questions.

And nobody knows how to fix it.

We've rescued dozens of broken Business Central projects. The problems are always different. But the pattern is always the same.

Here's how we fix them.

Step 1: Stop And Assess

The first instinct when a project is failing? Work harder. Move faster. Add more people.

This makes everything worse.

When we take over a broken project, we do the opposite. We stop. We assess. We figure out what's actually broken.

What we look for:

Scope problems. Is the project trying to do too much? Are requirements still changing every week? Does anyone actually know what success looks like?

Technical debt. How much custom code exists? Is it documented? Does it work? Can anyone maintain it?

Process gaps. Are business processes clear? Or is the team building software to automate chaos?

Communication breakdowns. Is IT talking to the business? Is anyone making decisions? Who owns what?

Resource issues. Does the team have the right skills? Are they overwhelmed? Are critical people missing?

This takes one to two weeks. No coding. No building. Just understanding what went wrong.

Most consultants skip this step. They jump straight to fixing symptoms. This is why rescue attempts fail.

Step 2: Make Hard Decisions

Once we know what's broken, we make decisions. Hard ones.

This is where most rescue projects fail. Because nobody wants to cut scope. Nobody wants to throw away work. Nobody wants to admit the original plan was wrong.

But you can't fix a broken foundation by building faster on top of it.

What we cut:

Nice-to-have features. Everything that isn't core to going live gets pushed to phase two. No exceptions.

Bad custom code. If customizations are causing problems and aren't critical, we delete them. Start with standard.

Broken processes. If a business process doesn't make sense, we fix the process first. Not the software.

Unclear requirements. If nobody can explain why something is needed, it gets cut. Clarity first.

What we keep:

Core business functions. The minimum needed to run the business. Finance. Sales. Purchasing. Stock. Nothing fancy.

Clean data. Good master data. Clear transactions. Proper setup. This is non-negotiable.

Working integrations. Only the ones that are truly required. Everything else waits.

This phase takes one week. At the end, you have a clear plan. Everyone knows what's in scope and what's not.

Step 3: Execute With Discipline

Now we build. But differently.

No more feature creep. No more last-minute changes. No more building without testing.

How we work:

Fixed scope. What we agreed in step two is what we build. Nothing gets added without cutting something else.

Weekly demos. Every Friday, we show working software. Real features. Real progress. No PowerPoint.

Test as we go. Nothing moves to the next phase without being tested. By real users. With real data.

Document everything. Every decision. Every change. Every workaround. No more tribal knowledge.

Train early. Users see the system weeks before go-live. They practice. They find issues. We fix them.

This phase takes two to four months depending on project size. At the end, you go live. For real this time.

What Makes This Work

Three things make rescue projects succeed:

Leadership commitment. Someone senior has to own the outcome. Make hard calls. Kill sacred cows. Without this, nothing changes.

Brutal honesty. No sugar-coating. No pretending things are fine. If something is broken, we say it. If a decision is wrong, we change it.

Discipline over speed. We don't rush. We don't cut corners. We do it right. This is actually faster than doing it wrong twice.

When To Call For Help

You need a rescue project if:

Your go-live date passed and you're still not live.

Your team is working nights and weekends but nothing improves.

Requirements keep changing and nobody can say no.

Custom code is breaking faster than you can fix it.

Users are threatening to quit if they have to use the new system.

If you see these signs, stop digging. The hole won't get shallower.

We've rescued projects that were six months behind schedule. Twelve months over budget. On their third consulting firm.

It's fixable. But you need to admit it's broken first.

Related Articles

3 Clean ERP Proposal Models That Actually Work

So you know we're on the same page - not with clarity loss risks
Read post