Choosing a Migration Path Under a Hard Colo Exit
Northwind Freight runs a nine-year-old Java order system on 38 VMware VMs in a colo whose lease expires in seven months. The Oracle database is 8 TB and grows 2.5 TB per month; a licensing audit is due in 10 months. Peak season is three times normal for six weeks, and the current design has no autoscaling. The team has four VMware administrators, one part-time AWS-certified engineer, and no production Kubernetes experience. Compliance requires encryption at rest and in transit, 12 months of audit logs, and 99.9% availability. The CIO has approved a capped 18-month budget and wants the colo exit on time. A vendor proposes containerizing everything and running active-active across two clouds; an internal architect proposes rehosting the VMs to IaaS first. You must recommend a path that meets the lease deadline without creating an unmanageable operating model.
1. Which migration approach should you recommend for the seven-month window, and what is the strongest reason to reject the two-cloud container proposal?
Read the worked answer
Recommend rehost (lift-and-shift) to one public cloud in a single region with multi-AZ, then replatform after the colo exit. The lease date and 8 TB database make a container rewrite high-risk: the team has no production Kubernetes experience, active-active across two clouds doubles the operating model, and the Oracle licensing audit would complicate a rushed refactor. The strongest reason to reject the vendor proposal is not cost; it is that four VMware admins and one part-time cloud engineer cannot support a new multi-cloud container platform while also migrating the data and meeting peak season. Rehost preserves current runbooks and immediately enables native backup, KMS encryption, and centralized logging. Plan database replication and a rehearsal cutover, and keep a rollback path to the colo until two weeks after acceptance.
2. Classify the target as a service model and deployment model, and explain which components should be managed services versus self-managed.
Read the worked answer
The target is public cloud IaaS for the initial migration, not PaaS, because the workloads remain VMs and the team controls the OS and middleware. Use managed services around the edges: load balancer, object storage for backups, KMS, centralized logging, and DNS. Keep Oracle self-managed on EC2 initially unless a licensing assessment proves a managed Oracle service is cheaper and supportable; Oracle licensing on cloud can change the cost model and audit exposure. The database is the component that most affects the deadline, so do not combine a database engine change with the colo exit. After stabilization, replatform selected tiers to managed services where the team has skills and the compliance evidence exists.
3. Name the two risks most likely to make you miss the lease deadline and give a concrete mitigation for each.
Read the worked answer
The highest-probability risks are data migration and cutover and operating-model readiness. For data, the 8 TB database plus 2.5 TB monthly growth means a simple export/import will not fit the window; use seed transfer, ongoing replication, and at least two timed rehearsals with measured cutover duration. For readiness, the team lacks production cloud experience; assign a cloud partner or senior engineer to pair with the VMware admins, write runbooks for backup, restore, patching, and incident response, and run a game day before cutover. A third risk, Oracle licensing, should be tracked separately with the audit date; confirm license portability and instance sizing before ordering capacity. Each risk needs an owner and a go/no-go checkpoint before the lease deadline.