The Strangler Fig Blueprint: Modernizing Legacy Monoliths With Zero Downtime

A warehouse operator came to us after its order platform had been running for more than a decade. The system still processed orders, but every meaningful change touched the same monolith: pricing, inventory, dispatch, customer notifications, and finance exports. A release that should have changed one workflow required a full regression pass across every site.

The detail that made the risk obvious was not a dramatic outage. It was a rollback exercise. The team could deploy the new code, but nobody could explain precisely which database writes had to be reversed if the release failed halfway through a trading day. The business had a deployment process, not a recovery process.

That is the problem this blueprint addresses. Modernization without downtime is achieved by controlling boundaries, traffic, data ownership, and rollback, not by placing a monolith behind a fashionable microservices diagram. The strangler fig pattern gives a team a way to replace a legacy system incrementally while the existing business continues to operate.

This guide is written for CTOs, CIOs, engineering leaders, and operations executives in Singapore, Australia, Hong Kong, and the wider APAC market. The examples assume a system that cannot be switched off while stores trade, shipments move, payments settle, or regulated records are created.

Why big-bang rewrites fail

Big-bang rewrites fail because the replacement must reproduce years of undocumented behaviour before the business receives any value. A monolith contains more than source code: it contains exception handling, data assumptions, operational workarounds, integration contracts, and decisions that no current diagram records.

We have inherited rewrite programmes where the new platform looked cleaner in a staging environment and performed worse in production. The missing behaviour was usually not a major feature. It was a site-specific cutoff rule, a retry path for a partner API, a manually corrected status, or a report that depended on a database field nobody regarded as authoritative.

The rewrite also creates a dangerous pause in product delivery. Internal engineers stop improving the current platform because the replacement is supposed to solve everything. Operations still need fixes. Customers still expect changes. The old system accumulates more pressure while the new one remains incomplete.

A monolith to microservices migration has a second failure mode: teams distribute the existing design without changing its ownership model. They split modules into services, retain shared tables, add synchronous calls between them, and create a distributed monolith with more failure points and less visibility.

The strangler fig pattern takes the opposite position. It treats the current system as a living production asset. New capability is built beside it, traffic is moved deliberately, and the old path is retired only after the new path has demonstrated correctness.

Our rule is simple: no extraction begins until we can name the business boundary, the system of record, the traffic switch, the success signal, and the rollback action.

That rule changes the programme from “replace the platform” to “retire one responsibility at a time.” A payment authorisation flow, inventory reservation, customer profile, or dispatch allocation can become a bounded migration unit. The business gets a controlled improvement rather than a twelve-month bet.

There are cases where an in-house team should own the entire programme. Hire internally when the capability will remain a permanent strategic differentiator, the organisation can staff architecture, QA, platform engineering, and operational support without weakening current delivery, and leadership can protect the team from competing roadmap demands. A rewrite is the wrong place to discover that the team had capacity for only two of those responsibilities.

controls before extraction

• business boundary — Define a bounded migration unit.
• system of record — Name the authoritative write path.
• traffic switch — Direct selected requests to the new path.
• success signal — Verify correctness through business outcomes.
• rollback action — Define traffic reversal and data recovery.

Retire one responsibility at a time.

Seam identification: finding the first module to peel off

The first module should be selected by business boundary and operational risk, not by whichever code folder looks easiest to extract. A useful seam has a clear owner, a measurable outcome, limited data coupling, and a traffic path that can be redirected without changing every caller.

We start with architecture assessment before implementation. The assessment traces requests from user or partner entry point through application logic, database writes, queues, scheduled jobs, reports, and operational procedures. It also records which team can explain each decision. A technically small module with ten hidden consumers is a worse first candidate than a larger workflow with one clear API.

The best first seam is usually a workflow with a stable contract and a tolerable failure domain. Customer notifications, document generation, search, pricing calculation, or a bounded partner integration may be suitable. Core settlement or inventory ownership may be strategically important but too coupled for the first extraction.

We do not infer a seam from the organisational chart. A “payments team” does not prove that payment ownership is isolated in code. The database and runtime call graph decide whether the boundary exists.

Teams also need a migration ledger. For each candidate, record the current owner, consumers, data stores, failure modes, compliance classification, traffic percentage, rollback trigger, and decommission condition. This ledger becomes more useful than a target-state diagram because it describes decisions that can be tested in production.

