Meridian Freight: Sequencing a 210-Day Data Centre Exit with an Incomplete Inventory

The binding constraint is a fixed 210-day deadline against an assessment process that is itself the bottleneck. Sequencing by business criticality would therefore be wrong: critical systems usually have the deepest dependency graphs and the least complete documentation, so they consume assessment capacity you do not have early. Sequence by (assessment completeness × dependency depth) ÷ effort to retire.

Wave 0 (foundation, weeks 1-5): landing zone, identity federation, connectivity, logging/audit, backup policy, and the migration factory tooling. Nothing user-facing ships, but every later wave depends on it, and this is the only work that cannot be parallelised later.

Wave 1 (weeks 6-11): the 180 assessed applications, filtered to those with no inbound dependencies from unassessed systems, plus the obvious retire candidates. Retiring 20-40 VMs shrinks the remaining problem faster than any rehost can, and does so without consuming migration engineering time.

The three vendor-blocked packaged applications and the two COBOL/AIX systems must be pulled out of the wave plan immediately and handled as a separate retain/replace track with its own exit contract, because they cannot be solved by migration engineering and will otherwise sit silently at the end of the schedule. Tier-1 systems with 4-hour RTO go into the final third, when the factory is tuned and Data Guard-based cutovers have been rehearsed.

AIX COBOL applications - retain (in a residual colo), with a replace track. Oracle Cloud Infrastructure does not offer AIX hosts, so rehost is not physically available; replatform means rewriting business logic in a language no current staff own, which is a multi-year programme and cannot be on a 210-day critical path. The honest answer is a small residual colo or hosted AIX contract covering only these two systems, negotiated now while you still have leverage, running in parallel with a funded repurchase/replace evaluation. Presenting this as a failure is the mistake; presenting it as a scoped, costed exception with a named owner is the correct architecture decision.

Vendor-blocked packaged applications - repurchase (SaaS) or retain. If the vendor offers a SaaS edition, repurchase removes the hosting question entirely and is usually cheaper than fighting an unsupported deployment. If no SaaS exists, retain on the same residual footprint, because running an unsupported configuration in OCI converts a vendor support problem into an availability problem you own.

For both groups the decisive test is not technical feasibility but who carries the support obligation after cutover. Any option that leaves Meridian holding an unsupported stack should be rejected even if it technically deploys, and the residual footprint should be sized from measured peaks (month-end 90%), not averages, since these are the workloads least tolerant of a sizing mistake.

With 22 months of support remaining and licences owned outright, BYOL is normally the cheaper path - but only if the technical preconditions hold, and those preconditions are what the exam is really testing.

1. Support must be current. If support lapses, BYOL rights on OCI disappear; the 22-month horizon means you must model the renewal cost into the business case, not treat year three as free.
2. Licence counting follows the failure domain. For Database EE, BYOL on OCI requires hard partitioning: you must be able to name the exact cores the database can run on. That pushes you toward dedicated shapes (Base Database on dedicated hosts, Exadata Database Service) and away from anything where the database could migrate onto a shared host. A consolidation onto autonomous or shared infrastructure invalidates the BYOL arithmetic and may force license-included.
3. Right-size on peaks, not the 11% average. The 11% average tells you the estate is over-provisioned; it does not tell you how small a shape is safe. Licence cost scales with cores, so the temptation is to cut shapes aggressively - but the month-end batch hosts at 90% would then miss their batch window every month. Size on p95 with headroom, then reduce core count by consolidating many small databases onto fewer, larger, properly licensed hosts.
4. Run both numbers. Compare BYOL (licence support cost + OCI infrastructure at reduced core count) against license-included (higher hourly rate, no licence tracking, no support renewal risk). License-included frequently wins for small, spiky databases where administration effort exceeds licence savings.

The decision per database, not per estate: BYOL for the large steady 19c instances on dedicated shapes, license-included for the small 11g instances you intend to consolidate or retire.