For SAP MII | PCO users
The end of support for SAP MII and SAP PCO is usually treated as an application problem. It is not: it is an integration problem. This page covers the real timeline, what is genuinely at risk, and the paths available — including the one that does not lead to SAP DM.
Full SAP support. The best moment to assess and plan without pressure.
31/12/2027: the last date with mainstream maintenance included in the contract.
Support only through Extended Maintenance, contracted separately.
A migration programme takes one to three years. Starting here is tight.
31/12/2030: no fixes, no security patches, no standard support.
Dates per SAP public communications on SAP MII end of life. Confirm the timeline that applies to your contract with SAP before planning.
What is at stake
When the conversation about leaving SAP MII starts, it usually starts with the web applications — the screens operators use. They are visible, everyone has an opinion about them, and so they become the centre of the project. But anyone who has maintained an SAP MII environment for years knows the hard part sits underneath: the transactions that talk to the ERP, the loops that read the PLC, the queues that hold production when SAP does not answer.
Those integrations are rarely documented in one place. They were built over years, by different teams, and much of what is known about them lives with people rather than on paper. That body of work is what the end of support puts at risk, and it is what takes longest to rebuild — not the interface.
Replacing the integration layer before touching the screens inverts the risk order of the project: the unsupported platform goes first, and the front-end decision comes later, without a deadline pressing on it.
Decision
There is no single answer — there is the answer that fits your risk, your budget and your calendar. The five paths that show up in practice:
Low cost now, rising risk later.
Nothing stops working on 31/12/2027. What ends is defect correction, security patching and contracted support. For a plant running around the clock, operating an integration layer with no security fixes is a decision that belongs with the risk function, not only with IT.
Right for those who want an MES. Not everyone does.
SAP Digital Manufacturing is an MES on SAP BTP, with recurring cost and an implementation project of its own. For those who used SAP MII as an MES, it is a natural succession. For those who used SAP MII as an integration layer — which is most — it means buying a different category of product to solve the problem at hand.
Solves the deadline first and preserves what works.
Integrations with SAP and with the shop floor move off SAP MII and onto a supported platform, keeping the same BAPIs, the same IDocs and the same equipment on the other end. The screens stay up while you decide what to do with them. This is the path CMS was built for.
Leaves SAP MII entirely, inheriting none of the technical debt.
Integration moves to CMS and the web applications built on SAP MII are rebuilt on current technology — decoupled, responsive and under your control. It costs more and takes longer than replacing integration alone, but it closes the matter: nothing is left tied to a third party product lifecycle.
Stays in the SAP ecosystem without outsourcing the shop floor.
The web applications move to SAP BTP and Integration Suite handles integration between corporate systems. CMS covers what Integration Suite does not reach: OPC UA, Modbus, PLCs, historians and the rest of the shop floor. For anyone already committed to BTP, this is the division of labour that avoids forcing an enterprise tool to talk directly to equipment and internal APIs with no integration and control hub in between.
Frequently asked
Mainstream maintenance included in the contract runs until 31/12/2027. After that, support exists only as Extended Maintenance, contracted separately and at additional cost, until 31/12/2030. From 2031 there is no correction, no security patching and no standard support.
No. Nothing is switched off remotely. What ends is the right to defect correction, security patches and support. The environment keeps running — what changes is that any new problem becomes yours alone, with no channel to escalate to.
No. SAP DM is the succession SAP offers, but it is a cloud MES with its own scope and cost. If you use SAP MII as an integration layer between SAP and the shop floor rather than as an MES, CMS is a path that resolves the end of support and brings in a range of current, leading-edge technologies.
You can use both, and that is usually the better arrangement: they solve different layers. Integration Suite is strong at integration between corporate systems, but it does not speak shop floor protocols — there is no OPC UA, no Modbus, no Sparkplug B, no PLC reading and no historian such as AVEVA PI. It does carry MQTT through Advanced Event Mesh, but as a corporate event bus, not as an equipment client. And because it runs in the cloud, putting it on the path between equipment and SAP creates a connectivity dependency production will not accept: when the link drops, the line does not stop producing along with it. CMS sits next to the equipment, speaks those protocols and holds the queue locally until SAP is back. In a BTP architecture, Integration Suite handles the corporate side and CMS handles the plant.
Because that is not what an MES is for. It exists to run and trace production, and that is where the vendor invests. Connectivity usually arrives as an API that receives data: it solves the inbound step, but not what surrounds it — holding the queue when the ERP does not answer, reprocessing only what failed, telling someone at three in the morning that a connection dropped, showing what was inside each message. Without that, a failure surfaces only when production notices. And an MES is rarely sized to keep dozens of connections alive and poll PLC tags in a loop, so every new integration becomes a dependency on the vendor roadmap. CMS takes that layer for any plant system, and the MES goes back to doing what it does well.
Yes, and it is usually the lower-risk path. Legacy screens stay in production while integration moves to a supported platform. The front-end decision waits until later, without the end-of-life deadline forcing it.
SAP Plant Connectivity follows the same movement as SAP MII. It is the component that talks to OPC, PLCs and shop floor equipment, so anyone relying on it for data collection needs it in the same plan — not treated as a separate item.
No. The same BAPIs, RFCs and IDocs are still called, with the same parameters. What changes is who makes the call. The contract with the SAP side is preserved, which is precisely what makes this path shorter than rebuilding everything.
A full migration programme including the front-end varies considerably from one industrial environment to another. We survey your case and come back with an estimate. Replacing only the integration layer is considerably shorter, because the scope is known and does not depend on redesigning the operator experience.
With the inventory. Before choosing a platform you need to know how many integrations exist, what each one does, which system it talks to and who depends on it. In almost every SAP MII environment this exercise surfaces integrations nobody remembered — and it is what defines the real size of the project.
Where to start
Before choosing a platform you need to know what exists. We send you the spreadsheet we use at the start of every migration project: thirteen columns that, in practice, change the decision — each one explained inside the file, with a sample row already filled in.
