Unlocking Greater Value: Why Moving from EKS to OpenShift Makes Strategic Sense
Modern enterprises are increasingly re-evaluating their Kubernetes strategy — not just from a technical standpoint, but from an operational, governance, and long-term platform perspective. While Amazon Elastic Kubernetes Service (EKS) provides a strong managed Kubernetes foundation on AWS, organizations looking for consistency, hybrid flexibility, and enterprise-ready capabilities often find greater long-term value in adopting Red Hat OpenShift.
Using the migration approach demonstrated in our GitHub repository — leveraging OpenShift Pipelines and the upstream Crane project — we’ve shown how stateful workloads can be migrated cleanly and repeatedly from EKS to OpenShift environments such as Red Hat OpenShift Service on AWS (ROSA) and other OpenShift variants.
But beyond migration mechanics, the bigger question is:
Why Move from EKS to OpenShift?
A Strategic Shift from Infrastructure to Enterprise Platform
🟦 Enterprise-Ready Platform
Beyond Kubernetes orchestration
- Integrated CI/CD (OpenShift Pipelines)
- Built-in image registry
- Operator lifecycle management
- Observability integration
- Centralized governance
Value: Reduced tooling sprawl, lower operational overhead, faster platform standardization.
🟩 Stronger Security & Compliance
Secure by design
- Default hardened configurations
- Security Context Constraints (SCCs)
- Policy-driven governance
- Enterprise authentication integration
Value: Reduced custom hardening effort, improved audit readiness, lower compliance risk.
🟨 Hybrid & Multi-Cloud Flexibility
Run anywhere consistently
- Public cloud (AWS, Azure, GCP)
- Managed OpenShift services (ROSA, Dedicated)
- On-prem data centers
- Edge environments
Value: Avoid cloud lock-in, meet sovereignty needs, optimize workload placement.
🟪 Portability Without Re-Architecture
Move workloads, not rewrite them
- Export and restore Kubernetes manifests
- Secure PVC migration
- Automated pipeline-driven transitions
Value: Lower migration risk, shorter transition timelines, minimal disruption.
🟧 Operational Consistency
Standardize across teams
- Unified developer experience
- Consistent policy enforcement
- Centralized governance model
Value: Reduced fragmentation, improved efficiency, better cross-team alignment.
🟥 Built-In Automation
Migration as a repeatable capability
- Declarative pipeline workflows
- Reusable across environments
- Centralized logging and tracking
- DevOps integration
Value: Controlled, auditable migrations with reduced manual intervention.
High Level Diagram
Demo
Steps to Migrate a Stateful Kubernetes Application from AWS EKS to ROSA using OpenShift Pipelines and Crane
Summary
This migration showed a Kubernetes-native way to move a stateful application with PVCs from Amazon Elastic Kubernetes Service (EKS) to Red Hat OpenShift Service on AWS (ROSA) using OpenShift Pipelines and the upstream Crane project.
The migration runs as a Tekton PipelineRun on ROSA, making the process automated, repeatable, and easy to observe. A unified kubeconfig gives Crane access to both clusters, allowing it to export application resources from EKS, recreate them on ROSA, and migrate persistent data.
OpenShift Pipelines handles orchestration and visibility, while Crane performs application and PVC migration without manual scripting. Together, they provide a clean, enterprise-ready approach for migrating stateful Kubernetes workloads with minimal operational overhead.
Notes & Limitations
Although demonstrated with ROSA, this migration approach is fully compatible with other OpenShift cluster variants as the destination environment.
PVC migration: Crane today, EBS snapshot as alternative automation We use Crane (e.g. transfer-pvc) to migrate workloads and PVC data from EKS to ROSA. For PVCs, an alternative and future plan is EBS snapshot–based migration: snapshot the EBS volume that backs the EKS PV (same AWS account), create a new EBS volume from that snapshot in the ROSA region/AZ, then create a PV (CSI volumeHandle) and PVC on ROSA. That avoids moving data over the wire and does not require VPC peering between EKS and ROSA; we may automate this (e.g. Tekton pipeline) later.
EKS tokens expire quickly — regenerate if the pipeline fails
Ensure network access between clusters
PVC migration speed depends on volume size and storage backend
Authors
Srikanth Valluru
