Plants had operational data, but much of it was isolated. Equipment systems, historians, SCADA platforms, MES applications, quality systems, and ERP environments often operated in separate layers, each with their own data silos. Leaders wanted real-time visibility, but the business could not always see what was happening on the shopfloor in a way that was timely, contextual, wholistic or useful.

MII helped close that gap. It gave manufacturers a practical way to connect operational data with business context. It supported dashboards, alerts, reports, plant information models, production visibility, performance monitoring, and shopfloor-to-ERP integration. For many organizations, it became the bridge that made manufacturing intelligence possible before “smart manufacturing” became a standard phrase.

That legacy deserves respect. MII helped many companies move from disconnected reporting toward a more integrated view of operations. Your original draft captures that historical role well: MII was not just middleware; it became a digital spine for many manufacturing environments.

But that same legacy now creates a difficult question.

If MII has become part of the manufacturing central nervous system, what happens when the architecture around it is no longer where SAP is investing for the future?

The challenge with MII is not that it failed. In many companies, it succeeded so deeply that it became embedded in how plants operate.

Over the years, manufacturers used MII to solve practical problems. They created custom dashboards for supervisors. They built logic to reconcile production events. They connected equipment and historians to ERP. They supported OEE reporting, production confirmations, genealogy, quality visibility, energy monitoring, and plant-specific workflows. Some of these capabilities were designed centrally. Others grew locally, plant by plant, as operations teams found ways to make the system fit the reality of production.

That is where complexity begins.

An MII environment is rarely just a clean technical landscape. It often contains years of accumulated business logic, local rules, custom transactions, interface decisions, reporting assumptions, and operational workarounds. Some of that logic is still critical. Some is obsolete. Some duplicates functionality that now exists elsewhere. Some may be compensating for old process gaps that no one has revisited in years.

This is why the move from MII to SAP Digital Manufacturing cannot be treated as a simple replacement project.

The first question is not, “How do we migrate everything?”

The better question is, “What is MII really doing for our plants today, and what should the future execution model look like?”

That distinction is important. A manufacturer that simply recreates its MII landscape in a new environment may preserve continuity but also preserve unnecessary complexity. A manufacturer that takes time to understand what has been built, why it exists, and whether it still serves the business has a chance to simplify, standardize, and modernize manufacturing execution in a more meaningful way.

The urgency around MII is often discussed through support dates. SAP community architecture guidance states that SAP ME 15.5 and SAP MII 15.5 are the latest releases, with mainstream maintenance ending in 2027, extended maintenance available until 2030, and no plans for further releases. (SAP Community)

Those dates are important, but they can also create the wrong behavior.

When organizations hear “2030,” it can sound far away. In manufacturing terms, it is not. A serious transition from MII to Digital Manufacturing requires much more than a technical cutover. Companies need time to inventory existing applications, understand custom logic, assess integrations, evaluate site-by-site variation, define future-state processes, align IT and operations, plan validation where required, train users, and protect production continuity while change is happening.

The risk is not only that support eventually ends. The bigger risk is that companies wait until the timeline forces them into a rushed migration.

Rushed migrations tend to carry forward old decisions because there is no time to challenge them. Custom logic gets rebuilt because no one can confirm whether it is still needed. Reports are preserved because someone might use them. Site-specific differences remain because standardization feels too risky under deadline pressure. The result may be technically functional, not “fit to standard” and strategically disappointing.

That is why MII owners should start planning before the timeline becomes urgent. The best transition work happens when there is still enough time to make thoughtful decisions.

SAP Digital Manufacturing is not simply the next version of MII. It reflects a different direction for manufacturing execution.

SAP describes SAP Digital Manufacturing as a cloud MES that supports manufacturing operations management with near real-time data and analytics. (SAP) SAP’s help documentation also describes manufacturing execution capabilities through apps and PODs used to support production execution. (SAP Help Portal)

That shift matters because manufacturers are no longer only trying to connect plant data to ERP. They are trying to create more consistent execution across sites, improve plant-floor visibility, reduce local technical debt, and build a foundation that can support change more easily.

MII often helped manufacturers make fragmented environments more intelligent. Digital Manufacturing asks a broader question: how should manufacturing execution be structured so plants can operate with more consistency, scalability, and visibility from the start?

