I Just Saved a Client $47K on Their Stalled D365 Project. Here’s Exactly What Was Wrong.

Three months behind schedule. $127K over budget. A team that had lost all confidence in their implementation partner. A CFO who couldn’t sleep at night.

That was the situation when I got the call in March for this D365 project rescue.

By May, we were live. Under the revised budget. With a system that actually worked the way the business needed it to work.

The total savings from fixing what was broken—rather than continuing down the original path? $47,000.

Here’s what was wrong, how we fixed it, and what you should watch for in your own D365 projects.

The Situation When I Arrived

A $2M manufacturing company had hired a mid-tier implementation partner nine months earlier. The original timeline: six months. The original budget: $185K.

When I walked in the door in March, here’s what I found:

Go-live had been pushed back three times
They’d spent $127K more than budgeted
Key modules still weren’t configured
Data migration was a mess
The project team was burned out and demoralized
Their original consultant had been reassigned to another project

The partner’s explanation? “These things happen. D365 is complex. We just need a little more time and budget.”

The CFO didn’t buy it. She brought me in for a second opinion.

What I discovered in my first week wasn’t complexity. It was incompetence masked as complexity.

The Four Critical Problems

Problem 1: Nobody Actually Understood Their Business Processes

The original requirements gathering had been a checkbox exercise. The consultant had used a standard template, asked generic questions, and documented what they heard—without really understanding how this manufacturing company actually operated.

The smoking gun: Their work order process required approval from three different people based on dollar thresholds and customer type. The D365 configuration? A simple two-step approval that didn’t account for their actual business rules.

When I asked to see the documented workflows, I got 50 pages of generic process diagrams that could have applied to any manufacturer. Nothing specific. Nothing that reflected their actual operations.

Cost impact: Requirements had to be re-gathered, workflows reconfigured. Three months of wasted work. Estimated cost: $18K in consulting fees and internal time.

Problem 2: The Data Migration Strategy Was “We’ll Figure It Out Later”

Here’s a direct quote from the project documentation: “Data migration approach TBD.”

Nine months into a project. Six months past the original go-live date. And nobody had a real plan for how to get 15 years of customer, order, and inventory data from their legacy system into D365.

When I dug deeper, I found out why: their legacy system had inconsistent data structures, duplicate records, and no single source of truth for critical information. The implementation partner had looked at it, decided it was too complicated, and… just moved on to other tasks.

The reality: Data migration should have been tackled in month two. By month nine, it had become a crisis that threatened the entire go-live.

Cost impact: Emergency data cleanup, custom migration scripts, extended timeline. Estimated cost: $22K.

Problem 3: Scope Creep Without Scope Management

The original scope document was seven pages. The actual configuration being built? At least double that.

How did this happen? The consultant kept saying “yes” to every request without documenting scope changes, assessing impacts, or adjusting timelines and budgets.

Classic example: Mid-project, the operations team asked for custom reporting dashboards that weren’t in the original scope. The consultant said “sure, we can do that” and spent three weeks building them—never mentioning that this was additional work.

When the CFO questioned the budget overruns, there was no paper trail showing where scope had expanded. Just a lot of “well, they needed this functionality.”

Cost impact: Untracked scope changes, no change orders, no budget adjustments. Estimated cost: $12K in unplanned work.

Problem 4: Junior Consultants Learning on Their Dime

Here’s what really made me angry: The partner had sold them senior-level expertise at $200+/hour rates. What they actually got? Junior consultants who were learning D365 as they went.

I could tell because the configuration was full of rookie mistakes:

Workflows that looped unnecessarily
Security roles that were too permissive
Custom code where standard functionality would have worked
Integrations built the hard way instead of using native connectors

When I asked direct questions about why certain decisions were made, the assigned consultant couldn’t explain the reasoning. Because there wasn’t any. They’d done it the only way they knew how—which wasn’t the right way.

Cost impact: Rework, inefficient solutions, extended timeline. Estimated cost: $15K.

How We Fixed It (And Saved $47K)

Once I understood the problems, the path forward was clear.

Step 1: Stop the Bleeding (Week 1)

First, we halted all work. No more configuration changes. No more “feature additions.” No more scope discussions.

Then I sat down with the CFO and built a realistic assessment:

Here’s what’s actually been built (and what needs to be redone)
Here’s what’s left to do
Here’s how long it will actually take
Here’s what it will actually cost

Her response: “Why didn’t anyone tell me this six months ago?”

Step 2: Right-Size the Scope (Week 2)

We went back to first principles: What does this business actually need to go live?

I worked with their team to separate “must have” from “nice to have.” Turns out, about 30% of what was being built was nice-to-have features that could wait for Phase 2.

The partner’s reaction: “But we’ve already started building those features!”

My response: “And we’re going to stop. Because getting live with 70% functionality that works is better than missing another deadline chasing 100% functionality that doesn’t.”

