Insurer's 240-VM Estate: 7R Judgement Against a 'No Exceptions' Mandate
A regional insurer is moving 240 VMware VMs (38 applications) to OCI within 14 months. At month 3 the board cut programme budget by 22%. The estate includes 11 Oracle databases totalling 22 TB, one of which is a 4-node RAC cluster backing the claims system. Nine applications are vendor-packaged and their ISVs have issued no OCI support statement; two have refused in writing. A 12-year-old .NET 2.0 policy-rating application has no source code, no vendor, and still processes 6% of premium volume. Monitoring shows 60 VMs average under 4% CPU. Connectivity is a single 300 Mbps MPLS to the nearest OCI region. Change control permits one 6-hour maintenance window per month, and the claims system cannot be frozen during month-end close. The CIO's stated position is 'cloud-first, no exceptions' by month 14, and the programme has not yet produced written ISV positions, licence portability findings, or application dependency maps.
1. Classify the estate into migration strategies and defend how you treat the nine vendor-packaged applications and the no-source .NET application. What evidence must exist before you commit to those classifications?
Read the worked answer
Start with retire, because it is the only strategy that pays for itself. The 60 sub-4%-CPU VMs are candidates, but CPU alone is not evidence: check network flows, scheduled jobs, licence servers that other apps depend on, and get owner sign-off. On estates this shape, 8-12% is typically retired, which recovers a meaningful slice of the 22% cut.
The 11 Oracle databases: rehost the claims RAC cluster as RAC (to Base Database Service or Exadata Cloud Service) rather than re-platforming it in the same programme. Changing platform and platform-of-record simultaneously doubles the failure surface and the rollback problem. The single-instance databases are safe re-platform candidates to a managed service.
The nine vendor applications are the real decision, and 'cloud-first, no exceptions' cannot override an ISV support statement. Unsupportable means the insurer silently inherits the vendor's bug-fix obligation. Classify as retain-in-supported-configuration with a dated re-evaluation, open a parallel vendor-certification track, and do not let them gate the whole programme.
The .NET 2.0 application with no source code is rehost or replace, never refactor. Rehost into an isolated compartment (no internet egress, restrictive NSGs, hardened extended-support image, no shared identity) while a replacement business case runs.
Evidence required before committing: application dependency maps, written ISV statements, licence portability findings, per-app RTO/RPO, and utilisation, not just CPU.
2. Sequence the migration into waves and re-plan under the 22% budget cut. What do you protect, what do you defer, and how do you handle the CIO's month-14 commitment?
Read the worked answer
Sequence by dependency and risk, not by business unit.
- Wave 0 (months 1-3): landing zone, network, identity, logging, plus 15-20 low-dependency dev/test VMs. This is where the pattern and the team are built.
- Wave 1: the retire candidates and stateless web/internal tools. Fast, cheap, low blast radius.
- Wave 2: single-instance Oracle databases with their applications in the same wave, because a database without its consumers is not a migration.
- Wave 3: claims RAC, scheduled away from month-end close, after the pattern is proven twice.
Under a 22% cut, do not 'do the same scope slower' - that pushes claims past month 14 and makes the commitment worse, not better. Cut scope instead: retire the 60 VMs, rightsize (VMware estates are commonly 40-60% over-provisioned), and defer 5-8 low-value applications to a post-programme phase with a written exception.
Protect the irreversible investments: landing zone, network design, and the database migration factory. Defer anything that is one-time and reversible.
On the month-14 commitment: with two ISVs refusing support in writing, 'no exceptions' is not a scope commitment you can make honestly. Surface the exceptions at month 4 with a named owner and a decision date, so the CIO chooses between scope, date and policy - rather than discovering the conflict at month 12.
3. What are the three largest threats to the 14-month date, and which leading indicators would you report monthly?
Read the worked answer
ISV certification slippage. It is the one dependency you cannot engineer around. Indicator: count of written support statements received versus nine required. If it is zero by end of month 4, the retain list is at risk of becoming a permanent on-prem footprint and the business case changes shape.
Throughput of the single 300 Mbps MPLS. It is the ceiling for bulk data, change replication and rollback re-sync. Model it: 22 TB of database plus VM images, plus ongoing replication, plus the existing production traffic on the same circuit. Indicator: measured sustained throughput to the region during Wave 0 and a modelled transfer schedule for Wave 3. If the model does not close, the answer is data transfer appliances or an offline seed, decided early - not a bigger window.
Oracle licensing. Moving a RAC cluster under BYOL with processor licences or a ULA can turn a rehost into a compliance event or an unbudgeted purchase, and the 22% cut leaves no headroom. Indicator: completed licence position signed off by procurement and legal, plus the support-renewal dates that constrain the timing.
Report also: cutover dry-run completion, WAF/patching exceptions open, and number of applications with a named business owner. Those three predict schedule slippage more reliably than percentage-complete.