Migrating from ECS to EKS Without Rebuilding Your Deployment Pipeline: 5 Paths Compared (2026)

Key points:

• Nothing converts ECS task definitions into production Kubernetes manifests. kompose reads Docker Compose files only, and Argo CD and Flux reconcile manifests you already wrote. The translation work - IAM, ingress, service discovery, autoscaling, secrets - is the migration.
• You can keep your deployment pipeline if you split it into build and deploy. ECR pushes, image builds, tests, and CI caching survive untouched; only the final aws ecs update-service step has to change.
• Short verdict: use kompose for a first manifest draft, Argo CD or Flux once your manifests are stable, AWS-native (EKS Auto Mode + Blueprints + Karpenter) if you have a platform team, and an internal developer platform like Qovery if you want EKS behavior without owning Helm charts, ingress controllers, and cluster upgrades.
• Qovery installs EKS in your own AWS account (BYOC), so the AWS bill, Savings Plans, and Reserved Instances stay in your name. Your existing GitHub Actions or GitLab CI keeps building and pushing images; Qovery owns the Kubernetes layer and the deploy step.
• Qovery is not AWS-only. The same model runs on GCP, Azure, Scaleway, or an existing Kubernetes cluster - which matters if leaving ECS is also a way out of single-cloud lock-in.
• Budget for the invisible parts: ECS task roles become IRSA or EKS Pod Identity, ALB target groups become Ingress or Gateway API, Cloud Map becomes Kubernetes Services plus CoreDNS, and awsvpc becomes the VPC CNI with pods-per-node ENI limits.

I have helped a lot of teams move off Amazon ECS, and the first thing I tell them is that the migration they are afraid of is not the one that hurts. Your containers are fine. Your CI build is fine. What hurts is everything ECS was quietly doing for you - IAM, load balancing, service discovery, secrets - that you now have to rebuild on Kubernetes. This article maps that work honestly and compares the five realistic paths, including where Qovery is the wrong choice.

Why do teams leave Amazon ECS for EKS in the first place?

ECS is a good orchestrator, and almost nobody leaves because it broke. They leave for three reasons: the Kubernetes ecosystem, portability, and hiring.

The ecosystem is the big one. Argo, Istio and Linkerd, External Secrets, Karpenter, KEDA, and the whole operator pattern have no real ECS equivalent. If you want any of that, you want Kubernetes.

Portability is the second. ECS task definitions are AWS-only artifacts. Kubernetes manifests run on any cloud, so moving to EKS is often step one of getting out of single-cloud lock-in. Kubernetes now runs in production for 82% of container users per the 2025 CNCF Annual Survey, which is also why hiring and tooling gravity point the same way.

Here is the honest counter-case: if you are a small team with a handful of Fargate services and no platform engineer, staying on ECS is often the right call. EKS gives you more power and hands you more surface to operate. Be sure you want the surface.

What actually breaks when you move from ECS to EKS?

Your container images and your CI build step almost never break. What breaks is everything wrapped around the container: task definitions, IAM, load balancer wiring, service discovery, logging, secrets, autoscaling, and networking.

There is no official converter from an ECS task definition to a Kubernetes Deployment, and you should not trust anything that claims to be one. The translation is manual, and it is the actual project. Here is the mapping I hand to teams on day one.

A few of these deserve a flag. EKS Pod Identity, launched at re:Invent 2023, is the newer and simpler successor to IRSA, and AWS now recommends it for new workloads unless you have a specific reason for IRSA. On networking, the VPC CNI caps pods per node based on ENI capacity; prefix delegation raises that ceiling a lot by assigning /28 prefixes instead of single IPs. Teams that skip this step hit a pod-density wall they never saw on ECS.

Can you really migrate to EKS without rebuilding your deployment pipeline?

Yes, and the trick is boring: split the pipeline into build and deploy, then replace only the deploy stage. A typical ECS pipeline is docker build, push to ECR, aws ecs update-service. The first two steps are orchestrator-agnostic and survive untouched.