Step 3: Fix the Data Migration (Weeks 3-4)

I brought in a data migration specialist from my network. Not some junior person learning on the job—someone who had done this 50 times before.

We spent two weeks cleaning data, building proper migration scripts, and testing everything twice. It wasn’t glamorous work, but it was necessary work.

Cost: $8K for the specialist. Value: Not having to re-migrate data three times because it wasn’t done right the first time.

Step 4: Rebuild What Was Broken (Weeks 5-7)

Some things couldn’t be salvaged. The approval workflows, the integration with their shipping system, the custom reporting—all had to be rebuilt correctly.

But here’s the key: We didn’t rebuild everything. Only the things that were truly broken or wouldn’t work at go-live.

Everything else? We documented it as “known issues to address post-launch.” Because getting live and improving was better than staying in perpetual implementation limbo.

Step 5: Get Live (Week 8)

We went live in early May. Not with perfect functionality. But with good-enough functionality that let them start using D365 and stop paying for two systems.

Post-launch: We spent another month fixing issues and adding back some of the Phase 2 features. Total time from when I started: three months. Total additional cost: $31K (instead of the $78K the original partner was projecting).

Net savings: $47K.

The Red Flags You Should Watch For

If you’re in a D365 project right now, here are the warning signs that you’re heading for the same situation:

Red Flag 1: “We’ll figure that out later”

If your consultant keeps deferring difficult decisions—especially around data migration or integrations—you’re in trouble. These issues don’t get easier with time. They get worse.

Red Flag 2: No clear scope documentation

If you can’t point to a document that says “this is in scope, this is not,” you have no way to manage scope creep. Every request becomes a negotiation.

Red Flag 3: Your consultant can’t explain why

When you ask “why did you do it this way?” the answer should be clear and logical. If you get vague responses or technical jargon that doesn’t make sense, that’s a red flag.

Red Flag 4: Constantly changing timelines

One delay happens. Two delays with clear explanations happen. Three+ delays with vague reasons? You don’t have a complexity problem. You have a competence problem.

Red Flag 5: The original consultant disappeared

If the person who sold you the project isn’t the person doing the work—and especially if the person doing the work keeps changing—that’s bait-and-switch. And it rarely ends well.

What This Really Cost Them

Yes, we saved $47K in direct consulting costs. But the real cost was higher:

Nine months of lost productivity using their old system
$127K already wasted on work that had to be redone or abandoned
Team morale damage that took months to repair
Lost confidence in technology investments
Delayed business improvements they were counting on

The financial savings were significant. But the opportunity cost? Much higher.

If This Sounds Familiar

If you’re reading this and thinking “this sounds like my project,” here’s what you should do:

Don’t wait. The longer a troubled project continues, the more expensive it becomes to fix. The sunk cost fallacy keeps people invested in failing projects for months too long.

Get a second opinion. Bring in someone with no financial incentive to tell you everything is fine. Someone who can give you an honest assessment of where you really are.

Be willing to make hard decisions. Sometimes that means pausing work. Sometimes it means changing partners. Sometimes it means cutting scope to get live and iterating from there.

Focus on outcomes, not activities. Don’t measure progress by how busy your consultant seems or how many meetings you’re having. Measure it by: Are we getting closer to a working system that delivers business value?

The Happy Ending

Today, that manufacturing company is running on D365. Their order processing time is down 40%. Their inventory accuracy is up. Their month-end close went from 10 days to 3 days.

The CFO sleeps at night.

And when they needed help with Phase 2, they knew who to call.

Ready to Discuss Your D365 Project?

Whether you’re dealing with a stalled project, planning a new implementation, or just want a second opinion on your current approach, let’s talk.

I offer free 30-minute project health assessments where we’ll discuss:

What’s working and what’s not
Whether your project can be saved
What your realistic options are

No pressure. No obligation. Just honest feedback from someone who’s seen this movie before.

Schedule Your Free Project Health Assessment

📅 Book a 30-Minute Call

Or email me directly: john@magneticd365.com

About the Author

John Panico is one of the founders of Magnetic D365, specializing in D365 project management and rescue services for small and mid-size businesses.

With 20+ years of D365 project management experience and having led or rescued 20+ implementations across manufacturing, distribution, and professional services, [Your Name] brings senior-level D365 project management expertise and honest guidance to growing businesses who deserve better than the bait-and-switch staffing models of big consulting firms.

Connect: LinkedIn ||Schedule a call | Send Email

The Question I Ask Every New D365 Client (And Why Their Answer Determines Everything)
The Q1 D365 Readiness Assessment: 5 Questions Every CFO Should Ask
Coming soon: “Before You Kick Off That Q1 D365 Project: The 2-Week Diagnostic”

I Just Saved a Client $47K on Their Stalled D365 Project. Here’s Exactly What Was Wrong