Symptoms of a project in trouble
- βThe go-live date has moved more than once and nobody can say what the new date depends on
- βTest scripts pass in demos but fail when your staff run them with real documents
- βData migration has been attempted several times and balances still do not agree
- βCustom extensions keep growing, and nobody has asked whether standard features would do
- βChange requests arrive faster than decisions, and the budget is spent on rework
- βYour team has quietly gone back to the old system or to spreadsheets
The rescue review, step by step
- 1
Secure access and documents
With your admin's permission we get read access to the Business Central environments, the source code repository, the contract, the statement of work and the issue log. Nothing is changed during the review.
- 2
Compare scope with reality
Every promised requirement is checked against what is configured, built and tested. The gaps are listed plainly, including the ones that were never in the contract but everyone assumed.
- 3
Test the foundations
Chart of accounts, dimensions, posting groups, costing method and data migration mappings are examined, because problems there spread into everything built on top.
- 4
Read the code
Custom AL extensions are checked for upgrade safety, test coverage and whether each one is still needed. Code written against Microsoft's rules is kept; code that fights the product is flagged.
- 5
Write the recovery plan
You receive a triage report and a plan: what to keep, what to fix, what to drop, the decisions you must make, and the criteria that must be met before go-live.

Recover, reset or restart
What we will not do
We will not blame the previous partner in writing for the sake of it. The report describes facts in the system and the documents, which is far more useful to you if a commercial conversation with that partner follows.
We will not recommend a restart to win more work. Most stalled projects can be recovered by narrowing scope and fixing a handful of foundations. A restart is recommended only when the design underneath cannot carry your business, and the report explains why in terms your board can follow.
Implementation rescue questions
Can you step in while our current partner is still engaged?
Yes. A review can run alongside the current partner, and sometimes that is the best route, because the findings give both sides a shared list to work from. We will want read access and cooperation on documents, and we keep our findings factual. Whether you continue with the current partner is your decision.
What if we want to change partner completely?
Business Central online lets the customer change the partner of record and remove the old partner's delegated access through admin settings. Your environments, data and extensions stay in your tenant. What you must secure early is the source code for any custom extensions, which should be in a repository you can access.
Our data migration keeps failing. Where do you start?
With the reconciliation, not the tool. We compare the trial balance, open customer and vendor items and inventory values between the old system and a test migration, and trace every difference back to a mapping or a data problem. Once the differences are explained, the fixes are usually straightforward.
Will we have to redo user testing?
Only for the parts that change. The recovery plan identifies which tested areas are still valid and which need retesting because configuration or code moved underneath them. Keeping users' trust matters, so retests are focused and scheduled with their workload in mind.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