The deploy step is the swap point. aws ecs update-service becomes one of three things: a manifest commit that GitOps reconciles, a helm upgrade, or an API or webhook call to a platform. Everything upstream - source checkout, tests, image build, ECR push, image tags, build caching - stays exactly as it is.

Keeping ECR and your build caching unchanged is what removes most of the risk and most of the diff in your repo. The change is contained to one job.

The hidden rebuild nobody budgets for is not the pipeline. It is the per-service Helm charts, the values files for each environment, and the env-var and secret plumbing. That is where the weeks actually go, and it is the part no YAML converter touches.

One more practical note: run ECS and EKS in parallel during cutover. Put both behind weighted ALB target groups or Route 53 weighted records, shift a slice of traffic to EKS, and keep ECS as your instant rollback target until you trust the new path.

Does kompose convert ECS task definitions to Kubernetes manifests?

No. kompose converts Docker Compose files to Kubernetes manifests. It does not read ECS task definitions, and a surprising number of migration posts get this wrong. Its own docs describe it as "a conversion tool for Docker Compose to container orchestrators such as Kubernetes," and the source repo confirms Compose is the only input.

Some teams use it indirectly: they keep a docker-compose.yml that mirrors production, run kompose, then hand-edit the output. That works if your Compose file is honest. It does nothing if the file drifted from production three years ago.

Even on a good day, kompose output is missing the things that make a manifest production-ready: resource requests and limits, liveness and readiness probes, Ingress, HPA, IRSA or Pod Identity annotations, PodDisruptionBudgets, and topology spread. You get the shape of a Deployment, not a deployable one.

My honest verdict: kompose saves you hours on the first draft of a small stateless service. It does not save weeks, and it is not a migration platform.

Do you need Argo CD or Flux to migrate from ECS to EKS?

No, and adopting them on day one usually slows the migration down. Argo CD and Flux are both CNCF graduated continuous delivery tools, and they are excellent. But they continuously reconcile manifests you already have, which is exactly the artifact an ECS team does not have yet. They solve delivery, not translation.

The GitOps model is genuinely good: Git as the source of truth, drift detection, declarative rollback by reverting a commit. Argo CD leans on a strong UI, app-of-apps, and ApplicationSets. Flux leans on lightweight controllers, native Helm/Kustomize/OCI support, and a clean Terraform bootstrap. Pick on taste.

The risk is sequencing. Learning a new orchestrator and a new deploy model at the same time doubles the surface where things go wrong. Get one service running on EKS, stabilize its manifests, then put GitOps in front of it.

And even with GitOps, something still needs an owner: the ingress controller, cert-manager, node upgrades, add-on lifecycle, multi-env promotion, preview environments, and RBAC. GitOps syncs your manifests. It does not run your cluster. That is why many teams run Argo CD or Flux for cluster add-ons and use a platform for application delivery - the two are complementary, not competing.

What do the AWS-native options cost you in engineering time?

AWS ships every building block for EKS - EKS Auto Mode, EKS Blueprints, Karpenter, the AWS Load Balancer Controller, CodePipeline - but zero migration path from ECS and zero opinion about how your developers ship. The price is paid in platform engineering hours, not license fees.

EKS Auto Mode, a recent addition, is the most hands-off AWS option. Per the AWS docs it manages compute autoscaling (via Karpenter), pod and service networking, Elastic Load Balancing integration, cluster DNS, and block storage as core components, and it keeps nodes patched on a 21-day maximum lifetime. What it does not do is translate your ECS services or decide how developers deploy. That is still yours.

EKS Blueprints and Terraform modules get a cluster bootstrapped fast, at the cost of an ongoing module-upgrade tax every time you bump a version. Karpenter is the strongest cost lever on EKS because it consolidates workloads onto fewer nodes and terminates idle capacity. That matters, because most Kubernetes clusters are badly overprovisioned - Datadog's State of Containers and Serverless report has shown for years that a large share of workloads use well under half the CPU and memory they request.

