Kubernetes / OpenShift to AKS Migration Center¶

The definitive resource for migrating from self-managed Kubernetes and Red Hat OpenShift to Azure Kubernetes Service (AKS), Azure Red Hat OpenShift (ARO), and AKS Hybrid.

Who this is for¶

This migration center serves federal CIOs, CTOs, platform engineering leads, DevOps engineers, and application architects who are evaluating or executing a migration from self-managed Kubernetes clusters (kubeadm, Rancher, k3s, Tanzu) or Red Hat OpenShift (OCP 4.x) to Azure-managed container platforms. Whether you are responding to an Azure-first mandate, eliminating control-plane operational burden, consolidating container infrastructure onto a single hyperscaler, addressing compliance gaps (FedRAMP, STIG, FIPS), or modernizing data workloads with CSA-in-a-Box on AKS, these resources provide the evidence, patterns, and step-by-step guidance to execute confidently.

Quick-start decision matrix¶

Target platform decision matrix¶

Before starting, choose your target platform. The decision depends on your current platform, OpenShift dependency depth, hybrid requirements, and compliance posture.

Decision flowchart¶

flowchart TD
    A[Current Platform?] --> B{OpenShift?}
    B -->|Yes| C{Heavy OCP dependency?}
    B -->|No| D{Need on-prem?}
    C -->|Yes - Routes, SCC, OLM| E[ARO]
    C -->|No - Standard K8s workloads| F{Need on-prem?}
    D -->|Yes| G{Connected?}
    D -->|No| H[AKS]
    F -->|Yes| G
    F -->|No| H
    G -->|Yes - Hybrid| I[AKS Hybrid / Arc-enabled]
    G -->|No - Disconnected/Edge| J[AKS on Azure Stack HCI]

    H --> K[Deploy on Azure Gov for federal]
    E --> K
    I --> K
    J --> K

    style H fill:#0078d4,color:#fff
    style E fill:#ee0000,color:#fff
    style I fill:#5c2d91,color:#fff
    style J fill:#008272,color:#fff

Strategic resources¶

These documents provide the business case, cost analysis, and strategic framing for decision-makers.

Migration guides¶

Domain-specific deep dives covering every aspect of a container platform migration.

Tutorials¶

Step-by-step walkthroughs for common migration scenarios.

Technical references¶

Government and federal¶

How CSA-in-a-Box fits¶

CSA-in-a-Box extends AKS from a generic container platform into a governed data and AI platform. Container workloads on AKS integrate directly with the CSA-in-a-Box architecture:

• Containerized data pipelines: Spark on Kubernetes (via Spark Operator) runs on AKS, reading from and writing to ADLS Gen2 / OneLake. Jobs are governed by Unity Catalog and lineage-tracked in Purview.
• Model serving: AI models trained in Azure ML or Databricks deploy to AKS GPU node pools (NC/ND series) using Triton Inference Server, vLLM, or TorchServe. Model endpoints register in AI Foundry and appear in the CSA-in-a-Box data marketplace.
• Event-driven data processing: KEDA on AKS scales data consumers based on Event Hubs partition lag. Consumers write to the medallion architecture (bronze/silver/gold) on ADLS Gen2.
• dbt runners: Containerized dbt jobs execute as Kubernetes CronJobs, running transformations against Databricks SQL Warehouses or Fabric SQL endpoints with contract validation.
• Data API layer: REST and GraphQL APIs serving data products from the CSA-in-a-Box data marketplace run on AKS with Entra Workload Identity authentication, AGIC traffic management, and Container Insights observability.
• Compliance integration: Azure Policy assignments on AKS clusters enforce the same compliance baselines (FedRAMP, CMMC, HIPAA) that govern the rest of the CSA-in-a-Box platform.

flowchart LR
    subgraph AKS["AKS Cluster"]
        SPARK[Spark Operator]
        MODEL[Model Serving<br>Triton / vLLM]
        KEDA_C[KEDA Consumers]
        DBT[dbt Runners]
        API[Data APIs]
    end

    subgraph CSA["CSA-in-a-Box Platform"]
        ADLS[ADLS Gen2 / OneLake]
        UC[Unity Catalog]
        PURV[Purview]
        DBX[Databricks SQL]
        EH[Event Hubs]
        AIF[AI Foundry]
        MKT[Data Marketplace]
    end

    SPARK --> ADLS
    SPARK --> UC
    MODEL --> AIF
    KEDA_C --> EH
    KEDA_C --> ADLS
    DBT --> DBX
    API --> MKT
    PURV --> AKS

    style AKS fill:#0078d4,color:#fff
    style CSA fill:#5c2d91,color:#fff

Migration timeline overview¶

gantt
    title Typical Kubernetes/OpenShift to AKS Migration (24 weeks)
    dateFormat  YYYY-MM-DD
    section Discovery
    Inventory clusters & workloads         :a1, 2026-05-04, 2w
    section Landing Zone
    Deploy AKS + ACR + networking          :a2, after a1, 3w
    section Pilot
    Migrate pilot stateless app            :a3, after a2, 3w
    section Stateless Migration
    Migrate remaining stateless workloads  :a4, after a3, 6w
    section Stateful Migration
    Migrate StatefulSets + data            :a5, after a3, 6w
    section Data Platform
    CSA-in-a-Box integration on AKS        :a6, after a4, 6w
    section Decommission
    Decommission on-prem clusters          :a7, after a5, 4w

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team Related: Migration Playbook | VMware Migration Center | AWS Migration