Northwind Freight: Choosing Migration Paths Under a Lease Deadline
Northwind Freight runs 120 VMware VMs in a colocation facility whose lease expires in 14 months. The 30 TB Oracle payroll and billing database is licensed per core and audited annually. Warehouse robots send scan events to an on-premises service that must respond within 20 ms; the robots cannot tolerate WAN round trips. A route-planning application is used only during the November peak and sits idle the rest of the year. The CFO has approved a migration but wants capex converted to opex and refuses a three-year commitment until the first workload proves out. The networking team worries about egress charges for 40 TB of monthly customer file downloads. A new CIO asks whether lift and shift is acceptable and how to prove the cloud is not more expensive.
1. Recommend a migration approach for each workload: the payroll/billing database, the robot scan service, the route-planning application, and the 40 TB of customer downloads. Justify each choice by risk, latency, and effort.
Read the worked answer
Payroll/billing database: replatform after a licensing review. Move to Amazon RDS for Oracle using bring-your-own-license, or rehost to EC2 on dedicated hosts if Oracle's cloud licensing rules are unclear. A naive lift and shift onto shared tenancy creates audit and per-core licensing exposure, while RDS adds managed backups, patching, and Multi-AZ failover. If licensing cannot be resolved quickly, retain this workload until it is.
Robot scan service: retain or go hybrid. A 20 ms response requirement is a hard constraint. Keep the service on-premises connected by Direct Connect, or run it on AWS Outposts at the warehouse. Migrating it to a distant Region would add WAN latency the robots cannot tolerate.
Route-planning application: replatform to scheduled capacity. Rehosting preserves 11 months of idle servers. Refactor to Auto Scaling that runs only in November, or to a batch/serverless design triggered on demand, so cost tracks usage.
Customer downloads: move to S3 with CloudFront. Object storage plus caching reduces origin load and usually lowers delivery cost versus serving files from web servers, but egress still exists and must be budgeted.
The pattern: strategy follows constraints, not fashion. A single 'lift and shift everything' answer ignores latency, licensing, and idle capacity.
2. The CFO says the data center is cheaper. Build the comparison you would present and name the costs teams usually omit.
Read the worked answer
Compare like with like over three years. On-premises side: colocation lease, power and cooling, hardware refresh, Oracle licenses and support, storage, network, staff, DR site, and capacity purchased for peak. Cloud side: compute hours actually consumed, storage by tier, requests, egress for 40 TB, NAT and VPN charges, support plan, migration, and training.
The common error is comparing depreciated peak capex with average cloud consumption. The data center is sized for November and for failure; the cloud bill can follow demand. Show that the route-planning app costs nearly nothing for 11 months in the cloud but must be powered and cooled all year on-premises.
Costs teams omit: data transfer out, cross-AZ traffic, NAT Gateway processing, idle or forgotten instances, snapshots, support plan uplift, duplicate tooling during migration, and staff retraining.
Recommendation: migrate one workload first, tag every resource by workload and owner, and review the bill monthly for a quarter. Commit only after a measured baseline; this also answers the CFO's no-long-term-commitment condition.
3. What should the CIO understand about lift and shift, and what AWS resource would you use to validate the business case?
Read the worked answer
Lift and shift (rehost) is a legitimate first step when speed matters, especially to exit a lease. It is not a destination: it carries existing inefficiencies into the cloud, so an overprovisioned server stays overprovisioned and keeps costing money. The six common strategies are rehost, replatform, repurchase, refactor/re-architect, retire, and retain. A sensible portfolio uses several of them; Northwind should retire unused VMs, retain the latency-bound robot service, replatform the database and route planner, and rehost only what must move quickly.
Risk: rehosting everything locks in the current architecture and delays savings, while the team learns cloud operations under deadline pressure.
For validation, use AWS Migration Evaluator to collect on-premises utilization data and build a data-driven business case, and Migration Hub to track application progress. These produce evidence from actual utilization rather than vendor list prices, which is exactly what a skeptical CFO needs. Pair that with a small pilot and a tagged cost baseline.