Distributor: AWS before peak shipping season
A Mid-Atlantic distributor with three warehouses needed off aging on-prem hosts before holiday volume. We moved warehouse, EDI and reporting workloads to AWS in phases so outbound shipping never paused for a migration window.
Hardware refresh vs. a messy lift-and-shift
Servers were out of warranty. A prior attempt to move VMs as-is stalled because nobody owned dependency maps for WMS, EDI and reporting. Peak season was twelve weeks out. The client preferred AWS for the landing zone their partners already used.
Landing zone first, then risk-ordered waves
We stood up a governed AWS account structure (VPC, IAM, backup, CloudWatch), then migrated in waves: reporting and non-critical tools first, WMS and EDI last with rehearsed Saturday cutovers. Each wave had a rollback path and a named warehouse contact. Automation used Terraform and Python runbooks.
Main pieces of the work
Dependency map
App owners, interfaces and maintenance windows documented before move #1.
AWS foundation
Multi-account layout, networking, IAM and monitoring before any cutover.
Wave cutovers
Saturday windows timed after last outbound trucks.
Day-2 ops
Cost alerts and runbooks handed to their IT lead.
- AWS (EC2, RDS, S3)
- Terraform
- Python runbooks
- CloudWatch / SNS
- Peak season ran on AWS without a missed ship day
- Roughly 18% lower monthly infrastructure spend after rightsizing
- IT has one place for backups and alerts instead of per-server tools
- Rollback never needed in production; two waves used it in dress rehearsals
Peak season on aging hardware?
We plan migrations around your shipping calendar on AWS, Azure or GCP — whichever fits your stack.