Strangler Fig Pattern: De-Risking ERP Migration One Module at a Time

Moving an enterprise resource planning system to the cloud is one of the most consequential technology decisions a mid-market or enterprise company will make. It affects finance, supply chain, HR, reporting, customer service — every operational process that depends on accurate, real-time data. The stakes have never been higher: Gartner classifies 25% of ERP implementations as catastrophic failures, with mean cost overruns of 35%. Most of those failures share a common root cause — teams attempting to replace an entire monolithic system in a single coordinated switch known colloquially as "big bang" migration.

There is a better way. The Strangler Fig pattern, introduced by Martin Fowler as an architectural migration strategy, offers enterprises a structured approach: gradually replace ERP modules one at a time while keeping the legacy system running behind them. The result is lower risk, clearer visibility into progress, and the ability to course-correct before small issues cascade into project-wide disasters.

Why Big-Bang ERP Migrations Fail

The big-bang approach concentrates all risk into one moment. You plan for months — sometimes years — inventorying every integration, cleansing decades of accumulated master data, retraining thousands of users. Then on go-live night, you flip the switch. If something goes wrong — and given that legacy ERPs accumulate undocumented customizations, edge-case dependencies, and data quirks that simply do not appear in staging environments — rollback is often impractical because the old system has already been decommissioned or the data has been transformed beyond easy reversal.

TechTarget's research on ERP cloud migration failures identifies several recurring causes:

• Overlooking data dependency (41%): Disrupted data migration cascades into module-wide failures when most data must migrate at once across interdependent workflows.
• Having IT own the project entirely (39%): When migrations are treated as purely technical transfers rather than business process reengineering initiatives, critical workflow requirements slip through gaps between departments.
• Failing to plan thoroughly (37%): Assuming cloud ERP deployment is "plug and play" because it is a SaaS product, leading to inadequate testing cycles and rushed user training.
• Adding too many features prematurely (29%): Teams attempt to replace working systems with all the new SaaS ERP capabilities simultaneously, overwhelming users and exposing configuration gaps before the core system works reliably.
• Neglecting connectivity (23%): Forgetting that cloud ERPs depend entirely on network reliability, creating single points of failure where a network outage brings operations to a complete halt.

Each of these failure modes becomes less catastrophic when the migration scope per "switch" is small. This is exactly what the Strangler Fig pattern addresses.

The Architecture Behind the Strangler Fig Pattern

The metaphor comes from a strangler fig tree, which grows around its host, gradually enveloping it until the original tree withers away. Applied to ERP migration, two architectural layers make this work:

Proxy / API Routing Layer

This layer sits between your users (the ERP web interface, mobile apps, external integrations) and the ERP backend. Initially, all traffic passes through the proxy to the legacy system — no behavior changes, no risk introduced. As new services are built and validated, the proxy routes specific endpoints to replacement services instead.

Anti-Corruption Layer (ACL)

Behind the proxy, the ACL handles translation between legacy contracts and new service contracts. Legacy ERPs often have inconsistent data models, poorly documented stored procedures, and conventions shaped by years of ad-hoc changes accumulated across dozens of developer teams. The ACL prevents these legacy patterns from corrupting the new service's clean domain model by handling all translation at the boundary.

Step-by-Step Migration Execution

Here is how a typical Strangler Fig ERP migration unfolds, from initial assessment through full decommission:

Step 1 — Map the Legacy Module Dependency Graph

Before writing a single line of replacement code, inventory your current ERP's modules and their dependencies. Which modules call which? Where is shared state stored? What integrations touch which tables? The output is a dependency matrix that reveals the natural order for replacement. Modules with fewer external dependencies and clearer boundaries are strangled first — typically things like self-service portals or departmental reporting tools — while deeply coupled core modules like general ledger become migration targets only after your team has built confidence with simpler replacements.

Step 2 — Build Proxy and Anti-Corruption Layers

Establish the routing infrastructure without yet replacing any functionality. Once proxy and ACL are in place, your team can begin building replacement services knowing traffic routing and contract translation already work correctly. This is often where organizations realize their legacy system exposes data in ways no one documented — and that realization, uncovered early, saves months of rework.

Step 3 — Strangle One Module at a Time

For each module being replaced:

• Build the replacement service with its own domain-bounded, service-owned data store. Cloud-native services need completely different structures than legacy flat shared tables.
• Synchronize data between legacy ERP and new service using Change Data Capture (CDC), event-driven replication, or dual-writes depending on consistency requirements.
• Run reconciliation jobs comparing outputs between legacy and new systems against predefined performance and consistency thresholds. This provides the evidence needed before shifting any production traffic.
• Shift read traffic progressively: A canary sequence like 1% → 5% → 25% → 50% → 100% limits blast radius. At each stage, monitor latency, error rates, and business-level metrics against defined thresholds.
• Shift write traffic once reads are stable and reconciliation confirms consistency over a sustained period — typically two to four weekly reporting cycles minimum.
• Decommission the legacy module once the replacement has run reliably in production for a defined stabilization period, often 60 days for financial modules.

Step 4 — Repeat Until Legacy Is Obsolete

