How to Migrate from ECS to EKS Without Rebuilding Your Deployment Pipeline (4 Options Compared)

Key Points:

• You do not need to rebuild your CI pipeline to move from Amazon ECS to Amazon EKS. Build, test, image build, and push to Amazon ECR stay byte-for-byte identical. Only the deploy step changes, typically 5 to 30 lines in a GitHub Actions or GitLab CI file, and that step can be delegated to a platform instead of rewritten as Kubernetes YAML.
• There are four realistic paths: (1) DIY Kubernetes manifests plus Helm plus Argo CD or Flux, (2) AWS-native tooling (App2Container, EKS Blueprints, Karpenter, AWS Load Balancer Controller), (3) a Kubernetes consultancy such as MeteorOps that builds a bespoke platform you then own, or (4) an internal developer platform like Qovery that generates and operates the Kubernetes layer inside your own AWS account.
• Argo CD and Flux are both CNCF graduated projects and best-in-class GitOps engines, but they are delivery tools, not migration tools. They reconcile manifests that already exist. Neither one will convert an ECS task definition into a Deployment, Service, Ingress, HPA, IRSA role, and secret wiring for you.
• Cost is not the reason to stay on ECS. EKS adds a per-cluster control plane fee that ECS does not charge, while EC2 and Fargate compute is priced identically on both, so the real budget goes to engineer-time on upgrades, add-ons, and idle non-production environments.
• Pick by team shape, not tool popularity. Under roughly 15 engineers with no dedicated platform hire, an IDP wins. With one or more full-time platform engineers who want Kubernetes as a core competency, DIY GitOps wins on control. A consultancy gets you live once; a platform keeps you live through every Kubernetes version upgrade after that.

The pipeline you get to keep is the one that only builds a container image and pushes it to Amazon ECR. The thing you actually choose is who owns the deploy step and the cluster after it. Use Argo CD or Flux if you have a platform engineer, a consultancy like MeteorOps if you want a bespoke platform you own outright, and an internal developer platform like Qovery if you want a real EKS cluster in your own AWS account without writing or maintaining the Kubernetes layer yourself.

I have watched a lot of teams treat "move from ECS to EKS" as a full pipeline rewrite, then quietly stall for a quarter. Most of that fear is misplaced, and the rest of this piece is the concept mapping, the four options compared fairly, a decision rule by team size, and the real 2026 cost numbers to prove it.

What actually has to change when you migrate from ECS to EKS?

Only two things change in a typical ECS-to-EKS migration: the deploy step in your CI job, and the day-2 operational layer around the cluster. Build, test, image build, tag, and push to Amazon ECR are untouched, which is why most of an existing pipeline survives intact, and why the real work hides in the cluster rather than the pipeline.

Here is the mapping that makes this page more useful than reading the AWS docs cold. Every ECS concept has a direct Kubernetes equivalent, and the work is configuration, not reinvention.

The deploy job itself is usually 5 to 30 lines out of a much larger CI file. "We had to rebuild the pipeline" is mostly a story teams repeat to each other. What genuinely lands on someone's plate is the day-2 layer: Kubernetes minor version upgrades, add-on management (VPC CNI, CoreDNS, kube-proxy, EBS CSI), node autoscaling, pod CIDR and subnet planning, RBAC, cost attribution, and the observability CloudWatch used to hand you for free.

That upgrade cadence is not optional. A Kubernetes minor version gets 14 months of standard support on EKS, then 12 months of extended support at a higher price, and upstream ships a new minor version roughly every four months (Amazon EKS version lifecycle, checked September 2026). Someone owns that clock every week.

The honest trade-off: ECS hides Kubernetes complexity and charges nothing for its control plane, while EKS gives you portability and the broadest ecosystem in infrastructure. Kubernetes now runs in production for 82% of container users, according to the 2025 CNCF Annual Survey (published January 2026). That ecosystem is what you are buying. Someone on your team has to own the difference.

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

