Application Modernisation: The Strangler-Fig Pattern in Practice

Application Modernisation: The Strangler-Fig Pattern in Practice

Application modernisation is the process of incrementally replacing or re-architecting legacy software systems to meet current operational, business, and technology requirements. For Australian engineering teams sitting on ageing .NET or Java monoliths, the question is rarely whether to modernise — it is how to do it without stalling product delivery or introducing catastrophic risk.

This post covers the three core modernisation strategies, explains why the strangler-fig pattern is the most practical approach for most mid-market organisations, and outlines the common Australian business triggers that make modernisation urgent.

---

What Are the Three Application Modernisation Strategies?

Before choosing a path, it helps to understand what the options actually mean in practice. Three strategies dominate most modernisation programmes:

Lift-and-Shift (Rehost)

Lift-and-shift means moving an existing application to the cloud with minimal code changes — typically to IaaS (Infrastructure as a Service) on AWS, Azure, or GCP. The application architecture stays the same; only the infrastructure changes.

When it makes sense: You need to vacate an on-premises data centre quickly, or reduce infrastructure management overhead before a deeper modernisation phase.

Limitation: You carry all the original architectural debt into the cloud. Performance, scalability, and developer experience problems do not go away. Cloud costs can actually increase if the application was not designed for elastic compute.

Re-Platform (Move and Improve)

Re-platforming involves migrating to the cloud while making targeted changes to take advantage of managed services — replacing a self-managed SQL Server instance with Azure SQL Managed Instance, for example, or moving batch jobs to serverless functions.

When it makes sense: The core application logic is sound, but specific infrastructure components are creating operational overhead or cost inefficiency.

Limitation: Still bounded by the monolithic application structure. Deployment coupling, test suite fragility, and team bottlenecks often persist.

Re-Architect (Refactor or Rebuild)

Re-architecting means changing the fundamental structure of the application — decomposing a monolith into services, adopting event-driven patterns, or replacing a tightly-coupled system with loosely-coupled components.

When it makes sense: The application's architecture is the primary constraint on feature velocity, reliability, or scalability.

Risk: Big-bang rewrites — where you stop shipping features and rebuild everything in parallel — have a poor track record. The strangler-fig pattern addresses this directly.

Strategy	Code Change	Cloud Benefit	Risk Level	Best For
Lift-and-Shift	Minimal	Low	Low	Data centre exit, quick wins
Re-Platform	Moderate	Medium	Medium	Targeted infrastructure improvement
Re-Architect	Significant	High	High (if big-bang)	Long-term scalability and velocity

---

What Is the Strangler-Fig Pattern?

The strangler-fig pattern is an application modernisation technique where new functionality is built as independent services alongside an existing monolith, and legacy components are progressively replaced — rather than rewritten all at once.

The name comes from the strangler fig tree, which grows around a host tree and gradually replaces it. Martin Fowler described the pattern in 2004, and it has become the industry-standard approach for large-scale legacy migration precisely because it manages risk through incrementalism.

The core mechanics:

1. Intercept — A routing layer (API gateway, reverse proxy, or event router) sits in front of the monolith. New requests can be directed to either the legacy system or new services.
2. Divert — New features are built as standalone services. As each service matures and stabilises, the corresponding monolith code is switched off.
3. Eliminate — Over time, the monolith shrinks. Eventually, it is either fully replaced or reduced to a thin residual layer.

The organisation never stops shipping. At every point in the process, there is a working, deployable system.

---

Why the Strangler-Fig Pattern Works for .NET and Java Monoliths

Legacy .NET Framework and Java EE applications are the most common modernisation candidates in Australian mid-market technology companies. They share a recognisable profile: built in the 2005-2015 era, running on-premises or in co-location, with tightly coupled business logic, SQL Server or Oracle databases, and deployment cycles measured in weeks.

The strangler-fig pattern fits this profile well for several reasons:

Preserves working code. The monolith continues to run in production throughout the process. You are not rewriting proven business logic from scratch — you are extracting and replacing it module by module.

Reduces deployment risk. Each extracted service can be tested, deployed, and monitored independently. A problem in one service does not require rolling back the entire application.

