If you run Dynamics 365 SCM on-premises, do you have a…

If you run Dynamics 365 SCM on-premises, do you have a supported MRP engine?

You have a running one — an MRP (material requirements planning) engine. It calculates, it produces planned orders, and nobody is going to switch it off. What you do not have is a single Microsoft answer about what stands behind it — three of Microsoft's own pages describe the support position differently, and the gap between the mildest and the harshest wording is the whole risk.

This is a risk brief, not an alarm. The fact, the wordings, and what each honest option costs.

Fact one: the new engine is cloud only

Master planning in Supply Chain Management is now delivered by an external service. Microsoft states it plainly on the master planning system architecture page: "In Supply Chain Management, the Planning Optimization Add-in for Microsoft Dynamics 365 Supply Chain Management manages master planning." Planning Optimization is [GA] — generally available, shipped, supported.

It is also not available to you. Three sentences, three Microsoft pages, same direction:

**Get started with master planning — Note box under Availability** — "Planning Optimization doesn't support on-premises deployments of Dynamics 365 Supply Chain Management." (source)
**Removed or deprecated features — manufacturing entry, Deployment option** — "Cloud only. Planning Optimization is not supported with on-premises deployments." (source)
**Removed or deprecated features — distribution entry, Deployment option** — "Cloud only. Planning Optimization isn't supported for on-premises deployments." (source)

The same Get started page lists prerequisites that close the door a second time: "You must be running Supply Chain Management on a Lifecycle Services enabled high-availability environment, tier 2 or higher (not a OneBox environment), with Dynamics 365 Supply Chain Management version 10.0.23 or later." An on-premises deployment runs on Service Fabric standalone clusters in your own data centre — Microsoft's on-premises deployment overview adds that it "isn't supported on any public cloud infrastructure, including Microsoft Azure Cloud services."

So the engine you run is the other one: the deprecated master planning engine [DEPR], which is Microsoft's own name for it.

Fact two: three Microsoft pages define its support three ways

This is the part worth printing. Each row is verbatim.

**Removed or deprecated features (updated 2026-06-24)** — "as of March 2023, Microsoft has now fully discontinued all support for the built-in master planning engine for all types of deployments. Hereafter, Microsoft will only provide support for critical blocking issues (which result in no planned orders being created or the continuous failure of built-in master planning)." (source)
**Migration to Planning Optimization (updated 2026-03-26)** — "Support is provided only for blocking problems (where master planning doesn't create any planned orders and/or continuously fails) and for regressions in the functionality." (source)
**Deprecated master planning overview (updated 2026-05-01)** — "The deprecated master planning engine has been deprecated for a long time and receives no support from Microsoft. There are no bug fixes, no new features, and no investment in the engine going forward. Customers who continue to use it do so entirely at their own risk." (source)

Read the middle row against the third. One promises fixes for blocking problems and regressions; the next says there are "no bug fixes" at all. Those are not the same commitment, and we are not going to tell you which one a support ticket will meet — that is Microsoft's to reconcile, and the honest move is to raise it with your account team rather than to guess.

Two more sentences matter and are not in dispute. The migration page names who the March 2023 policy binds: "These conditions apply to all customers, including the following types:… All on-premises customers." And the overview page settles the removal question: "There's currently no timeline for the full removal of the deprecated master planning engine from Supply Chain Management. Microsoft isn't currently planning to remove it." Currently is Microsoft's word, twice. If Microsoft changes its mind, the same page commits to announcing "at least 12 months before the removal date."

What Microsoft asks on-premises customers to do: nothing

This is the trap, and it is a quiet one. The migration page's FAQ:

"**My environment is on-premises. Do I need an exception to continue using the deprecated master

planning engine?** No. An exception isn't required for on-premises environments. You can continue to

use the deprecated master planning engine. Your environment admin is informed if any action is

required."

The same page opens with "This change affects all cloud environments. On-premises installations aren't affected." A cloud customer gets a dialog in the product, a system-driven exception process and a prompt each time they run planning. An on-premises customer gets silence unless Microsoft decides action is required. Nothing routine in the application tells a planner that the engine behind the numbers stopped receiving investment years ago.

That is why this reads as fine internally right up to the moment someone asks the question in a board pack. The absence of a prompt is not evidence of a supported engine — it is evidence that Microsoft has no migration to ask you for.

The version line that does not resolve cleanly

The overview page adds a restriction: "Starting in Supply Chain Management version 10.0.41, the deprecated master planning engine is blocked for all new deployments." The migration page says the same in its New deployments section, one paragraph after qualifying it — "you must use it for all new cloud deployments" — then drops the qualifier.

Our reading is that the block is a cloud control, because the same page exempts on-premises environments from the exception process entirely and the product cannot install the add-in on-premises in the first place. That reading is ours, not a Microsoft statement, and it is exactly the kind of sentence to confirm in writing before a new on-premises legal entity goes live.

Three options, and what each actually costs

**Stay on the deprecated engine** — What it costs: Nothing to build. You accept whichever of the three support definitions applies, and a feature gap that widens monthly — Planning Optimization is updated monthly per its release history, while the deprecated engine gets "no new features" · What it does not fix: Nothing. It is a decision to hold the position, which is legitimate if it is written down
**Move the deployment to cloud** — What it costs: An ERP programme, not a planning project — plus Planning Optimization's own prerequisites: tier 2 or higher, Lifecycle Services enabled, version 10.0.23 or later, and one of the Azure geographies Microsoft lists · What it does not fix: The planning policy. A faster engine executes a bad coverage policy faster
**Optimize the policy outside the engine** — What it costs: An integration and a model. Reads the demand and supply history you already hold, computes the coverage and buffer decisions, and writes them back as master data the engine consumes · What it does not fix: Support status. This does not give you a supported engine — it improves what the engine you have is told to do

Option three is our territory and we will state its limit before its value: it changes the inputs, not the runtime. Anyone who tells an on-premises manufacturer that a companion app resolves the engine question is selling something.

Where we would draw the line

We would not build against the deprecated engine's extensibility surface. Microsoft has published no removal date and also no investment, and code written against an engine with no forward development is a liability you pay for at every upgrade.

We would not let a Demand & Inventory Optimizer be presented as an answer to the support question. It optimizes safety stock and coverage policy; it does not change who fixes the engine.

And we would not put the deployment decision inside a planning workstream. Moving on-premises Supply Chain Management to cloud is a programme with security, integration and data-residency owners. The planning engine is one input to that business case — a real one, but one.

What to do this week

Open Master planning > Setup > Planning Optimization parameters and record the Connection status value for each legal entity. On-premises it will not be Connected; capture that as a fact rather than an assumption.
Put the three quoted support definitions above in front of whoever owns the ERP risk register, with their URLs. It is a five-minute agenda item and it is the whole point of this article.
Check your on-premises version against Microsoft's servicing policy: "Microsoft supports your deployment of Finance + Operations (on-premises) software only if you keep the deployed software current according to this policy" (source). A stale platform version compounds this.
Ask your implementation partner and your Microsoft account team, in writing, which of the three support definitions governs a ticket you raise tomorrow. Keep the answer.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are inside the on-premises planning decision, book a fifteen-minute call and we will walk the options and the policy layer with you on your own estate — no deck. https://cognilium.ai

If you run Dynamics 365 SCM on-premises, do you have a supported MRP engine?