Start with the right question

Insights

Dynamics 365 works, and the people implementing it are usually competent. Almost everything that reads like a late-stage failure — the UAT that finds hundreds of defects, the go-live weekend that runs into Tuesday, the reporting finance refuses to sign — traces back to a handful of choices made in the first six weeks. This is where those choices sit, why they are hard to reverse, and what to settle before you sign anything.

Dynamics 365 is not a bad product, and the engineers on these programmes are not bad engineers. Most of the failing projects I have seen were staffed by capable people working hard on the wrong things. So the useful question is not whether D365 is any good. It is this: which decisions, taken early by people who did not yet know enough to take them, will the rest of the programme spend two years paying for? That framing predicts far more of the outcome than the choice of partner, the size of the budget, or the quality of the code.

Finance & Operations (formerly AX), Business Central (formerly NAV) and the customer engagement apps on Dataverse (formerly CRM) share a brand and very little else. Different data models, different extension languages, different release mechanics, different licensing, different operational obligations once live. X++ with a build-and-deploy package pipeline on one side, AL extensions and a much lighter footprint on the other, plugins and Power Platform with a wholly different security model on the third.

Both ERP options demo well, which is the problem. A mid-sized distributor is shown Business Central and it looks clean and quick, because it is. Then multi-entity consolidation, process manufacturing or serious warehouse management arrives in month five and fit stops being a configuration conversation. The reverse happens too: a company with no appetite for environment tiers, deployable packages and release management buys Finance & Operations and finds it has taken on the ceremony of an enterprise platform to run forty users.

Choosing wrong is not something you correct with configuration. It is a different project, restarted, with the sunk cost argued over in a steering committee.

Some choices are cheap to revisit and some are effectively permanent, and teams routinely spend their design energy in inverse proportion to that. The permanent ones are permanent because they get written into posted transactions.

Write the irreversible list down in week one and give it the design time, with product knowledge and industry knowledge in the same room. Then stop arguing about the reversible things, which is most of the rest. A report layout, an approval route or a posting profile can be changed on a Tuesday afternoon after go-live.

Both ERP products moved away from letting you modify the base application. Finance & Operations replaced overlayering with an extension model: table and form extensions, event handlers, Chain of Command. Business Central made the same move to AL extensions. This is the right architecture, and it is the only reason continuous updates are survivable at all.

It also changes the economics of a gap, and estimates written with AX or NAV instincts get this wrong. The pattern is consistent. A requirement is priced as if standard logic could be edited. The developer then finds there is no event at the point where the behaviour must change, and the workaround is to reimplement a slice of standard functionality alongside it. That slice is now yours: you own it, you retest it against every update, and it will drift from the behaviour it shadows.

So for each gap the question is not "can this be done". It is "what do we own afterwards, and who tests it in eighteen months".

You no longer decide when you upgrade. Microsoft ships service updates on its own cadence, with major release waves through the year. You can defer an individual update within limits, but you cannot opt out, and the deferral rules have changed more than once. Treat the specifics as something to check rather than remember.

The consequence is structural. Regression testing is not a phase that ends at go-live, it is a permanent cost of running the system. Either you automate it or you do it by hand several times a year for the life of the estate. The tooling is workable rather than delightful: the task-recorder-driven regression suite for Finance & Operations is brittle when forms change and needs real maintenance, and Business Central's test codeunits are genuinely good if anyone writes them. Both beat the manual alternative, and both need a named owner.

Third-party solutions are the sharp edge. Every ISV in your stack must support the version you are being moved to, on a clock you do not control, and one lagging vendor can hold the whole estate. Ask about their release history before you sign with them, not when you are already blocked.

The tooling is rarely the binding constraint. The data-entity framework is fine for configuration and moderate volumes and struggles with large transactional loads, at which point you are writing to staging tables and doing set-based work, which is development nobody scoped. Annoying, but predictable.

The unpredictable part is your legacy data, and you will not know its real condition until you try to load it. Duplicate customers that were never duplicates in practice because a human recognised them. Addresses in the wrong fields. Items with no costing. Purchase orders left open in 2017 that nobody wants to be the one to close.

The decision that most changes the schedule is how much history to bring. Balances plus a read-only archive of the old system is usually right. "Migrate everything" buys reconciliation work, database volume that is a recurring cost rather than one-off effort, and history whose meaning does not match the new model. There is no honest general rule for how far back to go: it depends on your audit and warranty obligations, and someone in finance has to own the call.

Whatever you choose, budget the reconciliation explicitly and name a signatory. Subledger to general ledger, inventory quantity and value, open receivables and payables ageing, at a stated cut date. If nobody has signed it, the migration is not finished, whatever the plan says.

A development environment is a single box. The higher sandbox tiers resemble production architecturally but hold a fraction of its data and none of its concurrency. A green integration test in a sandbox tells you the interface functions. It says nothing about whether it will keep up.

Three things then bite. The data APIs are throttled, so an integration that polls aggressively and behaved at test volume gets shaped when it matters. Master-data synchronisation between Finance & Operations and Dataverse is unforgiving of partial failure, so design the error path before the happy path: rows will fail, and a human must see that queue. And custom code that loops row by row, filters without the company and partition columns, or adds custom fields with no supporting index only reveals itself under real concurrency and month-end batch load.

Before go-live, insist on one number: peak business documents per hour including retries, and where it was measured. If nobody can produce it, the integration has been demonstrated, not tested.

This is an opinion, held firmly. The largest cost driver on these programmes is the absence of a process owner with authority to change how the business works. Run as an IT project, every gap becomes code, because writing a customisation is politically cheaper than telling a department its twenty-year-old workaround is going away. No amount of engineering rescues that.

Its companion is workshop theatre. Standard process is demonstrated on clean demonstration data, everyone nods, and nobody walks a part-shipped order for a customer on credit hold with an intercompany drop-ship and a return that revalues stock. Those are not edge cases, they are the business, and they surface in user acceptance testing, which is the most expensive place to find them.

One more piece of honesty worth putting on the table early: a few days after go-live, rollback is fiction. The documented fallback will not be executed and everyone senior quietly knows it. Saying that out loud during planning is what makes the go/no-go criteria get taken seriously.

Four things, before the contract is signed rather than after. Name the irreversible decisions and give them the design time. Put one accountable process owner in place who can actually change how the business works. Get the legacy data assessed before anyone fixes a migration price. Fund the operate phase explicitly, with regression testing, ISV compatibility, environment refreshes and a named owner of the update calendar. Then walk your three ugliest real transactions end to end in a configured system before you commit to a go-live date: your worst order, your strangest intercompany flow, your most awkward return. Not standard process on sample data. If that cannot be arranged, you have learned something useful about the engagement.

Talk to us about this