A 90-day legacy modernization execution plan can help turn that ledger into staged delivery when the organisation needs a practical sequence rather than another architecture presentation.

Routing layer and dual-write strategy

Verdict: put the strangler fig at the traffic boundary, not inside a collection of application branches. A routing layer gives the team one place to direct selected requests, observe outcomes, apply feature flags, and reverse traffic without redeploying the entire platform.

The layer may be an API gateway, reverse proxy, application facade, or domain-specific router. The technology matters less than the controls. It must preserve correlation IDs, expose route-level metrics, support cohort or tenant routing, and make the active implementation visible to operators.

We prefer routing by a business-safe cohort before routing by random percentage. A multi-site operator might move one site, one warehouse, one customer segment, or one low-risk transaction type. A fintech may use an internal account cohort where regulatory and reconciliation controls are already proven. Random traffic splitting can hide stateful differences when the same customer reaches different implementations across related requests.

Dual writes deserve suspicion. Writing to both old and new stores appears safe, but it creates two authorities and a new consistency problem. If one write succeeds and the other fails, the system has not achieved safety; it has created a reconciliation queue.

Use dual writes only when the operation is idempotent, the failure state is visible, and reconciliation is an explicit product of the design. Include an event identifier, source timestamp, version, and business key. A retry must not create a second order, reservation, or payment instruction.

Where possible, keep one authoritative write path and replicate changes outward through a durable event or change-data-capture process. The new component can build its read model from that stream while the old system remains the system of record. When ownership moves, the direction of replication changes under a controlled cutover.

For regulated workloads, accountability cannot be delegated to the routing layer or a delivery partner. MAS TRM expectations for Singapore financial institutions require governance over technology risk, resilience, access, change, and third-party arrangements. APRA CPS 230 places operational risk management and third-party service-provider oversight directly on the Australian regulated entity. The organisation remains accountable for the code path that processes a customer transaction, even when another party supplies engineers or operates part of the platform.

That is why our delivery model uses engineers on our payroll who work on the client roadmap, with ownership defined in the client’s engineering governance. A dedicated pod with a tech lead, QA, and DevOps responsibility is delivery capability. Staff augmentation is rented headcount. The distinction matters when the migration needs a tested rollback at 2 a.m., not another person assigned to a ticket queue.

For cloud boundaries, backup, recovery, and infrastructure dependencies, document the target controls alongside the application seam. A useful reference for that work is cloud migration and infrastructure modernization guidance, particularly when the strangler path is also moving workloads between environments.

Our minimum routing dashboard contains:

• Requests by implementation, cohort, site, and business operation.
• Success and failure rates using business outcomes, not only HTTP status codes.
• Latency at the gateway, application, database, and external dependency.
• Duplicate, missing, delayed, and reconciled records.
• Rollback readiness, including the last verified reversal or replay test.

A route is not ready for wider traffic because its error rate is low. It is ready when the team can explain every failed transaction and restore the previous path without creating a second incident.

Related:system modernization and migration guidance, useful when the extraction must improve maintainability without abandoning production continuity.

Routing principle: Keep one authoritative write path; move traffic through controlled cohorts.

• Replicate changes through durable events or change-data-capture.
• Use dual writes only with idempotency, visible failures, and reconciliation.
• Verify reversal or replay before widening traffic.

Data migration without freezing the business

Data migration is safe when the business can continue making changes while the new model catches up, and when reconciliation proves that both sides represent the same business state. A one-time export followed by a weekend cutover is rarely enough for a system that keeps accepting orders, payments, bookings, or shipment updates.

We break the work into a short chain of verifiable states:

• Inventory: identify tables, records, jobs, reports, and integrations that touch the domain.
• Baseline: capture counts, checksums, status distributions, and representative records.
• Backfill: copy historical data into the new model without changing production ownership.
• Catch-up: apply changes created during the backfill through CDC, an event stream, or a controlled change log.
• Shadow: run the new logic against production-shaped inputs without affecting the customer outcome.
• Compare: reconcile outputs, state transitions, totals, and exception cases.
• Cut over: transfer ownership for a defined cohort and monitor the business result.

Checksums alone do not prove correctness. Two records can have identical row counts and different meanings because a status mapping, timezone, currency, or null-handling rule changed. Reconciliation must be expressed in business terms: orders by site and status, balances by account, shipments by lifecycle stage, or invoices by settlement period.

