The strangler fig pattern migrates a legacy PHP application gradually by placing a routing layer in front of it and moving functionality to new Node.js services one piece at a time. The old system keeps running until every route has moved, so healthcare platforms avoid risky big-bang cutovers.
Big-bang rewrites are risky for any organization, and especially for healthcare platforms that patients and staff rely on every day. The strangler fig pattern offers a safer alternative, and it underpins our PHP to Node.js migration services. This guide explains how it works, how to apply it in healthcare and which pitfalls to avoid.
What the Strangler Fig Pattern Is
The strangler fig pattern takes its name from a type of fig that grows around a host tree, gradually replacing it until the original tree is gone. Software architect Martin Fowler popularized the term to describe incremental system replacement. Instead of building a new system alongside the old one and switching over on a single day, teams wrap the legacy application with a routing layer and replace functionality piece by piece. Users continue working throughout. Each piece moves only after it is tested and proven, and the old system shrinks steadily until it can be switched off completely.
Incremental Replacement
Functionality moves in small pieces, often one route, screen or service at a time. Each piece is rebuilt, tested and released independently. This keeps every change small enough to understand, verify and reverse if something unexpected happens after release. Progress stays steady.
The Routing Layer
A routing layer, such as a reverse proxy or API gateway, sits in front of both systems. For each request, it decides whether the PHP application or a new Node.js service answers. Changing a routing rule moves traffic, and changing it back rolls it back instantly.
Both Systems Run Together
During migration, the PHP application and new services run side by side. Users see one system, one address and one sign-in. Behind the scenes, requests flow to whichever system currently owns that functionality, so the transition stays invisible to patients and staff.
The Old System Shrinks
As each piece moves, its PHP code is removed or disabled. The legacy application gets smaller with every release, which reduces patching effort and attack surface. Eventually no traffic reaches PHP, and the old application can be archived and its servers retired.
Contrast With Big-Bang Rewrites
Big-bang rewrites build a complete replacement and switch over all at once. Problems surface only after launch, when they affect everyone simultaneously. The strangler fig pattern spreads risk across many small releases, so problems are found early and affect fewer users.
Not Only for Node.js
The pattern works for any migration, including moving to a newer PHP framework, a different language or a modern front end. Our re-platforming services apply it to legacy stacks such as .NET Framework and Java EE as well. The principle stays the same.
Why the Pattern Suits Healthcare Platforms
Healthcare platforms have characteristics that make incremental migration especially valuable. They run continuously, often supporting patients and clinicians around the clock. They encode complex clinical, billing and consent rules that must not change accidentally. They connect to many external partners with their own schedules and testing requirements. And they handle protected health information, so every change must be controlled and documented. The strangler fig pattern addresses each of these needs by keeping changes small, reversible and verifiable. The points below explain why it has become the default approach for modernizing healthcare PHP applications safely.
Patients Cannot Wait for a Weekend Outage
Clinical systems cannot go offline for long cutovers. Incremental migration moves functionality during normal operations, usually in low-traffic windows, with no planned downtime. Patients keep booking, messaging and accessing records throughout. Our zero-downtime migration guide explains cutover techniques in detail.
Business Rules Need Proof
Eligibility, scheduling, consent and billing rules must behave exactly as before. Small increments make it practical to test each rule thoroughly, compare outputs between systems and fix differences before users are affected, rather than discovering problems across the entire platform after launch.
Integrations Move on Partner Schedules
Clearinghouses, payers and EHR vendors may require testing windows and formal approvals. Incremental migration lets each integration move when its partner is ready, rather than forcing every connection to change on the same day, which is rarely achievable in healthcare environments.
Compliance Evidence Accumulates
Each increment produces test results, approvals and change records. Over the program, this builds a strong evidence trail for auditors and customers. Compliance teams can update risk analyses phase by phase rather than reviewing an entirely new system at once.
Value Arrives Early
Patients and staff benefit from improved modules within months rather than waiting for a full rewrite. Early value builds support among leadership and users, making it easier to sustain funding and cooperation throughout a longer migration program. Feedback improves later phases.
Risk Stays Manageable
If a migrated module has problems, only that module is affected, and traffic can return to PHP immediately. This containment is especially important for systems handling patient care, revenue and protected health information, where widespread failures carry serious consequences. Failures stay small.
Building the Routing Layer
The routing layer is the heart of the strangler fig pattern. It must be reliable, fast, secure and easy to change, because every request passes through it and every migration step depends on it. A poorly designed routing layer becomes a bottleneck or a single point of failure, while a good one makes migration steps routine and reversible. Healthcare platforms also need the routing layer to preserve security controls, logging and session behavior consistently across both systems. The choices below shape how well the routing layer supports the migration from the first module through final decommissioning.
Choosing the Technology
Common options include reverse proxies such as NGINX, cloud load balancers, API gateways and framework-level rewrites in Next.js. The right choice depends on your hosting, traffic patterns and team skills. Simpler options are usually better, provided they support fast, safe routing changes.
Routing by Path and Method
Most routing decisions are based on URL paths and HTTP methods, such as sending all appointment endpoints to a new scheduling service. Clear, consistent URL structures make routing easier. Where URLs are messy, introducing a cleaner API layer early simplifies later migration steps.
Feature Flags for Gradual Rollout
Feature flags let teams route specific users, locations or percentages of traffic to new services. This allows internal testing, pilot groups and gradual rollout before all users switch. Flags also provide an instant way to disable a new service if problems appear.
Consistent Security Controls
The routing layer must enforce consistent security headers, TLS settings and rate limits for both systems. Authorization still happens in each service, but common protections at the edge reduce the chance that migrated routes accidentally weaken the platform’s overall security posture.
Centralized Logging and Monitoring
Every request through the routing layer should be logged with the destination system, response time and status. Central monitoring shows how traffic splits between PHP and Node.js, and highlights errors or slowdowns quickly after each routing change goes live. Dashboards show progress too.
Managing Routing as Code
Routing rules should be stored in version control and deployed through automated pipelines, with reviews and change records. Our healthcare CI/CD implementation work sets up these pipelines, so every routing change is traceable and reversible. Auditors can see exactly who changed what and when.
Choosing What to Move First
The order in which functionality moves has a large effect on risk, momentum and stakeholder confidence. Moving the most complex module first often leads to long delays and early frustration, while moving trivial pieces first may not prove the approach convincingly. The best sequence balances value, risk and learning. Early moves should be meaningful enough to demonstrate benefits and test the tooling, but contained enough that problems are manageable. The considerations below help teams build a migration order that delivers early wins while protecting the most critical clinical and financial functions until the approach is proven.
Start With Foundations
Shared capabilities such as identity, logging, configuration and deployment pipelines come first, because every later module depends on them. Building them early avoids rework and ensures each migrated module follows the same security, monitoring and release practices from the beginning.
Pick a Visible, Contained First Module
A good first module delivers visible value but limited risk, such as reporting, notifications or a read-only patient view. Success here proves the routing layer, tooling and team workflow in production, building confidence for more complex modules that follow later.
Follow Domain Boundaries
Move functionality by business domain, such as scheduling, messaging or billing, rather than by technical layer. Domain-based moves keep related rules together, reduce cross-system dependencies and make it easier to test complete workflows rather than fragments of them. Ownership stays clear.
Leave the Riskiest Logic Until Proven
Core clinical and financial logic should move after the approach is proven on lower-risk modules. By then, the team understands the tooling, testing and cutover process well, which reduces the chance of errors in the parts of the platform where mistakes matter most.
Consider Integration Readiness
Some modules depend on external partners who need advance notice or testing windows. Factor partner readiness into the sequence, so modules move when their integrations can move too. Our migration timeline guide explains how partner schedules affect sequencing. Book windows early.
Retire Instead of Migrating
Usage analysis may reveal routes and features that are rarely used. Retiring them instead of migrating them reduces scope and speeds the program. Business owners should confirm each retirement, but removing unused functionality is often the easiest win available. Less scope helps.
Handling Shared Data and Sessions
The hardest technical challenges in strangler fig migrations usually involve data and sessions shared between the old and new systems. Both systems may need to read and write the same records, and users must stay signed in as they move between PHP and Node.js features. Getting these right is essential in healthcare, where data integrity affects patient safety and billing accuracy, and where sessions protect access to protected health information. The approaches below help teams manage shared data and authentication safely throughout the migration, without forcing a risky big-bang data move at the start.
Sharing the Existing Database
In early phases, new services often connect to the existing PHP database. This avoids an immediate data migration and lets both systems work with the same records. Clear rules about which system owns which tables prevent conflicting updates and corrupted data.
Defining Data Ownership
Each table or domain should have one owning system responsible for writes, with others reading through defined interfaces. Ownership moves from PHP to Node.js as modules migrate. Documented ownership prevents subtle bugs caused by two systems updating the same data differently.
Moving Data Later
Schema improvements or moves to another database, such as PostgreSQL, can happen once new services are stable. Our MySQL to PostgreSQL guide explains how to move healthcare data safely with encryption and validation at each step. Timing should follow benefits, not urgency.
Shared Authentication
Users must stay signed in as requests move between systems. A shared identity provider using OpenID Connect, or a bridge that lets new services trust PHP sessions, keeps authentication consistent. Our authentication migration guide covers this in detail. Nobody signs in twice.
Consistent Authorization Rules
Both systems must apply identical permission rules for every role. Automated tests should confirm that each role can and cannot perform the same actions in PHP and Node.js, preventing accidental access to patient records or unexpected lockouts during transition. Tests run constantly.
Audit Logging Across Systems
Audit logs from both systems should share formats, user identifiers and timestamps, and flow into one central store. Investigators can then follow user activity regardless of which system handled each request, keeping compliance evidence complete throughout the migration. Gaps get flagged.
Testing, Rollback and Cutover
Each step in a strangler fig migration ends with a cutover, where traffic moves from PHP to a new service. Cutovers must be tested, monitored and reversible. In healthcare, they must also be scheduled around clinical operations, billing cycles and partner availability. A disciplined cutover process turns migration from a series of risky events into routine operations that teams can perform confidently. The practices below help ensure every cutover is safe, from verifying behavior before release to confirming success afterward and retiring the replaced PHP code promptly so the legacy system keeps shrinking.
Characterization Tests First
Before migrating any route, capture its current behavior in automated tests. The new service must pass the same tests. Our characterization testing guide explains how to build these tests for legacy PHP code effectively. Failures block each release automatically, which protects patients and revenue.
Parallel Running for Critical Logic
For billing, eligibility and other critical calculations, both systems can process the same requests while only one result is used. Outputs are compared automatically, and differences are resolved before cutover, catching subtle behavior changes that tests alone might miss. Finance approves results.
Staged Rollout
New services are enabled first for internal users, then a pilot group, then everyone. Each stage is monitored for errors, performance and user feedback. Staged rollout limits the impact of any problem and builds confidence gradually across the organization. Feedback shapes fixes.
Instant Rollback
Every cutover has a tested rollback plan, usually a single routing change that sends traffic back to PHP. Rollback should take seconds, not hours. Knowing problems can be reversed quickly lets teams release confidently and reduces pressure during cutover windows.
Monitoring After Cutover
After each cutover, monitor errors, response times, business metrics and user feedback closely. Compare results with the PHP baseline. Early monitoring catches issues while they are small, before they affect many patients, staff members or partner transactions. Problems then stay small and fixable.
Removing Replaced PHP Code
Once a migrated route is stable, remove or disable the corresponding PHP code. Leaving it in place creates confusion and security risk. Prompt removal keeps the legacy application shrinking and makes final decommissioning simpler when the last route moves. Shrinking continues.
Common Pitfalls and How to Avoid Them
The strangler fig pattern is proven, but it is not foolproof. Teams that apply it without discipline can end up running two systems indefinitely, duplicating logic or creating new complexity that outlasts the migration itself. Most pitfalls are predictable and avoidable with clear planning, ownership and regular review. Knowing them in advance helps healthcare teams keep migrations on track and ensures the pattern delivers its promised benefits. The pitfalls below are the ones we see most often, along with practical ways to avoid them in your own migration program. Avoidance is cheaper.
Never Finishing the Migration
Some programs migrate the easy parts, then stall, leaving two systems running indefinitely. Set clear goals, timelines and decommissioning dates for the PHP application, and track progress publicly. Treat finishing as seriously as starting, or costs and complexity will keep growing.
Duplicating Logic in Both Systems
Fixing bugs or adding features in both PHP and Node.js doubles effort and risks inconsistency. Once a module moves, make changes only in the new service. Freeze related PHP code, so the old and new implementations do not drift apart over time.
Weak Data Ownership
When both systems write to the same tables without clear rules, data corruption follows. Define ownership for every table, enforce it through code reviews and transfer ownership deliberately as modules move. Data integrity problems in healthcare can affect patient safety and billing.
Overcomplicated Routing
Routing layers with hundreds of special cases become hard to understand and risky to change. Keep routing rules simple, grouped by domain and documented. Clean URL structures and an API layer introduced early make routing far easier to manage throughout migration.
Skipping Tests to Save Time
Under schedule pressure, teams sometimes skip characterization tests or parallel running. This saves time briefly but leads to defects, rework and loss of trust. Protect testing in the plan, especially for clinical and financial logic where errors carry serious consequences.
Ignoring the People Side
Clinicians, staff and partners need communication, training and support as functionality moves. Technical success means little if users are confused or partners are surprised. Our Legacy PHP Platform Assessment includes stakeholder planning alongside technical findings. People make migrations succeed or fail.
Frequently Asked Questions
Healthcare technology leaders often ask how the strangler fig pattern works in practice, how long it takes and how it compares with a full rewrite. The answers below reflect our experience applying the pattern to legacy PHP platforms for providers, payers and digital health companies. They are general guidance rather than a plan for your specific system, so treat them as a starting point. If you would like help applying the pattern to your platform, our team can review your architecture and recommend a routing approach, migration order and cutover plan.
What is the strangler fig pattern in simple terms?
It replaces an old system gradually. A routing layer sends each request to either the old PHP application or a new service. Functionality moves piece by piece until the old system handles nothing and can be switched off safely. Risk stays low.
Is the strangler fig pattern slower than a full rewrite?
It may take similar or longer total time, but it delivers value much earlier and carries far less risk. Many full rewrites run late anyway, while incremental migration keeps the platform working and improving throughout. Users benefit along the way.
Do we need to change our database first?
No. New services usually share the existing database in early phases, with clear ownership rules. Database changes can happen later, once new services are stable and the benefits of changing the database are clear. Early changes add risk. See our database migration services.
How do users stay signed in across both systems?
A shared identity provider, often using OpenID Connect, or a session bridge lets both systems recognize the same user. Patients and staff move between old and new features without signing in again or losing access. Roles stay consistent too. Sessions persist.
Can the pattern work with a front-end rebuild?
Yes. Routing can send some pages to a new Next.js or React front end while others remain in PHP. Our PHP to Next.js migration approach uses the same incremental principles. Pages move individually, so patients see improvements early without any disruptive switch.
What happens if a migrated module fails?
Traffic is routed back to the PHP implementation, usually within seconds. The issue is investigated and fixed in the new service, then the module is released again after testing. Users experience minimal disruption. Rollback is rehearsed beforehand. Learning continues. Nothing is lost.
Tell Us About Your PHP Platform
Tell us about your PHP application, its modules and integrations. We will recommend a routing approach and a safe first module to move. We will also outline likely phases and risks, with no obligation to proceed. Book a free consultation.