The Bottom Line
A stalled Dynamics 365 project has three options: start again, trust the build as it stands, or validate what exists. Validation means testing the build against the original requirements, then deciding what to keep. The third option usually wins, because it replaces opinion with evidence. Panorama Consulting Group , an ERP consultancy independent of software vendors, reports more organisations seeking project audits year on year. Its clients use them to reassess a project without a full recovery or restart. Three checks decide the call. Do the requirements still exist? Does each customisation still have a reason? Does the build still sit on supported features?
Where the Decision Sits
Rescue when most of the build still matches the requirements process by process and rests on supported features. Restart when the build and the requirements disagree on most of what matters, or when the foundation is no longer supported. The checks below sort the build into keep, fix or rebuild before anyone commits to either path.
-
Start With the Requirements, Because Everything Else Is Opinion
Without a baseline, validation has nothing to compare against. The original requirements document is that baseline, even an old one. Walk the build against it process by process, and you see exactly where it matches and where it does not. In 2014, the Project Management Institute found the same weakness at scale. Its survey of more than 2,000 practitioners found that nearly half of unsuccessful projects miss their goals because of poor requirements management. It also estimates that 5.1 percent of every project dollar is wasted on it. Microsoft’s guidance gives the method. Its testing strategy says to connect each test case to the business process it validates. That helps teams track, report and sign-off on readiness. User acceptance testing is the last test before production and a prerequisite for go-live. If the document is gone, Microsoft’s business process catalog offers a starting point. It lists the standard business processes Dynamics 365 supports, so a team can rebuild a baseline
from what the business does today.
-
Trace Every Customisation to a Reason
Stalled builds collect customisations that nobody has questioned in years. Some meet genuine requirements. Others work around a limitation Microsoft has since removed, or a process the business no longer runs. This is the customisation trap: each one was reasonable when it was built, and together they make the system hard to test, secure and maintain. Independent research shows where the cost lands. In Panorama’s 2026 report, the most common reason for going over budget was an unexpected need for additional technology. Organisations discover misfits late, then turn to additional technology, scope expansion and custom builds. McKinsey’s survey of 50 CIOs adds the long-term cost. They estimated tech debt at 20 to 40 percent of the value of their technology estate. Microsoft’s fit-to-standard guidance names the same risk. When a team evaluates a customisation, it says to weigh the potential redundancy as new Dynamics 365 features might cover the need. It recommends starting every project with a fit-to-standard analysis. In a rescue, that becomes a simple triage. Mark each customisation as required, replaced by standard functionality, or obsolete. Every item that drops off the list is one less thing to test, secure and maintain.
-
Check the Build Against the Platform as It Is Today
Code and configuration started years ago can rest on features Microsoft has since marked for removal. A deprecated feature keeps working and stays supported until it is removed. It is no longer in active development, and notices can span months or years. That is how a quiet system can carry a hidden deadline. Microsoft publishes a deprecation list for each app, including Sales, Customer Service, Field Service, Finance and Supply Chain Management. The Customer Service list, for example, includes standard SLAs, the standalone Customer Service Insights app and the legacy workspace layout . A build reviewed once at go-live and never again has not been checked against any of it. The Panorama report adds a governance warning for cloud platforms. Frequent updates and evolving functionality need clear ownership and oversight. Without it, post-go-live friction can escalate quickly. This is also where the lift-and-shift trap appears. Copying an unreviewed build into a new platform under deadline pressure carries the same problems forward. Checking platform currency early keeps a rescue from quietly becoming that.
-
Go Live in Phases and Park the Big Changes
A rescue that tries to fix everything before go-live stalls for the same reason the original did. Split the work by business process. Take each one live on its own. Fix minor gaps in that release, and log major gaps as change requests for after go-live, so they cannot hold up the first release.
Panorama’s survey shows what usually stalls a go-live. Of the organisations that ran late, the most common reason was organisational issues. These include governance, resistance to change and process redesign, and they show up as delayed signoffs. Parking major changes keeps those debates out of the first release.
Data shapes how smooth that is. Microsoft says the people most familiar with the data should lead the cleansing . It also says to rehearse the cutover several times in a test environment . Its testing checklist adds end-to-end testing with increasingly realistic, migrated data.
How Microsoft’s Guidance and Independent Research Meet These Risks
The same four risks appear in both, and each is cited in the section above.
- No baseline: Microsoft’s business process catalog and requirement-linked test cases, and PMI’s finding on requirements.
- Customisation drift: Microsoft’s fit-gap analysis, and Panorama’s finding on misfits found late.
- Platform drift: Microsoft’s deprecation lists, and Panorama’s warning on governance.
- A go-live that slips: acceptance testing as the final gate, and Panorama’s finding on organisational delays.
A Five-Question Self-Audit
Answer these before any rescue or restart conversation. They take an afternoon, and they show where the build stands.
- Does the original requirements document, or the closest equivalent, still exist?
- Can every customisation be traced to a named business reason?
- Has the build been checked against the current deprecation list for each app it uses?
- Did the build ever clear user acceptance testing, with test cases tied to requirements?
- Has the data migration been tested on realistic data, with a rehearsed cutover?
Three yes answers to the first three questions point to a rescue worth validating in full. Two or more no answers mean the first job is rebuilding the baseline, before anyone chooses between rescue and restart. Start this week with question one: find the requirements document, or the closest thing to it.
What This Looks Like in Practice
In a takeover we led for a mid-market manufacturing client, the previous vendor had left, nothing was documented, and the build had never been signed off. The one reliable document was the original requirements. We walked the build against it process by process and logged every difference as minor or major. Then we took the business processes live one at a time. Major changes went on a list for after go-live, so they could not stall the first release.
What This Means for You
If most of the build holds up, a rescue spares the cost of rebuilding what already works. If most of it does not, validate against what the business does today before choosing. Either way the order is the same: baseline first, customisations second, platform currency third, phases last. Doing that before a rebuild starts avoids paying twice for the same mistakes. See how our Microsoft Dynamics 365 consulting and Microsoft implementation services work.
