Do You Replace the Whole Warehouse System at Once, or One Module at a Time?

A warehouse management system that has run since 2011 holds every pick rule, every carrier integration, and every exception workaround your operation depends on. Some of that logic is documented. Much of it lives in the heads of people who have worked on the floor for a decade. 

Replacing it in one weekend cutover is the fastest route to a new system. It is also the fastest route to a stopped floor. 

The strangler fig pattern is the alternative: replace the old system with one piece of functionality at a time, run both side by side, and switch the legacy system off only once it has no work left. 

The risk of the other route is measurable. Gartner surveyed 306 logistics professionals at organizations with $500 million or more in revenue and found that 76% of logistics transformations fail to meet their budget, timeline, or KPI targets (Gartner, August 2024). 

Three in four. That exposure scales with the size of the cutover, which is exactly what a full WMS or TMS rewrite maximizes. 

Key takeaways 

• The strangler fig pattern replaces a legacy system incrementally, routing traffic through a facade that sends each request either to the old system or to its replacement. 
• Martin Fowler named the pattern in 2001 after the strangler fig tree, which grows around a host until the host is gone. 
• It fits large systems where a single cutover carries real operational risk, which describes most WMS and TMS replacements. 
• Microsoft names four conditions that rule the pattern out, including requests that cannot be intercepted and forced quick decommissioning. 
• Choose the first module for how cleanly it separates, not for how much the business wants it to be replaced. 

How the strangler fig pattern works, and where the name comes from 

The strangler fig pattern replaces a legacy system with one function at a time. A facade, also called a proxy, sits in front of the old system and intercepts every incoming request, then decides whether it goes to the legacy code or to a new service that has taken that function over. No function moves until you move it. 

Picture it on your floor. Every scan, every dock terminal lookup; every order dropped by an upstream system hits the facade first. 

Day one, the facade sends almost all of that traffic straight to the old WMS. Behavior is identical. Nobody notices a change, because functionally there is none. 

Then you build a replacement for one function. Label printing, say. The facade starts routing label requests to the new service and keeps sending all other traffic to the legacy system. The picker scanning a carton sees the same screen they saw last week. 

Repeat for the next function. Then the next. The old system’s share of the traffic keeps shrinking until it answers no live requests at all, and you switch it off. The facade, now pointing out all traffic at the new system, can come out too. 

The name comes from a tree. Martin Fowler spent time in the Queensland rainforest in 2001 and watched strangler figs work: the fig seeds itself high in a host tree, sends roots down the trunk until they reach soil, and slowly wraps the trunk it grew on. The host dies and rots away. The fig stays, holding the exact shape of the tree it replaced. 

Fowler saw the parallel. He described the software version as a gradual process of modernization, where small additions are built alongside the legacy code and behavior moves across piece by piece. He first published it as a “strangler application,” then renamed it after the tree rather than the act. 

For a warehouse operation, the consequence is simple. There is no cutover weekend. Each module moves on its own schedule; each move is small enough to undo, and only the facade needs to know which system owns a given request today. 

Why a full WMS cutover is the riskiest week of your year 

A big bang replacement puts every risk in the business into one window. 

Pick logic, carrier rate tables, label printing, yard moves, inventory counts, and every downstream integration switch at the same moment. Any one of them failing stops order fulfillment. 

On a distribution floor, that is not a degraded experience. Trucks wait. Dock doors back up. The carrier cutoff passes with orders still unpicked, and the recovery eats into the next shift. 

The warehouse system migration risk that keeps operations leaders awake has a specific shape: the cutover lands close to peak season, one component behaves differently under real volume than it did in test, and the rollback runs longer than the window allows. 

Gartner’s 76% describes transformations of missing budget, timeline, or KPI targets. The odds of holding all three improve as the scope of a single release falls. Twelve releases give you twelve chances to catch a problem while the rest of the operation keeps running. One release gives you one. 

Incremental legacy migration has become the default recommendation for systems that cannot absorb downtime, and the reason is not speed. It is usually the slower route in total elapsed time. The reason is what failure costs: the bad version of an incremental migration costs you a module, while the bad version of the fast route costs you a week of fulfillment. 

Big bang rewrite or incremental migration: what each approach costs you

Strip the strangler fig vs. big bang rewrite debate down, and it is a trade-off between elapsed time and blast radius. 

A big bang rewrite wins on effort. You build one system once, never run two in parallel, and never pay for a facade. It finishes sooner and costs less in total engineering. It also concentrates every failure mode into a single event, with one rollback path that must work under pressure, on the day, at full volume. 

Strangler fig migration costs more. Two systems run at once, the facade needs building and operating, and data both systems touch must stay consistent for months. What that money buys is the ability to be wrong cheaply: each release is small, reversible, and tested against live traffic. 