Enables team parallelism. Once the routing layer is in place, one team can work on the monolith while another builds new services. Velocity increases as the decomposition progresses.

Creates natural boundaries. The decomposition process forces explicit conversations about domain boundaries — often surfacing implicit coupling that was never formally documented. This is valuable architecture work regardless of the destination architecture.

Practical Starting Points

Not all monolith components are equal candidates for early extraction. High-value starting points tend to be:

• High-change areas — modules that are modified frequently and create deployment bottlenecks for the rest of the application.
• Independently scalable components — report generation, PDF rendering, notification dispatch, or batch processing jobs that have different resource profiles from the core application.
• New product requirements — net-new features that do not need to touch existing monolith code can be built as services from day one.
• Integration surfaces — third-party API integrations or customer-facing APIs that are being actively consumed and need stability guarantees.

---

What Triggers Application Modernisation in Australian Organisations?

Modernisation programmes rarely start from a blank-slate strategic review. In our experience working with Australian technology teams, they are almost always triggered by a specific operational or business pressure.

Cloud Cost Optimisation

Australian organisations that completed lift-and-shift migrations during the 2019-2022 period are now confronting cloud bills that did not match the business case. Applications designed for dedicated on-premises hardware do not automatically become cost-efficient in the cloud — they often become more expensive unless the architecture changes.

Re-platforming to managed services and decomposing compute-intensive workloads into event-driven or serverless components are the primary levers. This is a legitimate forcing function for a modernisation programme that has strategic value well beyond cost.

Talent Attraction and Retention

Engineering talent in Australia is competitive, and candidates evaluate technology stack as part of the employment decision. A monolithic .NET Framework 4.x application running on Windows Server 2012 is a meaningful hiring obstacle — particularly for mid-career engineers who have options.

Modernisation to current .NET (formerly .NET Core), containerised workloads, and cloud-native infrastructure makes a direct difference to the quality of engineering talent a team can attract. It also reduces onboarding friction for new hires who are unfamiliar with older toolchains.

AI Integration Requirements

This is the most rapidly emerging trigger in 2024-2025. Organisations that want to integrate AI capabilities — retrieval-augmented generation, intelligent document processing, real-time inference, or ML-powered features — into their products face a structural problem: tightly coupled monoliths make AI integration genuinely difficult.

AI services need clean API boundaries, event streams or data pipelines, and infrastructure that supports model serving. A monolith that cannot expose clean internal APIs or consume asynchronous events is a significant obstacle to any AI product strategy. Application modernisation is frequently the prerequisite work that makes AI adoption possible.

End-of-Life Infrastructure and Compliance

Windows Server 2012 reached end of extended support in October 2023. SQL Server 2012 reached end of support in 2022. For organisations still running applications on these platforms, the combination of security exposure and inability to meet compliance requirements — particularly in financial services and healthcare — creates a hard deadline that discretionary modernisation programmes do not.

---

How to Sequence a Strangler-Fig Modernisation Programme

A well-structured modernisation programme follows a phased approach. The specifics depend on the application, the team, and the organisation's tolerance for parallel-running complexity — but a typical sequence looks like this:

Phase 1: Architecture Review and Domain Mapping (2-4 Weeks)

Before extracting anything, you need a clear picture of what you have. This means mapping the monolith's domain boundaries, identifying coupling hotspots, assessing the data model, and reviewing infrastructure. The output is a prioritised decomposition roadmap — not a rewrite blueprint, but a sequenced list of extraction candidates with rationale.

This phase also establishes the baseline: current deployment frequency, incident rate, and test coverage. You need these numbers to measure progress.

Phase 2: Routing Layer and First Extraction (4-8 Weeks)

The routing layer is the technical foundation of the strangler-fig approach. An API gateway or reverse proxy is placed in front of the monolith, capable of directing traffic to either the legacy application or new services based on routing rules.

Once the routing layer is in place, the first extraction begins. Choosing a well-bounded, lower-risk component for the first extraction builds team confidence and proves the pattern before tackling higher-stakes domains.

Phase 3: Iterative Extraction (Ongoing)

Subsequent extractions follow the same pattern: identify the next candidate, build the replacement service, migrate traffic incrementally (using feature flags or percentage-based routing), validate behaviour, and decommission the monolith code.

