Skip to main content
Back to Blog
Legacy Modernization

No Downtime Strangler Fig Modernization for Enterprise Engineers

February 202611 min read
No downtime strangler fig modernization for enterprise engineers

Strangler fig modernization is the technique of slowly retiring a legacy system by introducing new services to surround the old one, and a proxy to direct traffic to these services until the old code base is starved of responsibility. Fowler named the pattern after a fig vine that grows around another tree and in time replaces it. Pick this pattern for modernization when you want to continuously deliver new functionality, but are at risk of failing a big-bang rewrite. Do not pick it if the system is small enough to just rebuild outright.

TL;DR:

  • The pattern is a good fit if the system is large, frequently changing and needs continuous delivery.
  • The pattern is not a good fit if the system is small or well understood and can be replaced in a short time.
  • Migration is often based on some sort of staged approach: CDC or dual-write. Validating both approaches before final cutover is critical to prevent data drift.
  • Operating two systems in parallel adds operational complexity and risk. It must be managed through extensive testing, monitoring, and clear ownership of each slice of the migration.
  • Rerouting traffic slowly through a façade from 100% legacy to 100% new implementation reduces risk, and database writes are only shifted once read consistency is reached.

PODTECH

Modernise legacy systems incrementally. PODTECH provides custom-built enterprise software for legacy modernisation, critical infrastructure integration and scalable digital platforms.

Learn More at PODTECH

Table of Contents

How the strangler fig pattern actually works

The term is a metaphor for an actual biological event: a fig vine grows up around a tree, sending down its own roots, and outliving the tree which it has engulfed. Fowler's initial definition related this image to software that gradually replaces legacy components, rather than being done in one go.

The mechanics behind it is a façade. A proxy layer between the users and the back end, which determines whether to send requests to the legacy system or the new services. Developers identify “seams”. Natural boundaries in the codebase where they can extract functionality with low coupling. A reporting module. A payments flow. An authentication service. Each seam is a slice: build the new version, route a slice of traffic to it via the façade, observe how it behaves, then grow the routing rule until the legacy path is no longer handling anything for that feature.

UsersRequests enterFaçadeRoute by seamflag or %Legacy MonolithStarts at 100%New ServiceGrows slice by slice100% → 90% → 50%0% → 10% → 50% → 100%

When should you choose the strangler fig pattern?

Use this strategy when the system is large, feature requests are frequent, and stakeholders are comfortable with incremental delivery rather than a single cutover date. It works well for monoliths with a high frequency of change where a rewrite will prevent new features for months.

Migration becomes infeasible in a few scenarios: lack of source code, system small enough to build a replacement in a sprint or two, team without the discipline to safely run both systems in parallel. Business requirements are as important as technical considerations. A compliance deadline, infrastructure sunset date, or scaling threshold on the legacy platform are all reasons to start today. Seek stakeholder alignment early. A phased plan without executive sponsorship will often be cancelled midway through, leaving you stuck in the worst of both worlds.

What are the core components: façade, ACL and adapters?

Three building blocks make gradual replacement safe rather than reckless.

The façade or proxy lives at the front door and routes each request to its destination. There are three common placement choices:

  • API gateway: centralised routing, good for HTTP-based systems with many consumers.
  • Reverse proxy: lightweight, works well when you control network infrastructure directly.
  • Sidecar: it can be used to attach routing logic to each service instance. Useful in containerised environments, where adding a gateway introduces a single point of failure.

The anti-corruption layer (ACL) performs translations between the data model of the legacy system and the new service’s model so the new code never has to speak the old system’s quirks directly. AWS’s guidance on the pattern positions the ACL along with the façade as the two structural components that make coexistence possible, with adapters taking care of format conversion, field mapping and protocol translation between the two worlds.

Cutover itself is dependent on routing rules, versioning and feature flags. Percentage based routing can let you send 5% of traffic to the new path, watch error rates and then dial up. Feature flags can let you roll back a slice instantly without a deployment. Consider the ACL and its adapters as a temporary measure. Canonical guidance is explicit that transitional code be scheduled for removal once cutover completes, and not left to calcify into permanent technical debt.

How do you migrate data without breaking anything?

Data. The single largest implementation challenge in most strangler fig projects. The simple fact is that legacy data almost never maps in any direct fashion onto new domain types. Three strategies dominate:

  • ETL (extract, transform, load): batch jobs that move data on a schedule; simple, but has latency between systems.
  • CDC (change data capture): captures and streams changes from the legacy database as they occur. CDC keeps the new store closer to real time.
  • Dual-write: the application writes to both systems at the same time; quick to implement but can suffer from drift if one of the writes fails silently.

Micrsoft's Azure Architecture Center describes a fairly standard progression that most teams will arrive at: read-through against the monolith first, then CDC replication into a domain-specific store, then a validated cutover of writes. Validating before cutover involves running contract tests and reconciliation jobs that compare record counts and checksums between old and new stores. Don't migrate historical data on day one unless a particular feature needs it. If your organisation runs polyglot persistence, different databases for different services, plan the ACL to normalise formats before data lands in any new store, not after.