Yes, as long as the contract between CI and the runtime stays at the container image level. If CI's only job is to build an immutable image and push it to ECR, the deploy step becomes a single swappable command. A rebuild only becomes unavoidable if you also decide to hand-author Kubernetes YAML for every service during the same migration.

Define the image contract explicitly: CI builds, tests, and pushes to ECR with an immutable tag (the git SHA, never latest), then hands off. Everything downstream is a deploy concern, not a CI concern. That single discipline is what lets you swap runtimes without touching your build.

There are three legal swaps for the deploy job. Conceptually, aws ecs update-service --force-new-deployment becomes one of:

• helm upgrade --install my-svc ./chart --set image.tag=$GIT_SHA
• a commit to a manifests repo that Argo CD or Flux reconciles
• an internal developer platform call, such as a qovery CLI command, an API call, or a Qovery GitHub Action step

The rest of your CI file does not care which one you pick. What genuinely needs rework regardless of path: SIGTERM handling and terminationGracePeriodSeconds (Kubernetes sends SIGTERM and waits 30 seconds by default before SIGKILL, per the pod lifecycle docs), health check semantics (ALB health checks become readiness and liveness probes), secret injection, service discovery names (Cloud Map becomes Kubernetes DNS), sticky sessions, and anything reading the ECS task metadata endpoint.

Most teams who say they "had to rebuild the pipeline" actually chose to rebuild their deployment model at the same time, then blamed EKS for the timeline. Keep those two projects separate.

One trap that quietly doubles bills: ECS CPU units and memory reservation do not translate 1:1 into Kubernetes requests and limits. ECS reserves at the task level in CPU units (1024 = 1 vCPU) and MiB (task definition parameters). Kubernetes uses per-container requests and limits, where exceeding a memory limit gets the container OOMKilled and exceeding a CPU limit gets it throttled (managing resources for containers). Copy the numbers blindly and you either over-provision every node or get paged in week two.

Keeping the image contract stable is also what protects your delivery metrics during the cutover. DORA tracks deployment frequency and change lead time among its core software delivery metrics (dora.dev); a migration that leaves the build untouched keeps both from regressing while you move.

What are the main options for an ECS to EKS migration, and how do they compare?

There are four categories, and they answer different questions. GitOps engines (Argo CD, Flux) automate delivery of manifests you already wrote. AWS-native tooling (App2Container, EKS Blueprints, Karpenter) hands you building blocks. A consultancy such as MeteorOps designs and delivers a bespoke platform you own. An internal developer platform such as Qovery generates and operates the Kubernetes layer for you. Choose based on who owns the cluster the Monday after the migration ends.

Argo CD and Flux are excellent. Argo graduated in the CNCF on December 6, 2022 and Flux on November 30, 2022; Argo CD carries about 24,000 GitHub stars and Flux around 8,400 as of September 2026 (argo-cd, flux2). Their reconciliation and drift detection are best in class. The limitation is just as plain: they deploy manifests that must already exist. Neither converts an ECS task definition into a Deployment, Service, Ingress, HPA, and IRSA role. They solve continuous delivery, not ECS-to-EKS conversion. If you are torn between the two, see our Flux vs Argo CD breakdown.

Helm is the packaging and templating standard, and you will probably use it whichever path you pick. The catch is that authoring and maintaining one chart per microservice is exactly the work most teams are trying to avoid when they ask this question.

The AWS-native path gives you free, well-documented building blocks: EKS Blueprints and the AWS CDK bootstrap the cluster, Karpenter provisions and consolidates nodes, the AWS Load Balancer Controller handles Ingress, and IRSA or EKS Pod Identity handles permissions. AWS App2Container containerizes Java and ASP.NET applications and can generate deployment artifacts, though note AWS closed it to new customers after November 7, 2025 and now points to AWS Transform (App2Container supported applications). Powerful and cheap, but it hands you infrastructure, not a developer workflow.