This is where the migration conversation becomes more strategic. Moving toward SAP Digital Manufacturing gives organizations an opportunity to revisit production execution, operator workflows, quality processes, performance visibility, resource orchestration, genealogy, and integration with enterprise processes. It also creates a moment to decide which local variations are truly valuable and which ones exist only because the legacy landscape allowed them to grow.

That does not mean every process should be forced into a generic template. Manufacturing is too complex for that. Plants have real differences in products, equipment, regulatory requirements, production models, and operating constraints. But there is a difference between meaningful operational variation and unmanaged technical debt.

A well-planned transition helps leaders separate the two.

One of the reasons MII transitions are difficult is that existing environments often continue to run. There may be no immediate crisis. Dashboards still load. Interfaces still move data. Operators still follow familiar routines. Reports still reach the people who expect them.

That can make inaction feel safe.

But legacy risk usually builds gradually. Knowledge becomes concentrated in fewer people. Custom code becomes harder to support. Interfaces become harder to change. New business requirements take longer to absorb. Security and compliance questions become more difficult. Younger teams may have less experience with the underlying stack. Eventually, the organization can still operate the environment, but its ability to confidently evolve the environment begins to decline.

For manufacturing leaders, that is the real issue. Plants do not only need systems that keep running. They need execution environments that can support change without destabilizing operations.

This is why the migration discussion should not be owned by IT alone. MII often touches production, quality, maintenance, planning, inventory, and performance management. The people who understand how the plant actually works need to be part of deciding what comes next.

The transition to Digital Manufacturing is not just about technology modernization. It is about protecting the operational knowledge embedded in MII while avoiding the mistake of carrying forward every old workaround.

Many organizations are tempted to begin by comparing functions: what exists in MII, what exists in Digital Manufacturing, and what needs to be rebuilt. That comparison is necessary, but it should not be the first move.

The better first step is discovery.

A serious discovery effort looks at the current MII landscape from both a technical and operational perspective. It identifies which applications are business-critical, which integrations support production continuity, which reports are actively used, which logic is redundant, and which customizations exist because of old process decisions. It also examines how different plants use MII differently, because the same platform can play very different roles across a manufacturing network.

This work often reveals uncomfortable truths. Some capabilities that appear essential are only essential because the underlying process is unclear. Some reports are widely distributed but rarely used for decisions. Some custom logic exists because a temporary workaround became permanent. Some plant-specific variations create value, while others only make support harder.

That is why migration planning should not be reduced to a technical inventory. The point is not only to document what exists. The point is to understand what the business needs from manufacturing execution going forward to achieve a Smart Factory with Operational Intelligence.

This is where RTS brings a different kind of value.

RTS has worked in manufacturing environments since 1992 and has supported more than 3,000 projects across industrial organizations. The previous RTS Industry 4.0 article positioned the firm around a principle that plant leaders recognize immediately: the shopfloor grades execution, not the sales pitch. That principle matters especially in an MII-to-Digital Manufacturing transition, because the real challenge is not only understanding SAP architecture. It is understanding how production actually runs.

RTS understands the legacy side of the equation: MII landscapes with custom logic, PCo connections, plant-specific dashboards, ERP interfaces, OEE structures, quality workflows, and years of operational decisions embedded into the system. It also understands the future direction: SAP Digital Manufacturing as a more modern execution foundation for visibility, standardization, analytics, and scalable manufacturing operations.

The value is in helping manufacturers bridge those worlds carefully.

That means assessing the current MII environment, identifying what is critical, determining what should be redesigned rather than migrated, defining a practical Digital Manufacturing roadmap, and aligning IT and operations around a transition that protects production continuity. It also means challenging the assumption that every piece of legacy logic deserves to survive.

A good migration preserves operational knowledge. A great migration turns that knowledge into a cleaner, more scalable execution model.

SAP MII played an important role in the history of manufacturing intelligence. It helped manufacturers connect the plant to the enterprise and gave leaders visibility they did not have before. But the next chapter requires more than preserving that legacy.

For MII owners, the right time to start is not when the deadline feels close. It is while there is still enough time to understand the current landscape, make better decisions, and shape the future of manufacturing execution deliberately.

Because once the clock becomes the main driver, the project stops being strategic.

It becomes a race.