Nine-Month Data Center Exit With Two Migration Engineers
GlobalFreight is exiting a leased data center in nine months. The estate includes 180 VMware VMs, 30 Oracle databases, 12 WebSphere applications, and a COBOL batch system that exchanges files with a customs broker. About 40 VMs run custom Linux daemons with hard-coded IP addresses; 25 are Windows Server 2012 R2; the rest are file/print and monitoring. The CIO wants to lift and shift everything to VPC to meet the deadline, but the CFO has asked for a modernization plan that reduces run cost by 20%. The network team confirms a 1 Gbps Direct Link and a 35 ms round trip to the on-premises mainframe. Application teams are already overloaded, and only two migration engineers are available. A previous migration attempt failed because the payroll dependency on a database link was discovered late. The board has made the data-center exit date non-negotiable, and any workload not migrated must be retired or replaced.
1. How would you segment the estate and choose migration patterns under the schedule, staffing, and cost constraints? Be specific about what to rehost, replatform, retire, or defer.
Read the worked answer
Start with application-to-application dependency discovery, not a VM inventory. The prior payroll failure shows that database links and file drops are the real cutover units. Group the estate into waves by business capability: low-risk file/print and monitoring first, then custom Linux daemons, then Oracle and WebSphere, and the COBOL batch last or as a retained/replaced service. Apply the 6Rs deliberately: retire duplicate file/print and monitoring; rehost simple Windows and Linux workloads to VPC virtual server instances; replatform only where the CFO's 20% target is credible, such as WebSphere to OpenShift or Oracle to a managed database, and only after a pilot. Do not replatform 30 Oracle databases with two engineers in nine months; that is the schedule risk. Rehost Oracle and WebSphere initially, with a post-exit modernization roadmap. Windows Server 2012 R2 is a security problem, so those 25 VMs should be rebuilt on a supported OS, not lifted unchanged. The non-negotiable exit date drives a migrate-or-retire decision per application.
2. Address the hard-coded IP addresses and the risk of late-discovered dependencies such as the payroll database link. What engineering and cutover controls would you put in place?
Read the worked answer
Treat hard-coded IP addresses as a migration defect, not a networking problem. Inventory every hard-coded address and its owner, and replace it with DNS names or service discovery before cutover where possible. Where it cannot change in time, use a per-wave address translation layer and a temporary landing zone that preserves the old addresses, then retire it. For the 35 ms mainframe round trip, test chatty database links; latency may be acceptable for batch but not for online transactions. Run discovery workshops with each application owner and a dependency hatch that logs every observed connection for at least two weeks before cutover. Build a runbook with freeze, backup, replication catch-up, validation, and rollback. The rollback criterion must be measurable, such as failed file reconciliation or error rate above threshold. Late discoveries should trigger a wave delay, not a heroic all-night fix. This is a judgment call: the schedule pressure is real, but hidden dependencies are what turn a migration into an outage.
3. The CFO wants a 20% run-cost reduction, and the board wants the exit date. How do you reconcile these targets, and what should you promise?
Read the worked answer
Tell the CFO the truth: the data-center exit and the 20% run-cost reduction are separate programs with different risk. The exit should optimize for certainty and reversibility; the cost target should be earned after migration through rightsizing, retirement, storage lifecycle, and license optimization. A lift-and-shift of 180 VMs often increases run cost because on-premises costs are understated. Commit to a baseline and a 90-day post-migration optimization gate, not a 20% cut on day one. Quick wins are retiring redundant monitoring and file/print, moving logs to lifecycle-managed COS, and rightsizing after 30 days of production metrics. Larger levers such as Oracle licensing, WebSphere consolidation, and replacing COBOL batch need a business case and may not fit the exit window. If the board insists on both, present a phased plan with explicit trade-offs: cut scope by retiring more applications or extend the exit for the high-risk wave. Do not fund the cost target by removing disaster recovery or support.