Migration Architecture

Architecture of Frontier Outrider — the migration pipeline design, assessment over MCP, flavor matching, network mapping and the job state machine.

Outrider is designed around a six-stage migration pipeline: assess, plan, transfer, convert, launch and verify. Assessment is served over MCP and reached through Remuda as outrider-assess; planning runs as a dry run and records a complete plan for each VM. What runs on the platform today is listed under Current scope.

High-Level Flow

   MCP client ──> Remuda (outrider-assess: token, audit)
                        │
                        v
   REST  /migrations    /mcp/assess    JSON-RPC 2.0  /jsonrpc
            \               │               /
             v              v              v
         ┌──────────────────────────────────┐
         │             outriderd            │
         │  Assessment                      │──> VMware client    (source VM detail)
         │  Planner: flavor match,          │──> OpenStack client (flavors, networks)
         │           network mapping        │
         │  Job state machine               │
         │  SQLite job store + event log    │
         └──────────────────────────────────┘

Migration Pipeline

Stage Purpose
Assess Read the source VM and the target cloud through the VMware and OpenStack clients.
Plan Match a flavor, map networks, select a transfer pipeline and record warnings before a move.
Transfer Copy source disks to target storage using the pipeline recorded in the plan.
Convert Prepare the guest to boot on OpenStack.
Launch Create the target instance with the matched flavor and mapped networks.
Verify Confirm the target instance against the plan.

Assess

For the requested VM (by name or ID), Outrider reads:

  • vCPU count and memory allocation
  • Disk layout (VMDK paths, sizes, thin/thick provisioning, controller types)
  • Network attachments (port groups, MAC addresses)

The assessment endpoint, /mcp/assess, is forwarded through Remuda as the MCP server outrider-assess. Remuda requires a token for each call and records an audit entry.

Plan: flavor matching

Outrider lists the available OpenStack flavors and selects one:

  • Flavor vCPUs must be ≥ source vCPUs
  • Flavor RAM must be ≥ source memory
  • Among qualifying flavors, the smallest (least resource waste) is selected
  • Boot-from-volume flavors (flavors with a root disk of 0 GB) are preferred for migrated workloads
  • If no flavor fits, the plan fails and includes a recommended flavor specification (vCPU, RAM, 0 GB root disk).

Example: a VMware VM with 4 vCPUs and 16GB RAM would match an OpenStack flavor with 4 vCPUs and 16GB RAM (or the next size up if no exact match exists).

Plan: network mapping

Each source network is mapped to an OpenStack network, using the requested target_network if one is given, otherwise an exact name match:

  • Mapped — a target network was found (mapped: true).
  • Unmapped — no matching OpenStack network; listed in the plan’s warnings, so the gap is visible before a move.

Plan: transfer pipeline

The plan records a transfer pipeline (A or B). pipeline=auto resolves to the configured default, B.

Service

outriderd is a containerized service (non-root image, health checks, Kubernetes Deployment and Service manifests) that plans one VM per job. It exposes the /mcp/assess MCP endpoint, a REST API and a JSON-RPC 2.0 endpoint, and stores jobs and events in SQLite. Jobs move through these states: planned, discovering, planning, then completed, failed, cancelled or rolled back.