You wouldn’t load a bus
onto a cargo plane.
Yet that is exactly what lift-and-shift migration does. It takes on-premises infrastructure — designed for ground transport — and forces it into the cloud without redesigning for the new medium. Exodus takes a different approach: modernize, don’t transplant.
Bus service vs. air travel
Bus service
On-premises / legacy
- Fixed routes, fixed schedules
- Passengers (workloads) stuck on one vehicle
- Driver (ops team) handles everything manually
- Road conditions (hardware) limit speed
- No altitude — local reach only
- Bus breaks down, everyone waits
Air travel
Cloud-native / OpenOva
- Dynamic routing, global reach
- Passengers (workloads) board any flight
- Autopilot (Specter) handles operations
- Altitude (cloud) removes physical limits
- Global network of airports (regions)
- If one plane has issues, rebook on the next
Five conditions that ground your workloads
Before any workload can fly, it needs a medical check. These five conditions are the most common blockers we find during assessment. Each has a treatment plan.
Life support dependency
Application cannot survive without a specific proprietary runtime, driver, or OS feature
Identify the dependency, find cloud-native equivalent, or containerize with compatibility layer
Siamese twin syndrome
Two or more applications are so tightly coupled they cannot be deployed independently
Map the coupling, introduce API boundaries, migrate as a unit or decouple first
Compromised immune system
Application has no health checks, no metrics, no logs. Invisible to monitoring.
Add OTel instrumentation, standardize health endpoints, integrate with Grafana stack
Fixed treatment protocol
Application requires specific manual procedures for deployment, scaling, or recovery
Codify runbooks into Kubernetes operators or Temporal workflows. Make procedures declarative.
Weak vital signs
Application performance is unknown. No baselines. No SLOs. No capacity model.
Establish baselines in current environment before migration. Set SLOs. Use KEDA/VPA for autoscaling.
Preparing for the journey
Check-in
State management
Externalize state from applications. Move session data to Valkey, files to MinIO, databases to CNPG. No carry-on luggage in the overhead bin.
Security screening
Auth & secrets
Migrate credentials to OpenBao. Replace hardcoded secrets with External Secrets Operator. Every passenger gets screened.
Gate assignment
Service discovery
Replace static IPs and hostfiles with Kubernetes services, Cilium networking, and ExternalDNS. Dynamic gate assignment.
Flight standards
Cloud-native compliance
Enforce resource limits, pod security, network policies via Kyverno. Every flight meets safety standards before takeoff.
5-phase structured migration
ASSESS
Week 1-2Full inventory and pre-flight medical check. Map dependencies, identify the five conditions, evaluate AI-readiness.
PLAN
Week 2-3Design the flight plan. Target architecture, migration sequence, rollback strategy, and treatment plans for each condition.
PILOT
Week 3-6First flight. Migrate a non-critical workload end-to-end to validate the approach.
MIGRATE
Week 6-12Full fleet transition. Phased production migration with parallel running and continuous validation.
OPTIMIZE
Week 12+Cruising altitude. Performance tuning, cost optimization, and legacy decommission.
From proprietary to open source
Platform migrations
Observability migrations
Database migrations
Security & identity migrations
Breaking free from vendor lock-in
The most common Exodus migrations start with unchaining from proprietary platforms. Each path has been proven in production.
VMware
vSphere tax, per-socket licensing, Broadcom uncertainty
Eliminate hypervisor licensing entirely. K3s runs directly on bare metal. Typical savings: 60-80% on infrastructure costs.
Red Hat OpenShift
Per-core subscription, forked K8s, ecosystem restrictions
Pure upstream Kubernetes. Every component is the actual open-source project, not a fork. No subscription lock-in.
Oracle
License audits, per-processor fees, Java SE traps
Full database migration to CNPG. No license audits. No per-processor fees. MongoDB workloads via FerretDB.
Why air travel beats bus service
Cost efficiency
Eliminate proprietary licensing. Pool infrastructure. Pay for what you use. 60-85% cost reduction.
Global reach
Multi-region deployment. Independent clusters in any geography. Disaster recovery built in.
Speed & agility
Deploy in minutes, not months. GitOps-native. Self-service via Catalyst IDP.
Professional infrastructure
Dedicated control tower (Specter). Standardized procedures. Continuous compliance.
Complete analogy mapping
| Bus service (on-prem) | Air travel (cloud-native) |
|---|---|
| Bus service | On-premises infrastructure |
| Air travel | Cloud-native platform (OpenOva) |
| Passengers | Workloads / applications |
| Bus driver | Operations team (manual) |
| Autopilot | Specter (AI operations) |
| Bus routes | Network topology (fixed) |
| Flight routes | Cilium service mesh (dynamic) |
| Bus depot | Data center |
| Airport | Kubernetes cluster |
| Control tower | Grafana observability stack |
| Baggage handling | Data migration (CNPG, Valkey, Strimzi) |
| Check-in counter | State externalization |
| Security screening | OpenBao + ESO (secrets) |
| Gate assignment | Service discovery + DNS |
| Flight standards | Kyverno policies |
| Pre-flight medical | Workload assessment |
| Fleet modernization | Exodus migration program |
Start your assessment
The pre-flight medical check starts in week 1. Zero downtime. Full modernization. Not lift-and-shift.