We also separate historical migration from live ownership. A new service may need ten years of customer records for read access, but it does not need to own every historical correction on its first day. Start with the smallest live responsibility that proves the boundary.

There is a practical reason to keep the old path operational during this period: rollback is easier when the old system still has a known state and a supported operational procedure. Deleting tables, changing identifiers, and removing jobs before the new path has passed reconciliation turns a reversible migration into a recovery project.

For organisations handling sensitive customer, financial, or operational data, governance must travel with the data model. Define retention, access, audit events, masking, recovery objectives, and who approves a correction. Data governance and management practices are relevant here because a migration that preserves rows but loses lineage has not preserved operational control.

The economics of ownership also affect the migration. A local senior engineer in Singapore carries base salary, roughly 17 percent CPF, recruiting effort that can be around 20 percent of first-year salary, and a three-month ramp before the first shipped increment. That does not make internal hiring wrong. It means the decision must include the calendar and the delivery system, not only the salary line.

The table is not an argument to outsource architecture. It is an argument to buy a coherent delivery capability when the constraint is missing continuity across engineering, QA, infrastructure, and data. A pod should leave behind runbooks, tests, decisions, and an internal owner, not a dependency on individual heroics.

For resilience, test restore and replay before the cutover. A backup that has never been restored is an assumption. Data backup, recovery, and resilience controls belong in the migration plan when the old and new systems will coexist for months.

Migrate while the business keeps running

1. Inventory and baseline — Identify domain dependencies; capture counts, checksums, statuses, and representative records.
2. Backfill — Copy historical data without changing production ownership.
3. Catch up — Apply ongoing changes through CDC, events, or controlled change logs.
4. Shadow — Run new logic without affecting customer outcomes.
5. Compare — Reconcile outputs, state transitions, totals, and exceptions.
6. Cut over — Transfer ownership for a defined cohort; monitor business results.

Decommission checklist and rollback plan

Decommissioning is a production change, not the administrative last step of a migration. The old component can be removed only when its traffic, writes, jobs, reports, support procedures, and recovery dependencies have been proven unnecessary.

Our decommission gate has five decisions:

1. Traffic: all intended cohorts use the new path, and no untracked caller reaches the old endpoint.
2. Data: the new system owns the agreed records, with reconciliation inside the accepted tolerance and exceptions assigned.
3. Operations: alerts, dashboards, runbooks, on-call ownership, and access controls cover the new path.
4. Compliance: audit trails, retention, evidence, change approvals, and third-party responsibilities are documented.
5. Recovery: rollback or forward-recovery actions have been tested against a realistic failure, not merely written down.

The rollback plan should name the trigger, the decision-maker, the traffic action, the data action, and the customer communication. “Revert the deployment” is incomplete if the new path has already created records in a new store or sent an external command.

We distinguish traffic rollback from data rollback. Traffic can often return to the old implementation quickly. Data may need forward recovery: complete a pending state transition, reconcile a duplicate, or replay an event into the authoritative system. Pretending every migration can reverse data perfectly creates false confidence.

Keep the old component dark but deployable for a defined observation period. Disable new writes and scheduled jobs only after checking that no downstream process depends on them. Archive code and configuration with enough context for an incident responder to understand the last active version.

Do not decommission because the new service has been live for a calendar period. Decommission because the evidence says the old path no longer carries business responsibility. The evidence should include production traces, database access logs, job inventories, reconciliation results, and support confirmation.

Where the modernization includes automation or process redesign, keep the operational boundary explicit. Intelligent process automation and workflow controls can reduce manual work, but automation must not hide an unresolved ownership or approval path inside a migration.

Retire on evidence, not elapsed time: Remove the old component only after proving its responsibilities unnecessary.

• Verify traffic, data, operations, compliance, and recovery readiness.
• Name rollback triggers, decision-makers, traffic actions, data actions, and communications.
• Keep the old component dark but deployable during observation.

Where the strangler fig pattern is the wrong choice

The strangler fig pattern is the wrong choice when the system has no stable business seams, the data model must be replaced as one atomic unit, or the organisation cannot fund the parallel operation and observability required for incremental change. It is also a poor fit when the existing platform is so insecure or unsupported that continued operation creates greater risk than a controlled replacement.