The real bill has three lines. The EKS control plane is $0.10 per cluster per hour on standard support, with a $0.50 per hour surcharge once a version hits extended support (so $0.60 per hour). Auto Mode adds a management fee that varies by EC2 instance type. And then there is the salary line for whoever owns upgrades, which dwarfs both. For comparison, ECS charges nothing for orchestration - you only pay for the compute - so budget for that control-plane and headcount delta explicitly.

Who this fits: teams with a dedicated platform team and existing Terraform discipline. If that is you, AWS-native is often the right answer, and I would not talk you out of it.

How does Qovery handle an ECS to EKS migration, and what does it not do?

Qovery is an internal developer platform that provisions and operates EKS inside your own AWS account, generates the Kubernetes resources your ECS services need, and takes over only the deploy step of your pipeline. Your CI keeps building and pushing to ECR exactly as it does today. Below, I will also tell you who it is wrong for.

Qovery is BYOC first. It installs into your own AWS account, so the AWS bill, Savings Plans, and Reserved Instances stay in your name, and your data stays in your VPC. Qovery's own site is blunt about it: "Your data and compute stay inside your own AWS, GCP, or Azure account."

The ECS mental model maps cleanly, which is why migrations go fast. A Qovery application roughly corresponds to an ECS service: a container image, a port, env vars, secrets, scaling rules, and health checks. Qovery generates the Kubernetes objects behind that - the Deployment, Service, Ingress, HPA, and secret wiring - so you describe the service, not the YAML.

What Qovery owns so you do not author it: ingress and TLS, autoscaling, secret and env-var injection per environment, and managed cluster upgrades and patches. On the pipeline side, you can deploy by git-push, or keep GitHub Actions and GitLab CI as the build step and trigger the deploy with an API call. Either way there are no per-service Helm charts to write and maintain.

You also get things ECS never gave you: preview environments spun up per pull request and torn down automatically, environment auto-stop for non-production so idle staging stops burning money, per-environment RBAC instead of hand-rolled IAM policies per task role, and managed databases backed by cloud services like RDS instead of stateful workloads you babysit on the cluster.

Qovery is not AWS-only. The same model runs on GCP, Azure, Scaleway, or an existing Kubernetes cluster, self-managed or on-prem. If your ECS exit is also a multi-cloud or sovereignty decision, that portability is the point.

Here is where Qovery is not the right fit, and I would rather you hear it from me. If you want manifest-level control of every CRD, run deeply custom operators or a service mesh you tune by hand, or you already have a mature platform team happy with Argo CD and Terraform, Qovery will feel like it is in your way. In that case, go AWS-native. And if you do adopt Qovery, you can still run Argo CD or Flux for cluster-level add-ons while Qovery handles application delivery - that combination is common and it works.

Which option is best for migrating ECS to EKS without rebuilding your pipeline?

If you have a platform team, the best path is AWS-native: EKS Auto Mode for the cluster, Karpenter for cost, and Argo CD or Flux for delivery. If you do not have a platform team, Qovery is the fastest route to EKS that leaves your CI build step untouched. kompose is a drafting tool, not a migration platform, and Argo CD and Flux are delivery tools that assume you already wrote the manifests.

Decide in this order: do you have a platform engineer, how many services you run, how much Kubernetes control you actually need, and how much of your pipeline you want to keep. The control-plane and node costs are similar across every path. The variable that actually differs is headcount and time to your first production service.

On lock-in: Kubernetes manifests are portable, ECS task definitions are not, and Qovery keeps both the cluster and the cloud account yours. Be fair about where each option wins outright - Argo CD has the best UI, Flux has the cleanest Terraform bootstrap, AWS-native gives you total control, and staying on ECS is cheapest if your estate is small and stable.

What does a realistic ECS to EKS migration plan look like?

The order matters more than the tooling. Here is the six-step sequence I give every team.