MeteorOps and comparable Kubernetes/DevOps consultancies deliver an expert-led platform build with a fast path to a well-designed EKS plus GitOps setup. This is genuinely the right answer when you want something bespoke that you own outright. The trade-off is that ownership, upgrades, and on-call transfer to your team the day the engagement ends.

Portainer is a management UI over Docker and Kubernetes. It is useful for ECS-era teams who miss a console, but it does not generate your application topology, provision EKS, or own cluster lifecycle. Prometheus with Grafana, or CloudWatch Container Insights, is required on day one, but it is observability, not a migration path. Place both correctly rather than expecting them to move workloads.

Qovery installs, runs, and upgrades a standard EKS cluster inside your own AWS account (BYOC), generates the Kubernetes objects from your service definitions, and keeps deploys as a git push, a CLI or API call, or a step in your existing GitHub Actions or GitLab CI job. It adds preview environments per pull request, environment auto-stop for non-production, per-environment RBAC, managed cluster upgrades, and databases backed by managed cloud services. The same workflow runs on GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster, so it is not an AWS-only bet. If you already run Argo CD, the two coexist.

Which option should you choose based on your team size and who owns the cluster?

Use one rule. If you have at least one full-time platform engineer who wants Kubernetes as a core competency, go DIY with Argo CD or Flux. If you do not, use an internal developer platform and keep your engineers on product. If you need deep expertise once but control forever, hire a consultancy like MeteorOps and pair it with either path.

The build-vs-buy math is dominated by people, not infrastructure. An EKS control plane is $0.10 per cluster per hour, about $73 a month (EKS pricing, checked September 2026). A fully loaded platform engineer in the US averages around $217,000 in total pay, with a typical range of roughly $173,000 to $277,000 (Glassdoor, checked September 2026). The control plane is a rounding error next to a salary and the upgrade cadence that keeps consuming that salary's weeks.

That cadence is the recurring tax. With 14 months of standard support per minor version and a new upstream minor roughly every four months (EKS version lifecycle), a team that stays current runs an upgrade every few months, forever. Fall behind and you pay $0.60 per cluster per hour for extended support instead of $0.10 (EKS pricing). And platform teams are becoming standard, not exotic: Gartner has predicted that 80% of software engineering organizations will establish platform teams by 2026 (Gartner). The question is whether yours builds the platform or buys it.

DIY is genuinely the right call for unusual networking, custom CRDs and operators, a service mesh requirement, strict compliance boundaries, or multi-tenant clusters you sell to customers. An IDP is the right call when you want ECS-like simplicity on top of standard EKS, self-service environments for developers, and nobody free to babysit a version upgrade every few months. These combine rather than compete: run Qovery alongside your existing GitHub Actions, keep Argo CD for a subset of workloads, or bring in a consultancy to design the VPC and landing zone while an IDP runs the developer workflow. The goal is to keep engineers on product, which is the whole point of an internal developer platform.

What does a low-risk ECS to EKS migration plan look like step by step?

A safe ECS-to-EKS migration is incremental and reversible: stand up EKS beside ECS in the same VPC, move one low-traffic stateless service, shift traffic at the DNS or load balancer level, then repeat service by service. Nothing gets deleted until the last workload has run cleanly in production for weeks.

