Cloud Infrastructure Migration for a Retail Operation
A retail business with 14 physical stores and an e-commerce operation moved from on-premises infrastructure to a fully managed cloud environment, reducing operational overhead and improving system reliability ahead of peak season.
6 weeks
Migration duration
Full environment, under original 8-week estimate
0 critical
Post-migration incidents
First 90 days in production
< 4 hours
Recovery time objective
Improved from 2–3 days on-premises
The challenge
The client's on-premises servers were aging out of support, creating security and reliability risks ahead of their highest-revenue trading period. They lacked an internal infrastructure team and needed a migration completed within 8 weeks to avoid peak-season exposure.
Objectives
- Complete migration before peak trading season
- Eliminate end-of-life hardware security exposure
- Establish automated backup and disaster recovery
- Reduce operational overhead without a dedicated infrastructure team
Discovery
A 3-day on-site infrastructure audit catalogued 23 workloads across 6 physical servers. We classified each by migration complexity (lift-and-shift, re-platform, or retire) and identified two workloads — the e-commerce application and the POS integration layer — that required re-architecture rather than simple migration.
Strategy
Migrate in two tracks in parallel: lift-and-shift for 21 low-risk workloads, and re-architecture for the e-commerce stack. The e-commerce re-architecture used managed services (RDS, CloudFront, ElastiCache) to reduce operational dependencies and improve scalability ahead of peak season.
How we approached it
We conducted a 3-day infrastructure audit, categorized workloads by migration complexity, and executed a lift-and-shift for low-risk systems while re-architecting the e-commerce stack for managed services. Database migration used AWS DMS with a staging environment for validation before cutover. Monitoring was established via CloudWatch with alerting thresholds tuned to historical traffic patterns.
Architecture
E-commerce stack: CloudFront CDN → EC2 application tier (Auto Scaling) → RDS PostgreSQL (Multi-AZ) → ElastiCache Redis. Internal workloads: EC2 instances in a private subnet. All infrastructure defined in Terraform. CloudWatch dashboards and SNS alerting configured before cutover.
Implementation
Lift-and-shift workloads migrated in weeks 1–3 using AWS Migration Hub. E-commerce re-architecture ran in parallel (weeks 1–5) with a staging environment validated against production traffic patterns. Database migration used AWS DMS with ongoing replication to allow a clean cutover during a low-traffic window. Full cutover in week 6.
Key decisions
Full re-architecture vs. lift-and-shift for all workloads — re-architecting everything would have maximised long-term efficiency but exceeded the timeline.
We re-architected only the two revenue-critical workloads and lift-and-shifted the rest. This met the deadline and delivered the reliability improvement where it mattered most.
What changed
Migration completed in 6 weeks, under budget. The client entered their peak trading season on managed infrastructure with automated backups, scaling policies, and a monitoring dashboard. No critical incidents in the first 90 days post-migration.
Impact
The client entered peak season on infrastructure with automated scaling, backup, and monitoring — for the first time. Their operational overhead for infrastructure reduced significantly with no dedicated infrastructure engineer required.
Lessons learned
- 1The POS integration layer required more re-architecture effort than the initial audit suggested — undocumented dependencies were discovered during migration testing.
- 2Setting CloudWatch alert thresholds before cutover (rather than after the first incident) meant the team had two weeks of operational experience before peak season.