Legacy, monolithic ERPs are among the highest-risk systems in any enterprise. They hold years of business-critical data, run deeply embedded workflows, and are often tightly coupled to the point where a single change can cascade into unexpected failures. For CTOs and engineering leaders, the question is not whether to migrate, but how to do it without bringing operations to a halt.
ERP cloud migration is the process of moving a legacy, on-premise ERP system to a cloud environment — often accompanied by refactoring or re-architecting monolithic modules into cloud-native services. This article focuses on the technical playbook for that journey: the Strangler Fig Pattern for incremental module replacement, data cleanse and structuring as a migration foundation, and progressive cutover techniques that help reduce cutover risk and support minimal or near-zero downtime.
This is not a universal recommendation. Every ERP landscape is different. But for organizations where the legacy ERP is still operational, business continuity is non-negotiable, and a gradual, risk-managed approach is preferred over a big-bang gamble, the patterns described here provide a structured path forward. For broader context on choosing between custom ERP vs off-the-shelf ERP, that comparison provides the strategic backdrop for why a custom microservices approach may fit certain migration scenarios.
Key Takeaways
- ERP cloud migration often requires refactoring or re-architecting individual modules, not simply lifting and shifting the entire monolith.
- The Strangler Fig Pattern enables gradual, module-by-module replacement of legacy ERP functionality, helping reduce cutover risk and support minimal or near-zero downtime.
- Data cleanse and structuring is a foundational step that significantly influences migration outcomes — it should happen before migration, not after.
- Zero downtime is an engineering objective, not a guarantee. It is pursued through a combination of shadow deployment, data synchronization, progressive traffic shifting, and tested rollback plans.
- Custom microservices offer greater flexibility when business processes differ significantly from standardized models; off-the-shelf cloud ERP can deploy faster when processes align with vendor standards.
- HDWEBSOFT operates under an ISO/IEC 27001-certified Information Security Management System (ISMS), providing governance for migration projects.
Why Legacy ERP Migration Fails (And Why It’s Different Now)
ERP migration projects have a well-earned reputation for difficulty. Understanding the common failure patterns helps explain why legacy ERP modernization requires a different approach — and why the patterns described later in this article exist. For broader context on legacy application migration to cloud, the general principles of cloud migration apply, but ERP systems add unique complexity due to their scale, data volume, and business-criticality.
The Big-Bang Trap
The most common failure mode is the big-bang cutover: attempting to migrate the entire ERP — all modules, all data, all integrations — in a single, coordinated switch. This approach concentrates all risk into one moment. If something goes wrong during cutover, rollback is often impractical because the old system has already been decommissioned or the data has been transformed beyond easy reversal. Teams are overwhelmed by the sheer scope of simultaneous change, and the business absorbs the cost of extended downtime.
The big-bang approach assumes that everything can be tested in a staging environment and will work identically in production. In practice, legacy ERPs accumulate edge cases, undocumented customizations, and data quirks that only surface under real production load.
Why Monolithic ERPs Resist Migration
Legacy ERPs resist migration because of their architecture. Shared database schemas mean that a single table may serve multiple business domains with no clean separation. Business logic is often embedded in stored procedures, triggers, or vendor-specific frameworks that cannot be easily extracted. Customizations made over years — sometimes decades — are “frozen” into the vendor’s framework, making it difficult to identify what is standard and what is custom.
This is why a simple lift-and-shift (rehost) often fails to deliver the expected benefits when organizations attempt to migrate legacy ERP to cloud without addressing the underlying architecture. The monolith moves to the cloud, but the technical debt, coupling, and rigidity move with it. The cloud provides new infrastructure, but the old architecture remains unchanged.
The Strangler Fig Pattern: Replacing Legacy ERP Module by Module
The Strangler Fig Pattern, introduced by Martin Fowler, offers an alternative to the big-bang cutover. The metaphor comes from a strangler fig tree: a new tree grows around an existing one, gradually replacing it until the old tree is no longer needed. Applied to ERP migration, new services are built alongside the legacy ERP, gradually taking over functionality until the legacy system can be decommissioned.
Two distinct layers make this pattern work:
- Proxy / API routing layer: Sits between clients (UI, integrations, external systems) and the ERP backend. Initially, all traffic flows through the proxy to the legacy ERP. As new services are built, the proxy routes specific endpoints to the replacement services instead.
- Anti-Corruption Layer (ACL): Translates contracts and data models between the legacy ERP and the new services. The legacy ERP’s data model and conventions are often inconsistent, poorly documented, or shaped by years of ad-hoc changes. The ACL prevents these legacy patterns from “corrupting” the new service’s clean domain model by handling translation at the boundary.
For technical implementation guidance on this pattern in cloud environments, AWS Prescriptive Guidance on the Strangler Fig Pattern provides architecture-level recommendations.
Step 1: Map the Legacy Module Dependency Graph
Before writing any replacement code, the first step is to map the dependency graph of the legacy ERP. Which modules depend on which? Where is shared state stored? What are the data flows between modules? Which integrations touch which tables?
The output is a dependency matrix that reveals the natural order for replacement. Modules with fewer dependencies and clearer boundaries are typically strangled first, while deeply coupled modules are left for later stages when the team has more experience with the migration process and the supporting infrastructure is more mature.
Step 2: Build the Proxy Layer and Anti-Corruption Layer
The proxy layer is placed in front of the legacy ERP. Initially, 100% of traffic passes through the proxy to the legacy system — no behavior changes, no risk. The ACL sits behind the proxy and handles translation between legacy contracts and new service contracts.
This step is about establishing the routing and translation infrastructure without yet replacing any functionality. Once the proxy and ACL are in place, the team can begin building replacement services with confidence that traffic routing and contract translation are already handled.
Step 3: Strangle One Module at a Time
For each module being replaced, a typical sequence looks like this:
- Build the replacement service with its own domain-bounded data store, exposed through the ACL.
- Synchronize data between the legacy ERP and the new service. The synchronization mechanism depends on the architecture — it may involve Change Data Capture (CDC), event-driven synchronization, a transactional outbox pattern, or dual-writes. There is no single default best practice; the choice depends on consistency requirements, data volume, and the legacy system’s capabilities.
- Run a reconciliation job that compares outputs between the legacy and new systems against predefined reconciliation, performance, and consistency thresholds. This validates that the new service produces equivalent results before any traffic is shifted.
- Shift read traffic to the new service progressively while writes continue to both systems (or to the new system only, depending on the synchronization strategy).
- Shift write traffic to the new service once reads are stable and reconciliation confirms consistency.
- Decommission the legacy module once the new service has been running reliably in production for a defined stabilization period.
This sequence is then repeated for the next module in the dependency graph. Each module replacement is an independent, testable, and rollback-capable step.
Step 4: Decommission the Legacy Monolith
When all modules have been strangled, the legacy ERP is reduced to a shell — it may still be running, but no traffic flows to it. At this point, the remaining data can be migrated, the legacy infrastructure can be decommissioned, and the team can focus on optimizing the new architecture without the constraints of the old system.
This final step is the one that big-bang migrations attempt to reach in a single leap. The Strangler Fig Pattern reaches it through a series of smaller, safer steps.
Data Cleanse & Structuring: The Foundation Nobody Skips
Legacy ERP data accumulates over years of operation. Duplicate records, orphaned foreign keys, inconsistent encodings, business rules embedded in stored procedures, and data that no one can explain — these are the realities of legacy ERP data. Migrating this data as-is means carrying decades of technical debt into the new system.
Data cleanse and structuring is the step that determines whether the new system starts with a clean foundation or inherits the old system’s problems. It must happen before migration, not after.
Data Audit & Profiling
The first step is a comprehensive data audit. Run data profiling across all tables to measure null rates, duplicate rates, referential integrity violations, data type inconsistencies, and encoding issues. The output is a data quality report and a risk matrix that identifies which data sets are clean enough to migrate, which need cleansing, and which should be archived.
This audit also surfaces hidden dependencies — tables that appear unused but are referenced by stored procedures, or fields that appear free-text but encode business meaning. These discoveries inform the restructuring strategy.
Data Cleansing Strategy
Cleansing involves several activities:
- Deduplication: Identify and merge duplicate records, preserving the most complete and accurate version.
- Standardization: Normalize encodings, date formats, currency formats, and naming conventions to a single standard.
- Orphaned record resolution: Decide what to do with records that reference non-existent parents — repair, archive, or discard.
- Business rule extraction: Identify business logic embedded in data (stored procedures, triggers, computed columns) and document it for reimplementation in the new service layer.
A practical rule: if you cannot explain what a data record means or why it exists, archive it — do not migrate it. Migrating unexplained data creates a new system with the same opacity as the old one.
Restructuring for Domain-Bounded Data Stores
Legacy ERPs typically use flat, denormalized tables or large shared schemas that serve multiple business domains. Cloud-native services need a different structure: domain-bounded, service-owned data stores, where each service owns its data and exposes it through well-defined APIs.
These data stores may be normalized or denormalized depending on the access pattern. A service handling transactional writes may use a normalized schema for consistency, while a read-heavy reporting service may use a denormalized schema for query performance. The key principle is that each service owns its data store — there are no shared tables across services.
The mapping from legacy to new is not always one-to-one. A single legacy table may be split across multiple service data stores, or multiple legacy tables may be consolidated into one. The mapping is driven by domain boundaries, not by the legacy schema structure.
CQRS (Command Query Responsibility Segregation) and Event Sourcing are optional patterns that can support this restructuring — for example, by separating write models from read models or by maintaining an immutable event log as the source of truth. These are architectural choices, not requirements, and should be evaluated based on the specific needs of each service.
Zero-Downtime Cutover: Techniques for Progressive Migration
Zero downtime is an engineering objective, not a guarantee. For organizations targeting zero-downtime ERP migration, it is pursued through a combination of techniques that reduce cutover risk and allow the legacy and new systems to operate in parallel until the new system is proven stable. The specific combination of techniques depends on the system being migrated — there is no single playbook that applies to every ERP.
Shadow Mode & Data Synchronization
In shadow mode, every write to the legacy ERP is simultaneously synchronized to the new service. The synchronization mechanism may be CDC, event-driven replication, a transactional outbox, or dual-writes — the choice depends on the architecture and consistency requirements.
A reconciliation job runs continuously (or on a schedule) to compare the outputs of the legacy and new systems. The comparison checks data consistency, business logic equivalence, and performance characteristics against predefined reconciliation, performance, and consistency thresholds. These thresholds are defined per migration based on the business requirements — there is no universal default.
When the reconciliation results consistently meet the defined thresholds, the team has evidence that the new service is ready to serve traffic. Without this evidence, shifting traffic is a gamble.
Progressive Traffic Shifting
Once shadow mode validates the new service, read traffic is shifted progressively. A canary sequence — for example, 1% → 5% → 25% → 50% → 100% — is an illustrative pattern, not a standard. The actual sequence depends on the system’s traffic volume, error tolerance, and monitoring capabilities.
At each stage, the team monitors latency, error rates, and business-level metrics. If any metric exceeds the defined thresholds, traffic is shifted back to the legacy system. This progressive approach limits the blast radius of any issue to the percentage of traffic on the new service at the time of detection.
Feature Flags & Rollback Planning
Feature flags allow the team to switch between the legacy and new systems per-tenant, per-module, or per-request. This enables rapid traffic and behavior rollback without redeployment — if an issue is detected, the flag is toggled and traffic returns to the legacy system.
However, feature flags enable rapid traffic and behavior rollback, not necessarily rapid data rollback. If the new service has been writing data for a period before the issue is detected, reverting that data may require a separate, planned data rollback procedure. This distinction matters: the rollback plan must account for both the traffic switch and any data state that was modified during the period the new service was active.
A rollback plan that has not been tested is not a rollback plan. Before cutover, the team should rehearse the rollback procedure in a staging environment to confirm it works under realistic conditions.
ERP Migration Strategy: Choosing Your Migration Path
Not every ERP migration requires the Strangler Fig Pattern. The right approach depends on the legacy system’s condition, the business’s tolerance for change, and the desired end state. Four common migration paths, aligned with established cloud migration terminology, provide a framework for this decision:
- Rehost (lift-and-shift): Move the legacy ERP to cloud infrastructure with minimal changes. Fast, but the technical debt and architectural constraints of the monolith are carried along. Suitable when the priority is infrastructure modernization and the legacy architecture is acceptable.
- Replatform: Migrate with limited optimization — for example, moving to a managed database service or adjusting the deployment model — without deeply changing the application architecture. A middle ground that reduces some operational burden without a full re-architecture.
- Refactor / Re-architect: Restructure the application architecture, often breaking the monolith into services. The Strangler Fig Pattern belongs here. This path offers the greatest architectural improvement but requires the most engineering effort. It is well suited when gradual replacement, high availability, and a still-operational legacy ERP are required.
- Rebuild: Start from scratch with a new system, leaving the legacy ERP behind. This offers the greatest redesign freedom but also the highest transformation scope and change exposure. Suitable when the legacy ERP is broken beyond repair, the business model has fundamentally changed, or a greenfield approach is viable.
For a broader framework on what makes a successful ERP implementation, the five-pillars model provides complementary guidance on planning, execution, and adoption.
When to Choose Strangler Fig vs Rebuild
The Strangler Fig Pattern is not always the right choice. It fits when the legacy ERP is still operational and serving the business, the organization needs high availability during migration, and there is budget and appetite for a phased, multi-stage effort. It also works well when the team wants to learn and adapt as they go — each module replacement provides lessons that inform the next.
Rebuild is the alternative when the legacy ERP is no longer maintainable, the business model has shifted so fundamentally that the old processes no longer apply, or the organization has the appetite for a clean-slate approach with its associated risk and scope. Rebuild offers the greatest redesign freedom but also the highest transformation scope and change exposure — every process, integration, and data model must be rebuilt from scratch.
Custom Microservices vs Off-the-Shelf Cloud ERP: The Migration Lens
The choice between custom microservices and off-the-shelf cloud ERP is not a binary one. Each approach has trade-offs that become clearer when viewed through the lens of migration.
Off-the-shelf cloud ERP (such as SAP, Oracle, or Microsoft Dynamics) provides standardized processes and data models backed by vendor ecosystems. These platforms can deploy faster when the organization’s processes align with the vendor’s built-in workflows, and they come with established integration patterns, support networks, and regular updates. The trade-off is that customization is constrained by the vendor’s framework — when business processes differ significantly from the standardized model, workarounds or limited extensions may be necessary, and data must be mapped into the vendor’s data model during migration.
Custom microservices offer greater flexibility when business processes differ significantly from standardized models — common in manufacturing and supply chain where workflows are domain-specific. Each service owns its data store, and the schema follows the domain rather than a vendor’s template. This allows module-by-module migration with schemas designed for the actual business, not for a generic template. The trade-off is higher development and maintenance effort: the organization builds and maintains the services, integrations, and infrastructure that a vendor would otherwise provide.
For organizations evaluating cloud-based ERP as part of their migration strategy, the decision ultimately depends on the trade-off between flexibility and speed of deployment, and on how closely the organization’s processes match what off-the-shelf options provide.
Security & Compliance During Migration
ERP migration projects span months or years, with data flowing across multiple environments — legacy on-premise, cloud staging, cloud production, and integration layers. This extended exposure surface requires deliberate security practices:
- Encryption at rest and in transit for all data stores and data flows, including synchronization pipelines between legacy and new systems.
- Identity and access management (IAM) with least-privilege principles — migration service accounts should have access only to the data and systems they need, and that access should be time-bound where possible.
- Audit logging for all data access and modifications, enabling traceability when issues arise during or after migration.
- Environment isolation so that staging and production environments are clearly separated, with no uncontrolled data flow between them.
HDWEBSOFT operates under an ISO/IEC 27001-certified Information Security Management System (ISMS). This means the organization’s information security processes — risk assessment, access control, incident management, and continuous improvement — are governed by an internationally recognized framework. For ERP migration projects, this ISMS provides the governance structure within which security practices are applied.
ISO/IEC 27001 is not a technical security baseline in itself — it is a management system standard that defines how an organization identifies, manages, and improves its information security posture. The technical controls (encryption, IAM, logging) are implemented within this governance framework.
How HDWEBSOFT Approaches Legacy ERP Cloud Migration
HDWEBSOFT’s approach to legacy ERP cloud migration is tailored to the specific legacy architecture and business context of each engagement. There is no fixed template applied to every project.
Depending on the legacy architecture, HDWEBSOFT’s migration approach can include dependency mapping, data cleansing, phased module replacement, cloud re-architecture, and progressive cutover. The team designs custom ERP systems for manufacturing and supply chain environments, where business processes often differ from the standardized models offered by off-the-shelf vendors.
HDWEBSOFT operates under an ISO/IEC 27001-certified ISMS, providing governance for migration projects from assessment through execution. A typical engagement follows an architecture roadmap:
- Assessment: Evaluate the legacy ERP’s architecture, data quality, module dependencies, and integration landscape.
- Dependency mapping: Build the module dependency graph that determines the order of replacement.
- Pilot module: Select a low-risk, well-bounded module for the first replacement cycle — this validates the proxy, ACL, and synchronization infrastructure.
- Scale: Apply lessons from the pilot to subsequent module replacements, scaling the process across the remaining dependency graph.
If your organization is evaluating a legacy ERP cloud migration, request a Legacy ERP Migration Assessment & Architecture Roadmap from HDWEBSOFT’s team. The assessment covers legacy architecture evaluation, data quality analysis, module dependency mapping, and a recommended migration path — whether that involves the Strangler Fig Pattern, replatforming, or another approach suited to your specific context.
Conclusion
ERP cloud migration is not a single event — it is a sequence of deliberate, risk-managed steps. The Strangler Fig Pattern provides a structured approach for gradual module replacement when the legacy ERP is still operational and business continuity is critical. Data cleanse and structuring ensures the new system starts with a clean foundation rather than inheriting decades of accumulated debt. Progressive cutover techniques — shadow mode, data synchronization, traffic shifting, and feature flags — help reduce cutover risk and pursue minimal or near-zero downtime as an engineering objective.
There is no shortcut, but there is a playbook. The right migration path — rehost, replatform, refactor, or rebuild — depends on the legacy system’s condition, the business’s needs, and the organization’s appetite for change. For teams navigating this decision, the patterns described here offer a starting point, not a prescription.
If your organization is planning a legacy ERP cloud migration, HDWEBSOFT’s team can help assess your current architecture and design a migration roadmap tailored to your context. Thank you for reading — we hope this playbook helps you approach your migration with greater clarity and confidence.
FAQ
What is ERP cloud migration?
ERP cloud migration is the process of moving a legacy, on-premise ERP system to a cloud environment, often accompanied by refactoring or re-architecting monolithic modules into cloud-native services. The goal is to reduce infrastructure cost, improve scalability, and enable modern integration — while minimizing disruption to business operations.
How long does a legacy ERP migration take?
The timeline depends on scope, complexity, and the chosen migration path. The Strangler Fig Pattern allows incremental, module-by-module replacement, but total duration varies based on the number of modules, data volume, integration complexity, and organizational readiness. There is no universal timeline that fits all ERP migrations.
Can ERP migration achieve zero downtime?
ERP migration can sometimes achieve minimal or near-zero application downtime by running legacy and target environments in parallel, synchronizing data, progressively shifting traffic, and maintaining tested rollback paths. Some integrations or transactional workloads may still require controlled cutover windows.
What is the Strangler Fig Pattern in ERP migration?
The Strangler Fig Pattern places a proxy or API routing layer in front of a legacy ERP, combined with an Anti-Corruption Layer that translates contracts and data models between the legacy system and new services. Traffic is gradually routed to replacement services, “strangling” the old module when the new service is mature enough. It is well suited when gradual replacement, high availability, and a still-operational legacy ERP are required.
How do you clean legacy ERP data before migration?
Data cleansing before migration involves data profiling to identify duplicates, nulls, and referential integrity violations; deduplication and standardization of formats; and restructuring into domain-bounded, service-owned data stores. The guiding rule is to cleanse before migrating, not after — if a data record cannot be explained or validated, it should be archived rather than migrated.
Why choose custom microservices over off-the-shelf cloud ERP for migration?
Custom microservices offer greater flexibility when business processes differ significantly from standardized vendor models and when module-by-module migration is needed. Off-the-shelf cloud ERP can deploy faster when processes align with vendor standards and the data model fits. The choice depends on the trade-off between flexibility and speed of deployment.
