This is the first blog post on the SAP ME Reset Window blog series, written by João Roque, architect and advocate for automation and connectivity at Critical Manufacturing.
I want to talk about something that comes up in almost every conversation I have with manufacturing leaders running SAP ME. Not the end-of-life timeline. Not the SAP DM roadmap. Something more uncomfortable.
Most SAP ME customers may not be able to accurately describe their own implementation.
I don’t mean they don’t know they run SAP ME. They know that. I mean that if you ask them to list every piece of custom logic that has been added to their system over the past ten or fifteen years, they cannot do it. Not completely. Not accurately. And in many cases, not at all.
This matters now more than it ever has, because every one of these customers faces a forced reimplementation:
- SAP has confirmed that mainstream maintenance for ME and MII ends in December 2027
- Extended support, at a premium, runs until 2030. There is no upgrade path to SAP Digital Manufacturing.
- The transition is a full reimplementation on a new platform, regardless of destination.
You cannot plan a reimplementation of something you cannot inventory.
Where the Custom Logic Hides
SAP ME was designed to be extended. That was one of its strengths. The platform provided a Java SDK with a powerful mechanism called Activity Hooks: Java classes that intercept standard transactions (Start, Complete, Split, Merge, NC Log, and dozens of others) at defined execution points. You could write code that executed before, after, or instead of any standard operation.
Over the years, most SAP ME customers accumulated dozens, sometimes hundreds, of these hooks. They enforce business rules, call external systems, modify transaction behavior, write to custom data stores, and abort operations conditionally.
They are registered in the ME administration interface, but the registry only tells you that a hook exists and where it executes. It does not tell you what it does or what it is for or even how it relates to the rest of the system. Understanding that requires reading the Java source code.
Here is the uncomfortable question: how many Activity Hooks do you have in production right now? And can you show me the source code for each one?
In my experience, the answer to the first question is often “I’m not sure.” The answer to the second is frequently worse: the source code exists somewhere, but it was written by:
- A consultant who left three years ago
- An internal developer who has moved on
- An SI partner whose engagement ended.
The code is there, deployed and running, shaping production behavior every day. But nobody in the organization can fully explain what all of it does.
Of course, this is not always how things begin. The initial implementation may have been carried out by an excellent core team that documented their decisions thoroughly and provided valuable business context. At go-live, the solution may have been well understood and easy to maintain. The challenge emerges over time. By the tenth patch, enhancement, or small feature request, much of that context has been lost. The original team has dispersed, documentation has fallen out of date, and each incremental change has added another layer of complexity. Eventually, the organization finds itself in the uncomfortable position of trying to understand not just how the system should behave, but what it is actually running.
You can probably guess what becomes the basis for future estimates. Rather than investing the significant time required to reverse engineer the current production system and understand years of accumulated changes, estimations rely on the original implementation artifacts, the customization as it existed on day one, not on day thousand. It is the only version that is reasonably understandable. As a result, estimates are often based on an idealized system that no longer exists, while the actual implementation has evolved through countless undocumented patches, enhancements, and fixes.
The Custom Data Problem
It gets deeper. SAP ME allows you to attach custom data fields to standard objects:
- SFCs
- Shop Orders
- Resources
- Operations.
These fields are name-value pairs, loosely typed, stored as strings in the database. They were intended for supplementary information.
In practice, they became workflow engines.
A custom field called HOLD_REASON on an SFC. An Activity Hook that checks this field before allowing a lot to proceed. Another hook that writes to a field called REWORK_FLAG based on data collection results. A third hook that reads both fields to decide which routing branch to follow.
None of this is visible in the standard ME configuration. The object model looks clean. The actual execution behavior is governed by undocumented string fields that are only meaningful in the context of custom Java code that references them.
There is no tool provided by SAP that maps these dependencies. No dependency graph. No impact analysis.
The relationship between custom data fields and Activity Hooks exists only in the source code itself, and sometimes not even there if the developers didn’t comment their work.
The Integration Iceberg
Then there is MII. SAP Manufacturing Integration and Intelligence runs alongside ME on the same NetWeaver server. It handles everything that connects the MES to the rest of the enterprise and to the shop floor equipment.
MII’s Business Logic Service (BLS) transactions are visual workflow compositions that model integration logic. A typical SAP ME implementation has dozens to hundreds of them. They handle
- ERP order synchronization
- Equipment data collection
- Label printing
- SPC analysis
- Custom reporting
- and business logic that could not fit inside ME’s standard transaction framework.
Here is the thing about BLS transactions: they are stored as XML workflow definitions in MII’s workbench. They frequently contain embedded SQL queries running directly against the ME database, BAPI calls to the ERP system, custom Java actions, and hardcoded references to specific SFC structures, custom data fields, and resource configurations.
They are documented to the extent that whoever built them documented them. Which, in the majority of implementations I have seen, means they are not documented at all.
Why This Matters Right Now
Every SAP ME customer must plan a transition. To SAP DM, or to something else. Either way, the transition is a reimplementation. And the scope of that reimplementation is directly determined by the customization footprint.
- If you don’t know how many Activity Hooks you have, and how they interact with each other, you cannot estimate the reimplementation effort
- If you don’t know which custom data fields are referenced by which hooks, you cannot separate business-critical customization from technical debt
- If you cannot take stock and map your MII BLS transactions, you cannot determine how much of your integration layer needs to be rebuilt versus retired.
I have seen organizations estimate their transition at twelve months, only to discover during the project that their customization footprint was three times what they assumed.
Not because they were careless, but because the customization was architecturally invisible. Distributed across compiled Java classes, XML workflow files, and undocumented database fields.
No single view, no dependency map, no way to know what you don’t know until you look.
The Question Nobody Asks Early Enough
The conversation in the SAP ME community right now is mostly about timelines and target platforms.
- Should we move to SAP DM?
- Should we evaluate alternatives?
- When should we start?
These are the wrong first questions.
The right first question is: what are we actually running?
Before selecting a target platform, build the customization inventory:
- Catalog every Activity Hook and what it does
- Map every custom data field to the hooks that reference it
- Export and classify every MII BLS transaction
- Document every PCo agent configuration.
- Build the feature flows that tie all of these hooks and data fields together
This is 2 to 3 weeks of focused work for a single site, and it will consistently reveal customization that the organization’s own IT team did not fully appreciate.
This inventory is the prerequisite for any honest transition estimate. Without it, you are planning based on assumptions. And in my experience, the assumptions are always optimistic.
What This Reveals About Architecture
There is a broader point here.
The customization problem exists because of an architectural choice. SAP ME gave developers the tools to extend the system through code. That code became tightly coupled to the platform, difficult to inspect, and impossible to migrate. The flexibility that made SAP ME powerful in 2010 is exactly what makes it painful to leave in 2026.
The lesson for anyone choosing the next platform is simple: flexibility should come from configuration, not customization. A system that requires you to write and deploy code to accommodate operational variation is a static system in a dynamic world. It will eventually become a system you cannot change, upgrade, or leave without significant pain, cost and effort.
The best indicator of long-term cost of ownership is not the license fee or the implementation timeline. It is the ratio of configuration to custom code.
Today, if change requires a project, the system is already holding you back.
Blog Series: The SAP ME Reset Window
#2 What carries over from SAP ME to DM? A technical comparison