1. Inventory everything. Task definitions, task roles, secrets, ALB listener rules, scheduled tasks, and anything stateful. The things you forget are always the IAM policies and the cron jobs.
2. Stand up the cluster with add-ons before any workload. Ingress, logging, secrets, and autoscaling need to exist before the first pod, or let a platform do this part for you.
3. Migrate one stateless, non-critical service end to end. Measure p95 latency and monthly cost against its ECS baseline. One service proves the whole path.
4. Parallel run behind weighted traffic. Weighted ALB target groups or Route 53 records, with ECS kept as the rollback target until you trust EKS.
5. Do the hard cases last. Scheduled tasks, sticky sessions, long-running jobs, stateful services, anything with an EFS mount.
6. Standardize so service #10 takes an hour, not a week. GitOps, a platform, or both.

The failure modes I keep seeing are predictable: migrating the hardest service first, copying ECS CPU and memory straight into Kubernetes requests and limits, ignoring pods-per-node ENI limits, shipping with no PodDisruptionBudgets so the first node upgrade takes you down, and having no named owner for cluster version upgrades. Avoid those five and the migration is mostly logistics.

Is there a tool that converts ECS task definitions to Kubernetes manifests?

No. There is no official or reliable tool that turns an ECS task definition into production Kubernetes manifests. kompose converts Docker Compose, not ECS, and GitOps tools like Argo CD and Flux reconcile manifests you already wrote. The translation - IAM, ingress, service discovery, autoscaling, secrets - is manual work, which is the real substance of the migration.

Does kompose work with ECS, or only Docker Compose?

Only Docker Compose. kompose reads a docker-compose.yml and emits Kubernetes manifests; it has no knowledge of ECS task definitions. Some teams keep a Compose file that mirrors production and use kompose to draft manifests, then hand-edit to add probes, limits, Ingress, and HPA. It is a drafting shortcut, not a migration path.

Do I need Argo CD or Flux to migrate from ECS to EKS?

No. Both are CNCF graduated GitOps tools that continuously reconcile manifests, and they are great once your manifests are stable - but they do not author manifests, so they do not help with the ECS-to-EKS translation itself. I recommend getting one service running on EKS first, stabilizing the manifests, then adding GitOps. Many teams also run them for cluster add-ons while a platform handles application delivery.

Can I keep my existing GitHub Actions or GitLab CI pipeline after moving from ECS to EKS?

Yes, if you split the pipeline into build and deploy. Your source checkout, tests, image build, ECR push, and caching are orchestrator-agnostic and stay unchanged. Only the final deploy step changes: aws ecs update-service becomes a manifest commit for GitOps, a helm upgrade, or an API call to a platform like Qovery that owns the deploy.

Is EKS more expensive than ECS?

On paper, yes, because EKS charges $0.10 per cluster per hour for the control plane (plus a $0.50 surcharge in extended support), while ECS charges nothing for orchestration. But the control-plane fee is usually a rounding error next to compute. The real cost of EKS is the engineering time to operate it, which is exactly the line a platform or AWS Auto Mode is meant to compress.

How long does an ECS to EKS migration take?

It depends entirely on how many services you have and whether you standardize. The honest shape is that your first service takes the longest because you are building the cluster and add-ons underneath it, and every service after that gets faster if you invest in standardization. I would not trust any guide that quotes you a fixed timeline without knowing your service count and your statefulness.

How does Qovery help migrate from ECS to EKS, and does it work outside AWS?

Qovery provisions and operates EKS inside your own AWS account, maps each ECS service to a Qovery application, and generates the Kubernetes objects behind it, so your CI keeps building and pushing to ECR and only the deploy step changes. It owns ingress, TLS, autoscaling, secrets, and cluster upgrades, and adds preview environments and per-environment RBAC. And no, it is not AWS-only: the same model runs on GCP, Azure, Scaleway, and existing Kubernetes clusters, which is useful if the ECS exit is also a multi-cloud move.

Moving off ECS is not the scary part. Rebuilding the IAM, ingress, service discovery, and secrets that ECS hid from you is - and no tool converts that for you automatically. Decide who owns the Kubernetes layer before you write the first manifest. If that owner is a platform team, go AWS-native. If it is not, and you still want EKS inside your own cloud account with your CI intact, try Qovery free.