Each iteration tightens the team's muscle memory for the process and reduces the complexity of subsequent extractions.

Phase 4: Data Decoupling

Shared database schemas are often the hardest part of monolith decomposition. Services that share tables with the monolith cannot be fully independent. Data decoupling — progressively separating the data layer to match service boundaries — is typically done in parallel with the application decomposition, not as a prerequisite.

This work requires careful sequencing to avoid dual-write complexity and data consistency issues during the transition period.

---

Application Modernisation and AI Readiness

There is a direct relationship between application modernisation and an organisation's ability to adopt AI at the product level. Monolithic architectures create several specific obstacles:

• No internal API surface — AI services need to call application logic and retrieve data through clean interfaces. A monolith with no internal API layer cannot be integrated with without modifying the core application.
• No event stream — Many AI use cases (real-time personalisation, anomaly detection, intelligent notifications) depend on event-driven data flows. Monoliths that write only to relational databases do not produce the event streams these systems require.
• No independent deployment — AI model versions need to be updated independently of the core application. Deployment coupling makes this impractical.

Modernisation to a services architecture removes these blockers. Once an application exposes clean APIs and produces event streams, integrating AI engineering capabilities becomes an engineering task rather than an architectural problem.

This is increasingly why Australian organisations are treating application modernisation not as a pure infrastructure exercise, but as a strategic precondition for product AI adoption.

---

What to Look for in an Application Modernisation Engagement

Any modernisation programme carries risk. The most common failure modes are not technical — they are organisational:

Scope creep into big-bang rewrite territory. The strangler-fig approach works because it is incremental. Programmes that start with "we'll just do the routing layer" and expand to "let's rebuild the whole thing" lose the risk management benefit of the pattern.

Data decoupling underestimated. Application code is often easier to extract than database dependencies. Programmes that do not explicitly plan for data decoupling discover this problem mid-stream.

Testing coverage debt. Extracting a service from a monolith without adequate test coverage of the original behaviour is high-risk. Building a characterisation test suite before extraction is standard practice, not optional.

Team knowledge transfer. The destination architecture needs to be owned and maintained by the internal team after the engagement. A modernisation that leaves the team dependent on an external partner for ongoing operations has not achieved its goal.

Our application modernisation engagements are structured around all four of these risk areas — with explicit handoff milestones, test coverage requirements, and documentation standards built into the programme from the start.

---

Frequently Asked Questions

How long does a strangler-fig modernisation take?

This depends heavily on the monolith's size, complexity, and the organisation's appetite for parallel-running complexity. A focused extraction of two or three high-priority domains can be delivered in three to six months. Full decomposition of a large enterprise monolith typically takes twelve to thirty-six months of iterative work.

Do we need to stop shipping features during modernisation?

No — and this is one of the primary reasons the strangler-fig pattern is preferred over big-bang rewrites. The monolith continues to operate in production throughout the process. Feature development can continue on the monolith while extraction work happens in parallel, though teams need to manage the additional coordination overhead.

What happens to the database?

The shared database is usually the last thing to decompose, not the first. Initial service extractions typically still read from the monolith's database while establishing their own write paths. Progressive data decoupling follows a separate track from application decomposition and requires careful planning to manage consistency during the transition.

Is .NET Framework code compatible with modern .NET?

Mostly, but not always. The migration from .NET Framework to .NET 6/7/8 involves API surface changes, particularly for Windows-specific components (WCF, Web Forms, certain System.* namespaces). A thorough architecture review will identify specific compatibility blockers before the programme begins.

---

Further Reading

For related topics across our insights library:

• Data Infrastructure: Building the Foundation for AI — modernisation programmes that feed into AI adoption need data infrastructure to match.
• Fractional CTO: Strategic Technology Leadership Without the Full-Time Cost — for organisations that need architecture leadership to guide a modernisation programme without a full-time hire.

---

If your team is carrying legacy .NET or Java architecture that is constraining feature velocity, blocking AI adoption, or creating cloud cost problems, we can help you build a clear-eyed modernisation roadmap and deliver it incrementally. Start with a technical architecture review or get in touch to talk through your specific situation.