• Step 0, inventory. List task definitions, environment variables, secrets, task IAM roles, load balancers, target groups, and the stateful dependencies (RDS, ElastiCache, S3, SQS) that should not move at all.
• Step 1, cluster. Create EKS in the same VPC or a peered one so security groups and RDS access keep working. Decide managed node groups vs Karpenter vs Fargate profiles, and plan pod CIDRs before you run out of IPs, because the VPC CNI assigns real VPC IP addresses to pods and you may need prefix delegation to raise density (increase available IP addresses).
• Step 2, pilot. Pick a stateless, internal, low-traffic service and run it with the exact same image and env vars. The success criterion is boring parity, not improvement.
• Step 3, swap the deploy step. Replace aws ecs update-service --force-new-deployment with helm upgrade --install, a GitOps commit, or an IDP deploy command. Everything upstream of the ECR push stays the same.
• Step 4, port cross-cutting concerns once, not per service. Ingress and TLS via the AWS Load Balancer Controller with ACM or cert-manager, IRSA or EKS Pod Identity, External Secrets Operator, Fluent Bit into CloudWatch Container Insights, Prometheus metrics, and HPA or KEDA scaling. We wrote up the NLB-to-ALB-Controller move from our own experience.
• Step 5, traffic shift. Use weighted Route 53 records or two target groups on the same ALB. Keep the ECS service warm with at least one task so rollback is instant.
• Step 6, repeat and decommission. Migrate service by service, then remove ECS services, clean up orphaned IAM roles, target groups, and ALBs, and set cost guardrails before the first full EKS bill reaches finance.

The failure modes worth naming out loud: no SIGTERM handling, under-sized pod CIDRs, 1:1 copies of ECS CPU and memory into requests and limits, no PodDisruptionBudgets before the first node rotation, and no owner assigned for the next Kubernetes version upgrade. AWS publishes general container platform prescriptive guidance, and we cover the same ground with a Qovery lens in our complete ECS-to-EKS guide.

How much does EKS cost compared to ECS, and where does the migration budget actually go?

EKS adds a fixed control plane fee of $0.10 per cluster per hour that ECS does not charge, while EC2 and Fargate compute is billed identically on both. Amazon ECS has no orchestration or per-cluster fee: "There is no additional charge for Amazon ECS orchestration. You pay only for the underlying compute and resources" (ECS pricing, checked September 2026). Fargate in us-east-1 is about $0.04048 per vCPU-hour and $0.004445 per GB-hour, and that rate applies whether the task runs on ECS or the pod runs on EKS (Fargate pricing, checked September 2026). So compute is not the delta. The control plane is a rounding error next to people-time and idle capacity.

Two things actually move the bill. The multi-cluster multiplier: one cluster per environment (dev, staging, prod) multiplies that $0.10 per hour, which is why many teams run namespaced environments on fewer clusters, and why a missed upgrade turns into a recurring increase once a version slides into extended support at $0.60 per cluster per hour (EKS pricing). And waste: across tens of thousands of clusters, Cast AI measured average CPU utilization at just 8% and memory at 20% in its 2026 State of Kubernetes Optimization Report. Non-production environments running 24/7 and over-provisioned requests are where the money leaks.

The levers differ by path. Karpenter consolidates and bin-packs nodes as the AWS-native cost lever (Karpenter disruption docs), and we have written about squeezing up to 60% off with EKS and Karpenter and broader Kubernetes cost optimization. Environment auto-stop for non-production is the IDP lever. Either way, a platform license is usually the smallest number on the page next to a fully loaded platform engineer salary and the upgrade cadence that keeps consuming their weeks.

How does Qovery handle an ECS to EKS migration differently?

Qovery installs and operates a standard Amazon EKS cluster inside your own AWS account and turns your existing containerized services into managed Kubernetes workloads. The output of the migration is a real, portable EKS cluster you own, while developers keep deploying with a git push or the exact CI job they already had.

BYOC in plain terms: the cluster, the VPC, and the bill live in your AWS account, so existing Reserved Instances, Savings Plans, and enterprise discounts still apply. You are not renting compute from a vendor, and there is no proprietary runtime to unwind later if you leave.

What it removes from the ECS-to-EKS checklist is the part teams dread: manifest authoring, Ingress and TLS wiring, cluster and add-on upgrades, per-environment RBAC, and databases backed by managed cloud services like RDS instead of hand-rolled operators. What developers gain that ECS never gave them is preview and ephemeral environments per pull request, plus automatic environment auto-stop for non-production, which is usually where the migration ROI first shows up on the invoice.

