AWS Copilot CLI End-of-Support: How to Migrate Before June 12, 2026

AWS put a date on Copilot’s decline on March 6, 2026: support ends June 12, 2026. That gives teams barely a quarter to stop treating Copilot as a safe default. Existing services keep running after that date, but the workflow you use to ship them loses AWS-backed feature work and security updates. For a small team, that can sit quietly for months and then hurt at the worst possible moment, usually during an upgrade or audit.

AWS also made the replacement story unusually explicit. The company is steering users toward Amazon ECS Express Mode and AWS CDK. Those two options cover very different instincts. Express Mode is for teams that liked Copilot because it hid the plumbing. CDK is for teams that are tired of hidden plumbing and want the stack in code where they can inspect it, review it, and reuse it.

That is the only question worth spending time on now: do you want another fast opinionated abstraction, or do you want to own the deployment model directly?

What AWS Actually Announced

The March 6, 2026 AWS Containers Blog post is blunt. Copilot support ends on June 12, 2026. The code stays on GitHub as an open-source project. AWS wants existing users to move to ECS Express Mode or AWS CDK. That last part is the real signal because it tells you where future examples, platform work, and product energy are likely to show up.

Copilot was built to simplify six common service patterns:

Those patterns were useful because they compressed a lot of AWS decisions into one CLI command. That was also Copilot’s ceiling. Once you wanted exact networking behavior, custom IAM boundaries, reusable infra patterns, or integration with a broader platform stack, Copilot stopped being a convenience and started being a constraint.

What Breaks on June 12, 2026 and What Does Not

This is where a lot of teams overreact.

Your already deployed services do not suddenly disappear on June 12. ECS services created by Copilot still run. App Runner services still run. CloudFormation stacks generated by Copilot do not self-destruct. If you do nothing, your workloads keep serving traffic.

What changes is the support boundary, not the runtime itself. AWS stops adding features to the Copilot CLI. AWS stops shipping security fixes for the tool. From that point on, every deployment is a conscious choice to stay on unsupported release machinery. The workload may look healthy in CloudWatch, but the delivery path is aging underneath it. That is the kind of problem that hides until a new engineer joins, a security review lands, or a dependency bump forces you to touch the stack.

Your Real Options

Most teams really have four choices. They can keep shipping from Copilot and accept the risk. They can adopt the generated CloudFormation and try to maintain it directly. They can move to ECS Express Mode. Or they can move to CDK.

The first option buys time and little else. The second option looks practical on paper and usually turns sour in maintenance. Generated CloudFormation is useful as a reference; it is a poor place to build a long-lived platform. I would read those templates, steal the intent, and move on. That leaves ECS Express Mode and CDK as the only choices I would recommend without caveat.

Copilot vs ECS Express Mode vs CDK

If you ignore the marketing language and look at the operational model, the decision becomes simpler.

My rule of thumb is straightforward.

If your team liked Copilot because it removed decisions, move to ECS Express Mode first. If your team was constantly working around Copilot because it hid too many decisions, move to CDK.

Which Copilot Pattern Should Move Where

Not every Copilot workload should land in the same destination.

There is one nuance worth calling out.

Copilot’s Request-Driven Web Service pattern used App Runner, and App Runner is still a perfectly reasonable service for small HTTP workloads. If your current team is happy with AWS App Runner, you do not need to force everything onto Express Mode just because Copilot is reaching end of support. But AWS is investing its migration guidance in ECS Express Mode and CDK, not in expanding Copilot itself, so that is where I would bias new effort.

When ECS Express Mode Is the Right Answer

ECS Express Mode is AWS’s nearest replacement for the part of Copilot people actually liked: ship the container and skip the ceremony. If the service is a straightforward HTTP app, maybe one public endpoint, ordinary autoscaling, standard logging, and no unusual compliance twist, Express Mode is usually enough.