We have rejected strangler plans where every transaction depended on shared mutable state and every service read the same tables directly. Extracting one endpoint would have produced two implementations with one hidden database contract. In that situation, the first task is boundary creation inside the monolith: modularise code, centralise access, add tests, and make ownership visible before moving runtime components.

A clean rebuild may be right under specific conditions:

• The business can tolerate a parallel operating period and has a verified cutover window.
• The domain rules are documented and the replacement can be tested against production history.
• The old platform has a security, licensing, or infrastructure constraint that cannot be mitigated safely.
• The organisation has permanent internal ownership for architecture, data, QA, platform operations, and support.
• Leadership accepts that the replacement is a business transformation programme, not a code-cleanup project.

Regulated financial services need an even stricter test. MAS TRM and APRA CPS 230 do not allow a firm to treat a third party as a substitute for accountable governance. If leadership cannot identify who approves the change, who monitors the service, who tests recovery, and who remains responsible for the customer impact, neither a strangler migration nor a rewrite is ready.

Our proprietary stance is that the common market answer, add more developers to the old backlog, does not solve a modernization capacity gap. Headcount without a tech lead, QA ownership, DevOps coverage, and a migration decision log spreads responsibility across more people. We would rather run a smaller delivery-owning pod against a defined seam than add individual bodies to a programme with no owner.

That stance has a limit. If the company’s permanent need is a core platform capability that will shape product strategy for years, hire the internal leader and build the team around that person. OmniStack is appropriate when the roadmap is real, the internal team is overloaded, and the business needs a consistent engineering, QA, UX, cloud, or data capability working directly against its priorities. Our engineers are on our payroll and on the client roadmap; delivery continuity sits with us rather than with the client’s hiring pipeline.

The decision to make before writing the first service

Do not begin with a microservice backlog. Begin with an architecture assessment that can answer six questions in writing:

1. Which business workflow is causing the greatest operational or roadmap constraint?
2. Where does that workflow enter, make decisions, write data, and emit external effects?
3. Which system is authoritative for each state transition today?
4. What is the smallest cohort that can prove the new path safely?
5. What evidence will permit wider routing or trigger rollback?
6. Who owns the outcome across engineering, QA, DevOps, data, operations, and compliance?

Score the first seam against business value, coupling, data risk, observability, reversibility, and team ownership. Do not select it because it makes the target architecture look impressive. Select it because the business can measure improvement and the team can contain failure.

For a multi-site operator, that may mean one warehouse or one operational workflow. For a funded scale-up, it may mean a bounded customer journey that is blocking product delivery. For a fintech, it may mean a non-settlement capability where audit and reconciliation can be proven before touching the ledger.

Write the migration charter before the implementation ticket. Name the old path, new path, system of record, traffic switch, success metrics, rollback trigger, data reconciliation method, and accountable owners. If any field is blank, the next action is not coding.

The strangler fig pattern works when each extraction reduces risk, clarifies ownership, and leaves the organisation with a stronger operating model than it had before. When the first seam cannot meet those conditions, stop and fix the boundary. The next decision is whether your current architecture can produce one reversible seam, or whether the assessment must first create one.

FAQ

What is the strangler fig pattern?

The strangler fig pattern is an incremental modernization approach in which new components replace parts of a legacy system while the existing system continues serving production traffic. Routing, data ownership, observability, and rollback controls determine when each responsibility moves.

Does the strangler fig pattern guarantee zero downtime?

No architecture pattern can guarantee zero downtime by itself. The pattern supports modernization without downtime by enabling controlled traffic shifts, shadow testing, reconciliation, and rollback. The result depends on the quality of operational controls and recovery testing.

Should every monolith become microservices?

No. A modular monolith may be the safer target when the domain has strong consistency needs, limited scale variation, or insufficient operational maturity for distributed systems. The strangler approach can modernize a monolith without requiring every extracted component to become a separate service.

When should a company hire internally instead of using a dedicated pod?

Hire internally when the capability is a permanent strategic differentiator and the organisation can support architecture, QA, platform operations, and product ownership without weakening current delivery. A dedicated pod fits a defined roadmap and capacity gap where continuity and outcome ownership are needed before the internal hiring pipeline can provide them.

What is the biggest risk in dual writes?

The biggest risk is creating two apparent systems of record without a reliable reconciliation process. If one write succeeds and the other fails, the design needs idempotency, durable change tracking, visible exceptions, and a clear authority for resolving conflicts.