Pipeline compatibility is the whole point: keep GitHub Actions or GitLab CI for build, test, and ECR push, then call Qovery for the deploy step, or let a git push trigger the deployment directly. And it is not AWS-only. The identical workflow runs on GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster, which matters the day a second region, a second provider, or a customer-hosted deployment lands on the roadmap. If you would rather not write Kubernetes YAML at all, that is the design goal.

To be fair about the edges: if you need deeply custom CRDs, a service mesh, or a bespoke cluster topology, a DIY Argo CD or Flux setup, or a consultancy-built platform, may fit better. Check the Qovery docs to verify current capabilities against your requirements rather than taking my word for it.

What is the best platform to migrate from ECS to EKS without rebuilding our deployment pipeline?

There is no single winner; there is a best fit by team shape. Use Argo CD or Flux if you have a full-time platform engineer, a consultancy like MeteorOps if you want a bespoke platform you own after handover, and an internal developer platform like Qovery if you want a standard EKS cluster in your own AWS account without writing or maintaining the Kubernetes layer. All three keep a CI pipeline whose only job is to build an image and push it to ECR.

Do I have to rewrite my CI/CD pipeline to move from Amazon ECS to Amazon EKS?

No. Build, test, image build, and docker push to ECR are identical on both. The only change is the deploy step, typically 5 to 30 lines, where aws ecs update-service becomes helm upgrade --install, a GitOps commit, or an IDP deploy command. You only face a rewrite if you also choose to hand-author Kubernetes YAML for every service at the same time.

Can Argo CD or Flux convert my ECS task definitions into Kubernetes manifests?

No. Argo CD and Flux are CNCF graduated GitOps engines that reconcile manifests you already wrote; they do not generate a Deployment, Service, Ingress, HPA, or IRSA role from an ECS task definition. You author those manifests yourself (often with Helm), or you use a platform that generates them, then point Argo CD or Flux at the result to handle continuous delivery.

How do I convert an ECS task definition into a Kubernetes Deployment?

Map the fields directly: the container image and command carry over unchanged, CPU units and memory become requests and limits (1024 CPU units equal 1 vCPU, which is 1000m), the ECS service becomes a Deployment plus Service, the task IAM role becomes IRSA or EKS Pod Identity, and Secrets Manager references become External Secrets Operator or the Secrets Store CSI driver. Do not copy CPU and memory 1:1, because Kubernetes will OOMKill or CPU-throttle on limits rather than reserve like ECS does.

How long does an ECS to EKS migration usually take?

It depends on service count and how many cross-cutting concerns you port, but the low-risk pattern is service-by-service over weeks, not a big-bang cutover. A single stateless pilot service can run on EKS in days. With an internal developer platform that provisions the cluster for you, first production workload is typically days; a DIY Argo CD or Flux build is usually weeks before you add upgrade and add-on ownership.

Is EKS more expensive than ECS?

Only by the control plane fee. EKS charges $0.10 per cluster per hour (about $73 a month) and ECS charges nothing for orchestration, while Fargate and EC2 compute is priced identically on both (EKS pricing, ECS pricing). The real cost is engineer-time on upgrades and idle non-production capacity, where Cast AI measured average CPU utilization at just 8% (2026 report).

Should we hire a Kubernetes consultancy like MeteorOps or use an internal developer platform for the migration?

Hire a consultancy like MeteorOps when you want a bespoke platform designed around unusual requirements and you have a team ready to own it after handover. Choose an internal developer platform like Qovery when you want ECS-like simplicity on standard EKS and nobody free to babysit a Kubernetes upgrade every few months. They also combine: a consultancy can design the VPC and landing zone while the IDP runs the day-to-day developer workflow.

Migrating off ECS should cost you a deploy step, not a quarter. Keep the pipeline that builds and pushes an image, pick who owns the cluster after it, and move one service at a time. If you want a real EKS cluster in your own AWS account without writing or maintaining the Kubernetes layer, try Qovery free and ship your first service in under 10 minutes.