That changes fast when the service stops being ordinary. The moment you need custom networking, stricter IAM review, shared infrastructure patterns, or one deployment model that several teams can extend safely, the abstraction starts to pinch. You can feel the ceiling earlier than you think.

That is why Amazon ECS Service Connect matters in the wider migration picture. Copilot made service-to-service behavior feel simple by hiding it. After the move, you have to choose which of those defaults should stay automatic and which ones deserve to become explicit platform decisions.

When CDK Is the Right Answer

CDK is the better fit when the first question from your team is not “how do we keep this simple?” but “where do we put the custom parts?” That usually shows up as odd IAM boundaries, internal networking rules, shared constructs, or the need to plug one service into stacks you already own. Once those questions appear, Copilot starts feeling cramped.

AWS clearly expects people to take this route. The migration guidance includes both low-level and higher-level CDK patterns, which tells me the escape hatch is no longer a side road. It is the supported road for teams that want typed infrastructure, reusable building blocks, tests around the deployment layer, and fewer surprises when the platform grows.

But you should be honest about the cost. CDK is work. Reviews get deeper. The diff surface gets bigger. Somebody has to care about constructs and synthesis output. I still prefer that trade, because the alternative is usually slower and messier: patched templates, one-off scripts, and a pile of Copilot exceptions nobody wants to inherit.

If you need the syntax refresher, the AWS CDK introduction covers it. The strategic reason to migrate is simpler than the code. CDK lets you keep the opinionated defaults that saved time and replace the ones that kept boxing you in.

A Migration Sequence That Does Not Create Unnecessary Risk

The cleanest migration is boring on purpose. Inventory every Copilot app first. Sort each workload into Express Mode, CDK, or temporary bridge. Then pick one low-risk HTTP service and rebuild only the delivery path. Leave the runtime shape as close as possible to what Copilot already created. When logs, scaling behavior, IAM assumptions, and health checks line up, then cut traffic.

The mistake I would avoid is bundling platform ambition into the same project. A Copilot exit is not the moment to redesign your VPC, replace observability, rewrite CI, and change runtime patterns unless you want a migration report that teaches you nothing because too many variables moved at once.

Your pipeline can stay boring too. If you already deploy from GitHub Actions, use the existing GitHub Actions deploy to AWS pattern. If you are AWS-native in CI/CD, CodePipeline and CodeBuild are enough. The critical thing is that the deployment path becomes owned and documented instead of living inside a tool AWS is deprecating.

The Small-Team Recommendation

If you are a small team with one or two services, move the plain HTTP workloads to ECS Express Mode, keep App Runner in the conversation for the tiniest web services, and save CDK for the point where repeatable infrastructure patterns actually matter. That gets you off Copilot without inventing a platform program you do not need.

The Platform-Team Recommendation

If you run a platform or infrastructure team, treat ECS Express Mode as a tactical on-ramp, not automatically the final layer. Standardize on CDK where service patterns diverge and use the migration to decide which defaults your team wants to own explicitly. It is more work in the short term, but it avoids replacing one opaque abstraction with another slightly newer opaque abstraction.

What I Would Do

If I had a single Copilot service that just needed to keep shipping, I would move it to ECS Express Mode first and not apologize for taking the simple path.

If I had a portfolio of services or a team that already thinks in infrastructure code, I would skip the halfway house and move to CDK directly.

The key point is that June 12, 2026 is not a panic date. It is a deadline to stop pretending Copilot is still the center of AWS’s container story.

Final Recommendation

The short version is simple. Choose ECS Express Mode when you still want Copilot’s speed but not its dead end. Choose AWS CDK when you need control, reuse, testing, and explicit ownership. Keep unsupported Copilot only as a short bridge and say that out loud in the backlog so it does not turn into a permanent exception.

That is the direction AWS is pointing people toward anyway. The useful work now is not debating whether Copilot is really over. It is deciding which replacement model fits your team before the unsupported workflow becomes one more stale dependency everyone complains about and nobody owns.