This is the second 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 have spent the better part of the last ten years building, extending, and maintaining MES systems across semiconductor fabs, medical device manufacturers, and electronics assembly plants. I know the landscape and each player’s strengths. I also know their limitations. What SAP did was surprising, and it really highlighted the cost of ownership for some systems, and how the way a system is built can impact not only transitioning to competitors, but fascinatingly, your own new products.
The question I hear most often right now is straightforward: what carries over from SAP ME to SAP DM?
The honest answer is: almost nothing at the technical level. The concepts are similar. The implementations are incompatible. And this gap is not a matter of opinion. It is a consequence of two fundamentally different architectures.
Two Different Technology Worlds
SAP ME runs on SAP NetWeaver Application Server for Java. It is an on-premises application deployed on physical or virtual servers in your data center.
- Your extensions are Java classes compiled and deployed into the same NetWeaver environment
- Your data lives in a relational database (HANA, Oracle, SQL Server, or DB2) with a proprietary schema
- Your integration logic runs in MII as BLS transactions on the same Java stack.
SAP DM runs on SAP Business Technology Platform (BTP). It is a cloud-native SaaS application. There is no on-premise option.
- Your extensions are side-by-side applications deployed in Cloud Foundry or Kyma (Kubernetes) runtimes on BTP
- Your data lives in HANA Cloud with a different schema
- Your integration logic runs in SAP Integration Suite (CPI), a cloud middleware service completely separate from MII.
These are not two versions of the same product. They are two different products built on two different technology stacks, sharing a common heritage in the manufacturing execution domain.
The Layer-by-Layer Reality
Let me walk through each technical layer of a typical SAP ME implementation and explain what happens to it when you move to SAP DM.
Activity Hooks: Must Be Rewritten from Scratch
In SAP ME, Activity Hooks are Java classes deployed on NetWeaver that intercept standard transactions at pre, post, or replace execution points. They are the primary mechanism for embedding custom business logic.
In SAP DM, this mechanism does not exist. There is no Activity Hook framework. This means custom logic must be implemented through one of three paths: configuring the PPD (Production Process Designer) for workflow-level automation, building a side-by-side extension on BTP (Cloud Foundry or Kyma) that is invoked via API, or using custom POD (Production Operator Dashboards) plugin event extensions for UI-triggered logic.
None of these are architecturally equivalent to Activity Hooks. PPD is a workflow orchestrator, not a transaction interceptor. BTP extensions run outside the application in a separate runtime with API-mediated communication, which introduces latency and architectural complexity that embedded Java hooks did not have. POD plugin extensions only cover UI-triggered events, not server-side transaction logic.
The practical consequence is clear: every Activity Hook must be functionally analyzed, and the business logic it contains must be redesigned for one of the DM extensibility paths. The Java code itself cannot be ported. Moreover, SAP has acknowledged that ME SDK knowledge is conceptually transferable, but the code is not. This redesign is consistently reported as one of the largest components of the total custom code migration effort, unsurprising, given Activity Hooks are usually where the deepest, most transaction-coupled business logic lives.
MII BLS Transactions: Must Be Redesigned
MII’s Business Logic Service transactions are visual workflow compositions that handle integration, business logic, and automation. They run inside MII on the NetWeaver Java stack and have direct access to ME’s database, ERP via RFC/BAPI, equipment via PCo, and external systems via web services.
In SAP DM, the equivalent workflow engine is the PPD. PPD uses a drag-and-drop BPM-style interface to compose execution workflows. It is a different tool with a different paradigm.
There is no import mechanism. You cannot export a BLS transaction from MII and load it into PPD. The workflow structure, the action blocks, the data transformations, the error handling, and the external system calls are all different. Each BLS transaction must be opened, its logic understood, and the equivalent behavior rebuilt in PPD or in a CPI integration flow.
For a typical SAP ME implementation with 50 to 150 BLS transactions, this represents weeks to months of reimplementation effort. And this assumes you can understand what each transaction does, which brings us back to how deeply you actually now your current system, which was something we addressed in the recent post about customization footprint.
Doing some back-of-the-envelope math: if you have 100 BLS transactions and each takes an average of 2 to 3 days to analyze, redesign, build, and test in the DM architecture, that is 200 to 300 person-days of integration reimplementation work alone. Before you touch a single Activity Hook, POD plugin, or master data mapping.
SAPMEINT: Must Be Rebuilt
SAPMEINT is the standard integration framework between SAP ME and SAP ERP/ECC. It runs inside MII and handles production order download, order confirmation, goods movements, and master data synchronization via IDoc and BAPI interfaces.
SAPMEINT does not exist in SAP DM. ERP integration in DM is handled by SAP Integration Suite (CPI), a cloud-based middleware platform on BTP. The communication patterns, protocols, and data transformations are entirely different. IDoc/BAPI-based integration is replaced by API-based cloud integration using CPI integration flows (iFlows).
SAP provides some standard integration content packages for DM-to-S/4HANA connectivity, covering basic scenarios like order download and confirmation. Nonetheless, these cover only the standard, out-of-box flows. Every custom SAPMEINT workflow, every customer-specific data enrichment, every custom IDoc mapping that your team or your SI partner built over the years must be redesigned and rebuilt in CPI.
POD Plugins: Must Be Rebuilt
SAP ME PODs are built with Java plugins deployed on NetWeaver. SAP DM PODs are built with UI5 components deployed on BTP. The underlying technology is different (Java/JSF vs. JavaScript/UI5), the deployment model is different (embedded vs. side-by-side on BTP), and the plugin framework APIs are different.
SAP DM does provide a POD Designer with standard plugins and the ability to develop custom plugins. But custom ME plugins cannot be imported or converted. They must be rewritten as UI5 components, tested in the DM POD framework, and deployed to BTP. For customers with a handful of custom plugins, this is manageable. For customers with heavily customized PODs that are central to their operator workflow, this is a significant effort.
Data Model: No Migration Tool
SAP ME uses a proprietary relational schema. SFCs, Shop Orders, Routings, Operations, Resources, BOMs, Data Collection Groups, NC Codes, and all associated transactional data live in this schema on your on-premise database.
SAP DM uses a different data model on HANA Cloud. Moreover, the entities are conceptually similar (SFCs exist in DM, orders exist in DM, routings exist in DM), but the schema structures, relationships, and API patterns are different.
There is no ETL tool, no schema mapping utility, and no data migration pipeline provided by SAP to move data from ME to DM. Master data (products, routings, resources) must be re-created in DM through its APIs or UI. Historical transactional data (production records, genealogy, quality data) must be archived from ME. It cannot be imported into DM.
For regulated environments, this is particularly painful. The validated production history that your ME system has accumulated over years is not portable. Also, you can archive it and query it from the archive, but it will not exist in DM’s data model. Any reporting or traceability that currently queries ME’s database directly will need to be redesigned to work against either an archive or DM’s own API-exposed data.
Equipment Connectivity: ProdCon Replaces PCo+MII
In the ME/MII stack, equipment connectivity works through SAP Plant Connectivity (PCo) collecting data from PLCs and SCADA systems and feeding it to MII for processing, transformation, and routing to ME. The configuration and runtime logic are intertwined inside MII.
In DM’s architecture, SAP Production Connector (ProdCon) replaces PCo. ProdCon is an on-premise Windows service that bridges equipment to the cloud. But there is a fundamental architectural shift: in DM, configuration happens in the cloud (DM is the design surface), while execution happens on-premise (ProdCon is the runtime executor). This is the opposite of MII, where configuration and runtime were co-located.
PCo agent configurations cannot be imported into ProdCon. Equipment models, tag mappings, and data flow patterns must be reconfigured. For a plant with a diverse equipment park spanning multiple protocols (OPC-UA, OPC-DA, SECS/GEM, MQTT, proprietary), this reconfiguration is a non-trivial effort.
The Update Model: A Permanent Change
I want to raise awareness to one additional difference that often gets overlooked in transition planning because it is not a migration issue, but an operational issue that begins the moment you go-live on SAP DM.
SAP ME was on-premise: you controlled when patches were applied, you could defer an update if it conflicted with a production freeze or a validation cycle, and your IT team decided the timing.
SAP DM is SaaS with mandatory quarterly releases. You do not control when updates are applied. Every quarter, the platform updates. In fact, SAP provides release notes and a pre-release testing window, but the update happens regardless.
For general manufacturing, this puts a strain, but it is often acceptable. For regulated environments under FDA 21 CFR Part 11, ISO 13485, IATF 16949, or similar frameworks, each mandatory update triggers a re-testing cycle and potentially a re-validation cycle.
This is a permanent and continuous operational cost that did not exist in the on-premise model. It’s a pattern that surfaces repeatedly in transition planning: organizations budget for the migration itself but not for the recurring cost of re-testing, and regulated manufacturers in particular are often caught off guard when the first mandatory quarterly update arrives and their quality team has to run regression testing on a schedule they don’t control.
What Actually Carries Over
Not everything is lost in the transition. What carries over is know-how, not code.
- Your understanding of your manufacturing processes carries over
- Your business requirements carry over
- Your team’s familiarity with MES concepts (SFCs, routings, operations, data collection, nonconformance management) carries over.
The general mental model of how a production execution system works carries over.
What does not carry over is everything you built on top of the platform. Every hook, every transaction, every plugin, every integration flow, every custom field, every report. All of that must be rebuilt, redesigned, or retired.
This is not a criticism of SAP DM as a product. DM has genuine strengths:
- modern cloud architecture
- better analytics integration
- a more accessible workflow designer
- and alignment with SAP’s broader BTP ecosystem.
The problem is not the destination. The problem is that the journey is a full reimplementation, and many organizations have not yet internalized what that means.
SAP DM is undoubtedly a more modern platform, but that modernity was bought at a price: SAP chose to step into the future without shouldering the past. Every Activity Hook, every SAPMEINT workflow, every custom POD plugin is weight they decided not to carry forward.
The Implication
If you are an SAP ME customer, the transition to SAP DM is not an upgrade and it’s not a migration, it’s a new implementation. It is the same scope of work as evaluating and implementing any other MES platform. SAP DM starts from scratch, just as any competitor would.
This changes the decision framework. The question is no longer “how do I upgrade to SAP DM?” but “since I am reimplementing regardless, which platform best serves the factory I need to run for the next decade?”
That question deserves an open evaluation, not an assumption that staying within the SAP ecosystem is automatically the lowest-risk path. The risk is the same regardless of destination… so choose the place you want to be, not the place you are being led to.
