Lift-and-Shift Versus Re-Platform for a Freight Broker Facing a Refresh Deadline
Northline Freight is a 900-person freight brokerage. Its estate is 46 on-premises VMs: a Java EE booking application on WebSphere across 6 VMs, two Oracle 11g database VMs, a nightly rating batch engine, and 12 TB of scanned bills of lading on a NAS. The data-center lease and hardware refresh land in seven months, and the CFO has committed to a 20% reduction in run-rate infrastructure spend. Customer contracts require 8-hour RTO and 1-hour RPO, while the November-to-December peak roughly triples order volume for five weeks. The 38-person team has strong Java and Oracle skills, no Kubernetes experience, and no capacity to run a second site; today's DR site costs about $180,000 a year and is tested once annually. A partner proposes lift-and-shift to VPC virtual server instances in a multizone region with Oracle self-managed. An internal architect argues for re-platforming the web tier to containers and moving the database to a managed service.
1. Evaluate both proposals tier by tier. Which workloads should move as-is, which should be re-platformed, and what evidence would you demand before touching the database?
Read the worked answer
Judge each tier on change cost versus change value, not on a single estate-wide slogan.
Web tier (stateless Java EE). Highest value, lowest risk. Containerizing it on OpenShift or Kubernetes removes the WebSphere licensing line and gives the peak-season elasticity the business actually needs. But the team has zero Kubernetes experience, so either accept an 8-10 week ramp with a managed OpenShift service, or take a staged path: VPC instances first, containers in the following quarter.
Rating batch. Moves as-is. It is schedule-driven, tolerates restarts, and has no interaction with peak web traffic; a VPC instance group or a container job is sufficient.
Oracle 11g. This is the trap. Lift-and-shift preserves an out-of-support release and moves the patching risk into the cloud, where it is no cheaper to own. Ask for three pieces of evidence: a PL/SQL and package inventory showing how much proprietary logic lives in the database, vendor certification for any alternative target, and a query-latency profile for the reporting workloads. If PL/SQL volume is high and the vendor is uncertified, run Oracle self-managed on VPC instances short-term as a reversible first step, then migrate in a funded second phase.
A defensible answer is a mixed path: re-platform the web tier, lift the batch, and gate the database on evidence rather than optimism.
2. The 20% target is a run-rate number. Which cost and value items does a lift-and-shift-only case usually miss, and what happens to the DR line once you are in a multizone region?
Read the worked answer
A lift-and-shift case typically compares only compute and storage list price against today's hardware depreciation, which understates and overstates at the same time.
Commonly missed costs: Oracle licensing under a bring-your-own-license model (per-core counts can rise on cloud CPU profiles), storage growth at 12 TB and climbing, backup retention, egress when scanned documents leave the account, patching labor that was previously hidden in a sysadmin's week, and the permanent over-provisioning needed for a five-week peak that runs at 3x.
Commonly missed value: converting a refresh capex into variable opex, deleting the refresh cycle entirely, and the release-velocity gain from containers, which is real money if the team ships weekly instead of quarterly.
On DR, a multizone region spreads instances across three zones, so a single-zone or single-datacenter failure no longer requires a second site. That retires much of the $180,000, but not all of it: a region-level event still exists, and the 1-hour RPO must be met by cross-region backup copies and a tested restore runbook. Expect the DR line to fall to cross-region object storage, backup tooling, and staff time for quarterly tests. Presenting it as 'DR goes to zero' invites a credibility problem later.
Finally, size the peak explicitly: reserved capacity for the baseline and pay-as-you-go for the peak is usually cheaper than provisioning for the peak all year.
3. Which support plan and account-governance controls should be in place for the first 12 months, and why those rather than the cheapest option?
Read the worked answer
The first year is a migration year, so the support question is about outage cost, not subscription cost.
Support. Basic support is ticket-and-documentation oriented and is a poor fit for a customer-facing booking system with a contractual RTO. An Advanced-level plan buys 24x7 access for severity-1 cases, named technical contacts, and defined response targets, which matches the migration risk profile. A Premium-level plan with a technical account manager and proactive architecture reviews is justified if the database migration proceeds on a tight timeline or if the peak season cannot tolerate a learning-curve incident. Decide by asking what one hour of peak-season downtime costs versus the annual delta between tiers.
Governance controls to stand up alongside the migration:
- Resource groups separated by environment (production isolated from non-production) so access policies and spend can be scoped.
- Access groups mapped to job roles instead of per-user policies, with a small admin group.
- A tagging standard (workload, environment, cost center) enforced from day one; retrofitting tags is painful.
- Budgets with spend notifications at 50/80/100% per resource group, and a weekly review during migration.
- Activity Tracker routed to a retained bucket for the first audit cycle.
These are cheap now and expensive to reconstruct after an auditor asks for evidence.