Somewhere in most warehouse operations sits a piece of software nobody wants to touch. It might be a custom pick-path module bolted onto the WMS in 2012, an EDI translator that turns retailer orders into ERP sales lines, or a Windows service that prints carrier labels at the end of every packing bench. Much of it was written in C# on the .NET Framework, and much of it still works. The trouble is that fewer people each year know how it works.

That gap becomes a real risk when a business decides to modernise. Upgrade work tends to collide with the busiest trading months, and a failed cutover in late November can mean missed carrier collections, short-shipped orders and chargebacks from retail customers. The upgrade does not have to be one big, risky weekend, though.

Why legacy .NET code is now a supply chain problem

Microsoft’s .NET Framework 4.8.1 is the final major version of the original framework. It still receives security patches as part of Windows, but it gets no new features, and modern libraries increasingly target only the newer, cross-platform .NET. The current long-term support release is .NET 10, and support for .NET 8 ended in November 2026, so even teams that modernised a few years ago may already have work to do.

For logistics teams, the practical issues show up as:

• Integrations that can’t use current SDKs from carriers, marketplaces or cloud providers
• Code tied to old Windows Server versions that the IT security team wants retired
• WCF services that ERP screens and handheld scanner apps depend on, which have no direct equivalent in modern .NET outside the community CoreWCF project
• A shrinking pool of staff who understand the original design decisions

None of this stops the warehouse today. It does make each year of delay more expensive.

Start with a map of what touches the floor

Before any code changes, it pays to list every component that sits between an order and a dispatched parcel. That usually includes the WMS customisations, the ERP extensions, EDI translation (EDIFACT ORDERS and DESADV messages for many UK and European retailers, ANSI X12 856 advance ship notices for US customers), label and manifest services, and any reporting jobs that run overnight.

For each item, the useful questions are simple. What breaks if it stops for an hour? Who knows how it works? When was it last changed? A label printing service that halts packing is a very different risk from a weekly stock-ageing report, and the migration plan should treat them differently.

Migrate in small slices

The safest pattern for this kind of system is often called the strangler fig approach. Instead of rewriting the whole application, the team puts a routing layer in front of it and moves one function at a time to the new code. Microsoft documents this method for ASP.NET applications, using its YARP reverse proxy to send some requests to a new ASP.NET Core app while the rest still go to the old one.

In a warehouse setting, a slice might be the carrier rate lookup, then the label service, then the ASN generator. Each slice goes live on its own, with the old path still available as a fallback. Microsoft’s upgrade tooling can handle much of the mechanical project conversion, though business logic around allocation rules or wave planning still needs a person who understands the process.

Rolling out by site helps too. Switching one smaller distribution centre to the new component first, while the main DC stays on the old path, limits any problems to a fraction of daily volume.

Test integrations with real traffic before cutover

Unit tests rarely catch the failures that hurt most in logistics. Those tend to come from data: a retailer’s EDI file with an unexpected segment, a postcode format the new validation rejects, or a pallet SSCC whose leading zero gets stripped.

Two techniques catch these early:

1. 1. Message replay. Capture a few weeks of real production messages, such as orders, ASNs and stock updates, and run them through both the old and new code. Any difference in output gets investigated before go-live.
   2. Shadow running. Let the new component process live traffic in parallel without acting on it, then compare its results with the old system’s decisions over a set period.

Both approaches give operations managers hard evidence before sign-off, which makes the go-live conversation far easier.

Build the timeline backwards from peak

Most UK retailers and 3PLs lock down system changes from early November until after the January returns wave. A sensible migration plan works backwards from that freeze. High-risk slices should go live by late summer, leaving September and October to watch them under rising volumes. Lower-risk work can carry on in development during peak, ready to deploy in February.

The trap is a freeze that never really ends. When a project misses its window, teams often push everything to “after peak”, then to “after the year-end stock count”, and the legacy code survives another year. Small slices are the best defence, since a two-week piece of work is far easier to fit into a quiet period than a six-month rewrite.

Who actually does the migration

This is where many projects stall. The internal IT team is usually busy keeping current systems running, and the developers who wrote the original code may have moved on. Pulling the one person who understands the allocation logic onto a rewrite leaves nobody to fix live issues during the day.

Common options include hiring permanent staff, which is slow in a tight market for senior C# developers; using a systems integrator, which suits large ERP programmes but can be costly for smaller custom code; or adding dedicated enterprise .NET engineers who join the existing team for the length of the migration. The last route lets internal staff stay focused on operations and process knowledge, while the extra engineers handle code conversion, test harnesses and the deployment pipeline.

Whichever route a business takes, the outside engineers need time with the people who run the floor. A developer who has watched a wave release on a busy Monday morning will write better code than one working only from a specification.

A steady path beats a big bang

Legacy WMS and ERP code rarely fails all at once. It gets harder to change, harder to secure and harder to staff, until a single upgrade suddenly becomes urgent. Teams that map their systems, move them in small slices, test with real data and plan around peak can modernise without putting the busiest weeks of the year at risk.