The pattern we keep seeing on D365 renewals
Microsoft Dynamics 365 has been the rational ERP choice for a meaningful slice of manufacturers in the region. The Microsoft account team is responsive, the integrator ecosystem is mature, and the bundled relationship with Azure and the Office stack makes the procurement story coherent. None of that is changing.
What is changing is the per-user economics on the manufacturing operations modules. Finance & Operations licensing scales with the operational user count — line operators, planners, shop-floor supervisors — in a way the original business case rarely modelled accurately. By the third renewal, the per-user spend on the operations side often exceeds the per-user spend on finance and admin combined. The CFO question that follows is the question this piece exists to address: what does a phased exit from D365 manufacturing modules actually look like?
We have run versions of this engagement for three manufacturers in the region. The playbook below is the consolidated version.
Decision framework before the build
The framework we run before recommending any build:
Layer one — what is the per-user spend trajectory across the next three renewals? Hold revenue flat, model the licence increases on the published schedule, factor in the typical D365 module upsell pattern. The number you get is the budget envelope for the replacement.
Layer two — which modules are load-bearing for differentiation, and which are commodity? Finance and accounting on D365 is rarely worth replacing for a manufacturer. The modules where ownership pays back are typically production scheduling, quality control, maintenance management, and the bespoke configurations of supply-chain planning that the integrator built on top of the platform anyway.
Layer three — what is the integration surface to the rest of the estate? The D365 instance does not live in isolation. It is connected to the warehouse management, the MES on the shop floor, the customer portal, the BI stack, the procurement platform. A successful migration models the integration surface explicitly before the first line of replacement code.
Layer four — what is the team's appetite for ownership? A REFORGE engagement only works when the receiving team is staffed and motivated to operate the new system. We have walked away from engagements where the appetite was not there. The integrator can sell you a working system; we cannot sell you a maintenance organisation.
The three patterns we see
Pattern one — production scheduling first. The production scheduling module is often the highest-friction, highest-customisation surface in a manufacturer's D365 estate. It is also one of the easiest to peel off cleanly: the inputs (orders, capacity, materials) are well-defined, the output is a published schedule the rest of the estate consumes, and the underlying optimisation problem benefits enormously from modern AI techniques the vendor module does not exploit. We have seen the production planner role transform from spreadsheet wrangling to schedule curation when the right software lands.
Pattern two — quality and maintenance. Quality control and maintenance management are typically configured workflows that bear the integrator's fingerprint more than Microsoft's product. The configuration is the IP. Migrating the workflow to owned software preserves the IP, removes the per-user cost, and opens the surface to modern computer-vision and predictive-maintenance models that the vendor module is years behind on.
Pattern three — full operations exit. The manufacturer keeps D365 finance and admin and exits the entire operations stack on a 12-to-18 month timeline. This is the largest engagement of the three and the one with the strongest CFO support when the per-user math has compounded for too long. The pattern requires the most rigorous parallel-run discipline.
The migration mechanics
Three mechanics show up in every D365 migration we run.
The parallel-run window. No production-critical workflow goes live on the new system without a parallel-run period against the existing D365 surface. The duration is module-specific — two weeks for production scheduling, six weeks for quality, longer for anything touching the regulatory or audit trail. The parallel run is the artifact the operations team uses to build trust. We treat it as a deliverable, not as a verification step.
The data contract with D365. Every workflow we replace is bounded by a well-defined data contract back to D365. Reads and writes use a single well-versioned surface — typically a small set of API endpoints we own — rather than direct database access. When the migration is complete and D365 retires, the contract is the seam that removes cleanly. When the migration is partial and D365 stays, the contract is the boundary that keeps the two systems honest.
The integration retirement order. The order in which D365-adjacent integrations retire matters. Get it wrong and the replacement system is hostage to a dependency on D365 it cannot break. Get it right and each integration retirement is a small, low-risk move. We map the integration retirement order in week 1 of every engagement.
The AI dimension
Modern manufacturing AI is not a feature you switch on. It is a series of agents that operate against your production data — schedule optimisation, anomaly detection on shop-floor sensors, root-cause analysis on quality incidents, predictive maintenance against equipment telemetry. The vendor modules in D365 expose a fraction of what is possible. Owning the platform unblocks the AI roadmap the operations team has been waiting for.
Our scope on every manufacturing engagement now includes at least one agentic workflow alongside the workflow replacement. The economics of "we are rebuilding this anyway" make the AI investment easier to fund and easier to operate, because the data plumbing is being rebuilt cleanly in the same window.
The saasinator perspective
The case for owning the manufacturing operations stack is not a case against Microsoft. It is a case for matching the cost structure to the value the workflow generates. Finance modules and admin workflows are commodity; renting them is rational. Production scheduling and quality workflows are differentiating; renting them is not.
The manufacturers we work with are not exiting Microsoft. They are deciding which workflows belong inside the Microsoft estate and which workflows belong inside their own platform. The renewal conversations get easier when the answer to "which workflow does this seat support" is clear.
What we tell manufacturing CIOs at renewal time
Pick the operations module where the per-user cost has compounded the most. Run a two-week pilot against a single production line. If the pilot proves the workflow, scale it on a fixed cadence and retire the D365 module on the next renewal. If the pilot does not prove the workflow, you have spent two weeks learning where the friction actually lives — which is its own deliverable.
Book a diagnostic. Bring your last D365 renewal sheet, the operations module breakdown, and a list of the integration points between D365 and the rest of your estate. Ten working days. We tell you which module flips first.