A phased checklist for every migration slice

Pick your first slice based on three signals: low coupling to other modules, clear ownership, and sufficient traffic to validate the approach but insufficient blast radius to sink a launch if something goes wrong. A reporting endpoint or an internal facing feature makes a better first slice than checkout.

For each slice, run the same sequence:

  1. Design the new service and its ACL, and map every field the legacy system exposes
  2. Create the façade route that can route to either system depending on a flag or a %
  3. Develop the new service separately, with its own CI/CD and test suite.
  4. Test using contract tests against the legacy interface to confirm behavioural parity.
  5. Validate with a small percentage of live traffic, monitoring error rates and latency.
  6. Cut over completely once validation is good for an agreed upon window, then decommission the legacy code path for that slice.

Rollback windows must be available for at least one full business cycle after each cutover. This may be a week for a payments slice; a day for a low-traffic internal tool.

SliceOps Pro Tip: Treat each slice like its own small product with its own deployment pipeline and monitoring dashboard. It's overhead, yes, but it's what makes a bad slice a few hours of downtime instead of days.

What operational risks come with running two systems at once?

Running old and new systems in parallel for months, sometimes years, has its own genre of risk independent of code quality.

Dual-run systems accrue technical debt: two log sets, two deployment pipelines, two on-call rotations. Left unchecked, that overhead outlives the migration process itself. As Fowler's own commentary on the pattern observes, practitioners almost universally report managing both systems is the most fatiguing part of the effort, more draining than any discrete engineering challenge.

Mitigate it with:

  • Contract tests that allow you to detect behavioural drift between legacy and new interfaces prior to production.
  • Canary releases: expose new code to a small portion of real monitored traffic.
  • Observability and alerting specially tailored to the façade layer, where routing failures are concealed.
  • Ownership for each slice is clear, so no one relies on "someone else" watching the legacy path.

Release discipline is more important here than with a normal sprint cadence. Each routing change is a de facto production deployment, even when no code is shipping.

What do real routing and cutover implementations look like?

Imagine an API Gateway receiving a request. It consults a routing table. Does this endpoint live on the legacy monolith or the shiny new payments service? Initially 100% of the traffic goes left, to the monolith. Over time, as confidence increases, the split moves to 90/10, then 50/50, then 100% right.

Database cutover has a similar trajectory: reads continue against the monolith, while change data capture streams writes into a new domain-specific store, contract tests ensure the two agree, and only then is the application switched to use the new write path. Adapter choice is governed by your infrastructure: a sidecar if you're a containerised, Kubernetes-native team; an API gateway if you're an organisation with many external consumers; an in-process façade if you're a smaller team who want to avoid adding another network hop. This is not wedded to a particular cloud vendor, the same principles apply whether you're running on bare metal or in a public cloud.

How did PODTECH apply this pattern in practice?

PODTECH’s system integration work used strangler fig principles in a legacy modernisation engagement with highly coupled infrastructure components. This approach broke the migration into discrete slices that were each routed through a façade layer while the underlying datastore migrated via a staged CDC and reconciliation process rather than a single cutover event.

The result was stability: the client continued running all the time, with no mandatory downtime period to work around. The single most important thing learned from the exercise was to set ACL and transitional code removal in stone, as a tracked task, rather than leave it for the moment when nobody needs it any more.

What do engineers get wrong about this pattern?

Teams approach the strangler fig pattern primarily as a technical solution and tend to under-appreciate the organisational challenge. The strangler fig pattern is not commonly associated with a single, fatal mistake. The greatest errors in applying the strangler fig pattern are not directly related to technical difficulties, such as the façade design or quality of the API. The single most important mistake teams can make is allowing dual-run systems to linger without an end date firmly set for each slice.

Three things to get right from day one: keep slices small enough that a rollback fits in an afternoon, give cross-functional teams ownership of a slice end to end rather than splitting frontend and backend work across separate groups, and measure everything at the façade layer before you measure anything else. The routing decision is where failures hide first.

— Harry

Get help planning your legacy modernisation

Executing a strangler fig migration successfully involves having the façade design, data reconciliation, and rollback planning all done correctly before the first slice is ever put into production. PODTECH builds that foundation right into its legacy software modernisation services, collaborating with enterprise teams that need a technical review before deciding whether to commit to a phased cutover plan.

Teams supporting intermittently connected users, or field-based data entry use cases during a migration should also read up on the sync patterns in Wells Manager’s guide to offline data capture in addition to their reconciliation strategy. In cases where your migration overlaps with datacentre infrastructure, telemetry construction, or BMS & PMS integration, PODTECH’s datacentre services team can help you discover where a façade and ACL approach is applicable to your legacy systems. Schedule a technical discovery to chart your first slice before you write your first line of migration code.

Sources

Recommended