The beauty of this approach is that each cycle provides incremental ROI. The accounts payable module you strangled first starts delivering value immediately: faster processing, fewer errors, automated exception handling. Meanwhile, your team gains deep expertise with the new platform before tackling your most complex and customized modules.

Key Patterns That Make This Work

Beyond the core pattern, several supporting practices consistently appear in successful migrations:

Shadow Mode and Continuous Synchronization

In shadow mode, every write to the legacy ERP is simultaneously synchronized to the replacement service. A reconciliation job runs on a schedule — or continuously for real-time validation — comparing outputs against predefined thresholds. When results consistently meet thresholds, the team has objective evidence that the new service performs equivalently. Without this evidence, shifting traffic is simply optimistic guessing.

Domain-Bounded Data Stores

Legacy ERPs typically use flat denormalized tables or large shared schemas serving multiple business domains with no clean separation. Cloud-native services need domain-bounded data models where each service owns its data and exposes it through well-defined APIs. The mapping from legacy to new is not always one-to-one: a single legacy table may split across multiple service stores, or several legacy tables consolidate into one. Domain boundaries drive the design, not legacy schema convenience.

Rapid Reconciliation Tooling

Build automated reconciliation tools early and use them during parallel running. Compare critical outputs — financials, inventory valuations, production schedules, costing calculations — between old and new systems continuously. This removes subjective judgment from go/no-go decisions and prevents the anxiety-driven rush to rollback that derails many migrations.

Typical Timelines and Costs

A Strangler Fig migration follows the existing ERP's operational rhythm rather than imposing a disruptive one-time event. Industry benchmarks suggest 12 to 36 months for full replacement depending on complexity:

• Simple ERP (less than 500 users, under 15 modules): 12–18 months at $400K–$750K total project cost.
• Moderate ERP (500–2,000 users, 15–30 modules): 18–30 months at $750K–$2M total project cost.
• Complex ERP (2,000+ users, 30+ modules, global footprint): 24–36 months at $2M–$8M total project cost.

For comparison, a greenfield re-implementation of an equivalent scope typically adds 30–50% to both timeline and cost because you are rebuilding business processes from scratch rather than incrementally replacing working modules.

Common Pitfalls and How to Avoid Them

Pitfall 1: Strangling One Thing, Then Finding Five Hidden Dependencies

The dependency mapping exercise is not optional. Organizations that skip it often strangling a reporting module only to discover the general ledger calls it for audit trail generation. Every unexpected discovery delays the traffic shift and erodes stakeholder confidence.

Pitfall 2: Treating Proxy as Permanent Infrastructure

The proxy should be temporary routing infrastructure that you eventually remove once all traffic reaches native services. Letting it accumulate custom business logic defeats its purpose and creates a new dependency to manage. Set a policy that no business rules live in the proxy — only routing and ACL translation.

Pitfall 3: Underestimating Integration Rebuilds

Your ERP connects to CRM, e-commerce, EDI partners, shop-floor systems, quality management platforms, logistics providers, and probably a dozen other applications. Every direct database integration must be rebuilt as an API connection when the ERP module moves behind the proxy layer. Budget $5K–$25K per integration rebuild depending on complexity and test each thoroughly before the module goes live.

Pitfall 4: Skipping User Training During Incremental Cutover

If users encounter different interfaces for "the same" function depending on whether data is served from legacy or replacement modules, frustration builds fast. Provide unified training documentation and help resources during each module strangling so users understand the change is intentional.

When Not to Use the Strangler Fig Pattern

The pattern is not universal. It works best when:

• Your legacy ERP still functions reliably enough that gradual replacement is feasible (a crashing SAP ECC, for example, forces a faster decision than an aging but stable system).
• You have technical capacity to build and maintain parallel systems simultaneously.
• Your business can tolerate some complexity during the migration period — users seeing slightly different interfaces or reporting outputs during transition windows.

A lift-and-shift to cloud IaaS makes sense when you need off-platform urgency: your data center lease expires in six months, hardware is end-of-life and replacement costs are prohibitive. Replatforming with managed services fits when the core architecture is sound and you want operational improvements — automated backups, managed databases, high availability — without a full architectural rewrite.

The ArcBeta Approach to ERP Modernization

At ArcBeta, we have seen how ERP migrations succeed and fail across industries from Calgary-based manufacturers to Edmonton-area healthcare providers. Our process begins before any code is written: an 8–12 week business process discovery phase that maps current-state workflows, documents every dependency, and identifies which customizations still deliver competitive value versus which exist purely out of institutional inertia.

We apply the Strangler Fig pattern not as a theoretical exercise but as a practical framework for phased delivery. Each strangled module delivers measurable ROI — faster reporting cycles, fewer month-end close errors, reduced IT maintenance burden — while the team builds expertise with the target platform incrementally. Clients who have followed this approach consistently achieve on-time go-lives with 40% fewer post-migration critical incidents compared to big-bang alternatives.

The Strangler Fig pattern is not just an architectural choice. It is a risk management strategy that respects how organizations actually change: gradually, imperfectly, but persistently. When your ERP holds the single source of truth for your business operations, that patience is not a luxury — it is an operational necessity.