Migrating legacy TMS/WMS to the cloud

An ageing on-prem stack at breaking point

A Memphis, Tennessee-based third-party logistics provider runs its TMS and WMS across 12 distribution centers, handling around 40 million order lines a year. On end-of-life hardware with fixed capacity, four problems compounded every peak season. The engagement ran around ten months, phased, for the CIO and infrastructure team.

No room to scale. Fixed capacity meant provisioning (and paying) for peak year-round, yet still hitting ceilings.

Fragile at peak. Limited headroom and manual failover left the platform exposed to slowdowns when it mattered most.

Brittle integration. Point-to-point batch interfaces to carriers, ERPs and EDI partners were hard to change and slow to recover.

Growing risk. Ageing hardware meant rising maintenance, patching burden, and disaster-recovery gaps.

Paying more, wasting most of it, and still failing at peak

The status quo carried a real price: a heavy run-rate on hardware that sat mostly idle, yet still couldn't absorb the peak.

• $210K a month run-rate on ageing on-prem hardware.
• ~60% of that capacity idle off-peak: paid for, rarely used.
• 3× peak demand that still outstripped fixed capacity.

Only part of an on-prem bill is compute. The rest (refresh cycles, floor space, support contracts and the staff time to keep it patched) is what a re-platform actually addresses:

Roughly three-quarters of the bill sat in hardware, facilities and support, none of which scales down when the peak passes.

"Every peak season, we held our breath. The systems that run our warehouses and freight sat on hardware we couldn't scale, and one bad day in November could cost us a client."

— Chief Information Officer, Memphis-based 3PL

Mapping the estate, then the must-haves

We began with discovery: dependency mapping across the TMS, WMS and their integrations, plus a TCO business case built with Azure Migrate. That set a clear bar the target platform had to clear:

• Scale elastically to ~3× peak, on demand.
• Meet a 99.9% availability target through peak.
• Reduce the monthly infrastructure run-rate.
• Cut over with minimal downtime and a rollback path.
• Replace brittle batch interfaces with modern APIs.
• Geo-redundant DR with defined RTO/RPO and strong security.

One re-platform on Azure, built for peak

The target: re-platform the TMS and WMS onto Microsoft Azure, managed services and elastic autoscale in place of fixed on-prem capacity.

Elastic scale. Autoscale for peak, pay for what you use, not standing peak capacity.

Resilience by design. Availability zones and Azure Site Recovery with defined RTO/RPO.

Cost control and FinOps. Cost Management, right-sizing and reserved capacity to lock in the run-rate.

Secure and integrated. Microsoft Entra identity, managed patching, and API-based integration.

Phased rollout, measurable change

Five phases kept the operation running throughout, and as workloads moved, the cost and resilience picture changed with them.

1. Assess: discovery, dependency mapping and the TCO business case with Azure Migrate.
2. Foundation: landing zone, networking, identity and security baseline, all as infrastructure-as-code.
3. Re-platform: re-architect the TMS/WMS for Azure compute and managed databases.
4. Migrate and cut over: data migration, a parallel run, and a minimal-downtime cutover with a tested rollback plan.
5. Optimize: autoscale, disaster recovery, and FinOps cost controls to lock in the run-rate.

The migration was sequenced by dependency, not by convenience: the integration layer had to land before the WMS could move, and the TMS followed only once warehouse traffic was stable on Azure.

Peak season fell in months 11–12, and the plan deliberately finished cutover and DR testing before it started.

Cutover night, hour by hour. A rehearsed runbook with a hard rollback checkpoint: if validation had failed at 01:30, the old stack was still live and untouched:

Total service interruption was under four hours, inside one planned weekend window, with the previous environment kept warm for a further two weeks. Capacity now follows demand through peak instead of sitting fixed at it.

A platform that scales with the business

The provider moved from a fixed, ageing stack it had outgrown to an elastic platform that meets the peak, holds its SLA, and costs less to run, with headroom to add forecasting and analytics next. The systems that run the warehouses and the freight are no longer the thing to worry about in November.

Built on Microsoft Azure.