For a TMS legacy replacement that touches carrier integrations and live shipment tracking, that trade usually favors the incremental route, because the cost of being wrong for one afternoon exceeds the extra engineering. For a small internal tool with three users and no integrations, it does not, and Microsoft says so explicitly. The deciding factor in any TMS legacy replacement is what a single bad afternoon costs for the operation, not what the engineering estimate says. 

When the strangler fig pattern fits, and when it does not 

Microsoft’s Azure Architecture Center documents both sides of this decision, and the conditions that rule the pattern out are stated plainly rather than left to judgment. The table below turns them into a check you can run against your own WMS or TMS before committing to an approach, and it is the step most warehouse system migration risk assessments skip. 

Your situation	Verdict	Basis
A facade can intercept requests to the legacy system	Pattern fits	Microsoft Azure Architecture Center
The system is large, and one cutover carries real operational risk	Pattern fits	Fowler, 2001; Gartner, 2024
Requests to the back-end system cannot be intercepted	Rules it out	Microsoft Azure Architecture Center
You cannot access the legacy system’s source code	Rules it out	Microsoft Azure Architecture Center
The system is small and replacing it wholesale is simple	Rules it out	Microsoft Azure Architecture Center
You need to fully decommission the original solution quickly	Rules it out	Microsoft Azure Architecture Center

Two of those rows deserve a closer look if you run a warehouse system. 

Source code access

Disabling a migrated feature inside the legacy system and redirecting its internal calls usually means editing legacy code. Where that code cannot be touched, Microsoft points to database-level routes instead: change data capture, or triggers that reach the new services without a code change. 

A forced quick decommission

This one removes the pattern’s entire benefit. If a license expires in ninety days and the old system must be dark by then, there is no room for a gradual handover. The decision becomes a rewrite against a hard deadline, whether you like the risk that carries. 

One further warning is worth taking seriously: the facade is not plumbing. It carries every request for the length of the migration, which makes it both a single point of failure and a potential bottleneck. Give it the monitoring and the capacity headroom you would give any production service. 

Running the pattern on a warehouse system without stopping fulfillment 

A WMS modernization strategy built on this pattern follows a consistent shape, and the sequencing decisions matter more than the tooling. 

• Stand up the facade first: Every request to the WMS routes through it before any module moves. On day one it changes behavior for nobody, which is the point: you prove the routing layer under full production load while the legacy system still answers every request. 

• Pick the first module for separability: The right starting point is the function with the fewest reads and writes shared with the rest of the system. Label generation and carrier rate lookup usually qualify. Core inventory allocation rarely does. 

• Decide how shared data behaves during the overlap. Both systems will read, and sometimes write, the same records for months. Agree which system owns each table, and how the other one sees changes, before the first module ships. 

• Put an anti-corruption layer between old and new: Microsoft recommends it, so the legacy system’s data semantics do not leak into the design of the replacement. Without it, the new system inherits the schema you are trying to escape. 

• Move one module, run both, then retire from the old path: Keep the legacy code for that function in place and reachable until the replacement is held through a full peak cycle. 

Here is what that looks like on a calendar. Label printing moves in month one. Carrier rate shopping in month three. Receiving in month five. Each sits behind the same facade, and allocation and wave planning wait until last, because they touch the most shared state. 

Throughout, the old WMS keeps running whatever has not moved yet. 

Once the final module lands, the legacy system is answering almost no requests. Switching it off is an administrative step, not an event the operations team has to staff on a Saturday night. That is the end state a sound WMS modernization strategy aims at: a decommission nobody must schedule around. 

How ViitorCloud sequences a strangler fig migration 

Most modernization proposals open with a target architecture. On legacy application modernization work, ViitorCloud opens with two different questions: what does the routing layer look like, and in what order do the modules move? 

Those two answers decide whether the migration can be halted safely halfway through. A target architecture you cannot reach incrementally is a rewrite in different packaging. 

That sequencing is what keeps a logistics operation running during work. The facade goes to production before any functionality moves, carrying live traffic to the legacy system, so the routing layer is proven while the stakes are still low. Module order follows data coupling rather than stakeholder preference. Each module stays reversible until it has survived a peak period. 

The approach draws on the same judgment covered in ViitorCloud’s guide to refactoring or replacing a legacy application, applied to systems where downtime carries a dock-door cost, and on the zero-downtime practices in its cloud migration work. 

Pick the module that proves the pattern 

The first module is not the one the business complains about most. It is the one that separates the most cleanly. 

Its real job is to prove three mechanisms while the stakes are low: the facade, the data handling, and the rollback path. Once it has run through a busy week, the rest of the sequence is a repetition of a process you have already tested under load. 

That is the quiet advantage of the strangler fig pattern. The hardest week of migration is the first one, and it is a week you chose. To scope a strangler fig migration against your own WMS or TMS, including which modules can move first and which have to wait, talk to the ViitorCloud team.