A manufacturer running a live ERP, a cloud workload, or a custom application faces a specific problem when the business needs to change one of them: the system doing real work today cannot simply stop while the new one is built. Orders are moving, production is running, and customers are expecting commitments to hold. The risk is not that modernization is a bad idea.
The question is not whether to change. It is how to change without the business paying for the transition in missed shipments, corrupted records, or rework.
Why These Changes Are Hard to Sequence
The difficulty starts with how tightly connected these systems actually are. In a manufacturing environment, MES sits at the edge of operational technology and information technology, which means it must interact with enterprise applications on both sides. MES can interact with ERP to get production and purchase order information, master data about parts and products, inventory availability, and bill of materials. It also reports back to ERP for the status of orders, actual material and labor consumption during production, and machine status. If a product lifecycle management (PLM) system is present, MES can interact with it to get a detailed bill of process, work instructions, and in some cases the bill of materials, and reports to PLM about process execution information, non-conformances, and BOM variations.
That web of live data exchange means that changing any one of these systems touches the others. A cloud migration that moves ERP to a new environment changes where integration endpoints resolve. A custom application replacement changes which records are authoritative and who owns them. A data platform consolidation changes what downstream reports and workflows can see. None of these changes is self-contained, and the design for handling them varies based on the systems MES interacts with in a given environment.
A second constraint is data quality and ownership. An existing single authentic data source may not be fit for purpose for a new requirement. Legacy systems operating off isolated data can make the transition to shared data sources difficult to justify within a manageable timeframe. That is not an argument against change. It is an argument for being honest about what the transition actually requires before committing to a timeline.
Four Approaches Worth Comparing
No single approach fits every situation. The right response depends on what the system currently does, how tightly it is connected to other systems, and what the business actually needs to change.
Extend the existing system. Before replacing a platform, check whether the capability gap can be closed by configuring, extending, or integrating what is already in place. If the existing ERP or custom application can be extended to meet the requirement, that path avoids a cutover entirely. The tradeoff is that extensions accumulate technical debt and may constrain future changes.
Targeted integration. When two systems need to exchange data but neither needs to be replaced, a targeted integration may be the smallest sound response. The same pattern applies more broadly: define the record that needs to cross the boundary, own the transformation, and route it without requiring either system to change its internal structure. The tradeoff is that point-to-point integrations multiply over time and require governance to stay manageable.
Reporting and portal patterns without platform change. When the business need is visibility rather than a new transaction capability, a reporting layer or portal may resolve the problem without touching the underlying systems. Organizations can import data from ERP and PLM to an Amazon S3 bucket, whether those systems are hosted in the cloud or elsewhere, and use that data for reporting and analysis. This approach preserves existing workflows and avoids cutover risk. The tradeoff is that it does not fix underlying data quality problems and may create a parallel record that diverges from the source.
Governed modernization or platform change. When the existing system genuinely cannot support the required capability, a platform change may be warranted. The solution team uses industry standard methods to perform an objective, data-driven analysis to determine whether an existing solution is a sufficiently good fit for the environment and purpose. The selection should follow that analysis, not precede it.
Tradeoffs That Determine the Sequence
Implementation effort is the most visible tradeoff, but it is not the only one. Data ownership is a governance question that must be answered before migration begins: which system holds the authoritative record for each data type, who is responsible for its accuracy, and what happens to that ownership when the system changes? Permissions that were embedded in a legacy application need to be explicitly re-established in the new environment, not assumed to carry over.
Adoption is a constraint that technical designs can underestimate. A new system that works correctly but that the people running production do not trust or use consistently will produce worse outcomes than the imperfect system it replaced.
Cloud cost governance is a related concern during and after migration. BCM Dashboards now support a Detected Anomalies widget, which displays the number of anomalies detected and their total cost impact relative to month-to-date spend, giving immediate context on each anomaly's scale. For each anomaly, teams can review the cost impact, root cause, and duration, and filter by severity, service, account, and region. During a migration, when workloads are running in both environments simultaneously, unexpected cost spikes are a real risk. Having anomaly detection integrated into the same dashboard as budgets and usage data means finance and cloud operations teams can catch those spikes before they compound.
Ongoing support is the tradeoff that surfaces last but matters longest. A custom-built integration or a heavily extended ERP requires someone to maintain it. If that knowledge lives with one person or one vendor, the system becomes a liability the moment that relationship changes. Governance means documenting who owns each record, who can authorize a change to the integration, and what the escalation path is when something breaks.
Connecting Business Capabilities to the Change Sequence
The practical starting point is not a technology decision. It is a capability map: what does the business need to be able to do, which application or data record currently supports that capability, and what would have to change for the new system to support it instead?
From that map, sequence the work in layers. Establish the integration boundary: define which events need to cross from the old environment to the new one during the coexistence period, and build those connections explicitly rather than assuming they will resolve on their own.
Decision rights matter throughout. Someone must be accountable for approving the cutover, not just the technical team confirming that the system works, but the business owner confirming that the capability is ready. That accountability does not require a formal architecture governance process. It requires a named person with the authority to say the business is ready to move, and the responsibility to answer for it if the transition disrupts a customer commitment.
The goal is not a perfect system. It is a change that the business can absorb without losing the commitments it has already made.
