AWS Proton Is End-of-Support: 5 Migration Paths for Platform Teams (and How to Pick One)

AWS Proton was AWS's answer to platform engineering, and it never owned your infrastructure. That is exactly why this migration is survivable. The hard part of a platform migration is usually the running workloads, and here they do not move.

I have talked to enough platform teams since the deprecation landed to know the first reaction is panic and the second is relief, once they realize what actually ended. Let me walk through what ended, the five places you can go, and a plan that changes nothing in production during week one.

Key points

• AWS Proton reached end of support on October 7, 2026. Everything AWS Proton already provisioned keeps running, because it lives as CloudFormation stacks inside your own AWS account. What stops is the AWS Proton control plane: no console, no API, no new template versions, and AWS says all AWS Proton service data will be deleted after that date.
• AWS Proton never owned your infrastructure. Your CloudFormation templates, Terraform modules, IAM roles and CI pipelines survive the migration intact. You lose four things: the template catalog, template version promotion, the environment and service abstraction, and the IAM-scoped developer self-service layer on top.
• There are five realistic destinations: (1) raw IaC plus CI with Terraform/OpenTofu or AWS CDK and GitHub Actions; (2) AWS-native stitching with CodePipeline, CDK Pipelines and AWS Service Catalog; (3) a self-built IDP on Backstage or Port with Crossplane or Terraform underneath; (4) a managed internal developer platform such as Qovery, Humanitec or Northflank; (5) Kubernetes-native GitOps with Argo CD or Flux.
• The deciding variable is platform headcount, not technology preference. With 0-1 full-time platform engineers, a managed IDP is the only option that restores self-service without a second product to staff; at 2-4, managed IDP or GitOps; at 5 or more with strong opinions, Backstage plus Crossplane becomes defensible.
• Qovery is the closest replacement for the AWS Proton developer-facing layer while keeping workloads in your account. Qovery is an internal developer platform that deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, so the cloud bill, Savings Plans, VPCs and compliance boundaries stay yours.
• Migrate in three stages over roughly 10 weeks for a 30-service estate: freeze new AWS Proton template versions and inventory everything (weeks 1-2), re-own the underlying IaC in Git (weeks 2-6), then replace the developer self-service layer last (weeks 4-10). Teams that start with the portal rebuild it twice.

What exactly ended when AWS Proton reached end of support on October 7, 2026?

AWS Proton's end of support ended the AWS Proton control plane only. After October 7, 2026, you can no longer access the AWS Proton console or API, no new template versions ship, and AWS support for the service is gone. Every resource AWS Proton provisioned keeps running untouched, because it exists as CloudFormation stacks inside your own AWS account, not inside AWS Proton.

AWS states this plainly in the deprecation guide: "Your deployed CloudFormation stacks and the resources they manage will remain intact and continue to function. The deprecation affects only the delivery pipelines, not your deployed infrastructure." (AWS Proton Service Deprecation and Migration Guide) One caveat worth flagging to your team: AWS also says all AWS Proton service data is deleted after the date, so export your template bundles before then.

AWS Proton covered three layers. Environment templates described shared infrastructure. Service templates described a service_instance plus an optional pipeline section. On top sat an IAM-scoped self-service interface that developers actually used to spin up environments without filing a ticket.

What survives: provisioned VPCs, ECS and Fargate services, RDS instances, your CI jobs, your IAM roles and trust policies, and any Terraform state in your own S3 backend.

What disappears: the template registry, template version promotion, the environment and service abstraction, and the AWS Proton console and API your developers self-served through.

Your first action, in order: list every AWS Proton environment, every service template and version, every service instance, every component, and record which provisioning mode each uses. AWS Proton supported two: AWS-managed CloudFormation and self-managed Terraform. If your estate runs self-managed Terraform provisioning, you already own the apply loop, so your migration is materially smaller - usually only the portal layer has to be replaced.

A deprecated template catalog is a far smaller problem than a deprecated runtime. Nothing here forces a re-architecture.

What are the migration options for AWS Proton, and which one fits which team?

Five destinations cover almost every AWS Proton estate: raw IaC plus CI, AWS-native services stitched together, a self-built IDP on Backstage or Port, a managed IDP such as Qovery, Humanitec or Northflank, or Kubernetes-native GitOps with Argo CD or Flux. Pick on the number of full-time platform engineers you can actually staff, not on which tool is most interesting to build.

• Option 1 - Terraform/OpenTofu or AWS CDK plus GitHub Actions or GitLab CI. Maximum control, zero abstraction. Developers go back to filing tickets for environments. Fine for a small team of infra-literate engineers, painful at scale.
• Option 2 - AWS-native stitching. CDK Pipelines, CodePipeline, AWS Service Catalog and CloudFormation StackSets are the closest structural replacement inside AWS, and the path AWS itself recommends for maximum flexibility. There is no first-class service and environment model and no template version promotion, so you rebuild that glue yourself.
• Option 3 - Build your own IDP. Backstage or Port as the portal with Terraform or Crossplane underneath. This is a product your team now owns forever, including its upgrades and its on-call. Right answer with real platform headcount, a trap without it.
• Option 4 - Managed IDP in your own cloud account. Qovery, Humanitec, Northflank. You keep the AWS, GCP, Azure or Scaleway account and drop the glue code. This restores self-service fastest.
• Option 5 - Kubernetes-native GitOps. Argo CD or Flux with Helm or Kustomize. The right answer if you are already on EKS and happy for the cluster itself to be the platform. Both are CNCF graduated projects, so this is a safe long-term bet.

The headcount rule is not arbitrary. Gartner projects 80% of large software engineering organizations will have platform teams by 2026, up from 45% in 2022, but having a platform team and being able to staff a bespoke IDP are different budgets. My rule of thumb: 0-1 platform engineers go managed IDP; 2-4 go managed IDP or GitOps; 5 or more with strong opinions can justify Backstage plus Crossplane.

How do I map AWS Proton environment templates, service templates and service instances to a new platform?

Map AWS Proton's primitives one layer at a time: an environment template becomes shared infrastructure owned by Terraform/OpenTofu modules, a service template becomes an application blueprint, and a service instance becomes a deployed environment. Do not try to port template version promotion. Almost nothing outside AWS Proton models it the same way, and recreating it is where these migrations stall.

To recover the source IaC, pull every AWS Proton template bundle from S3, flatten the Jinja parameterization, and commit the result as plain modules in Git. Jinja parameter injection becomes Terraform variables and tfvars files, Helm values files, or platform-level environment variables and secret references. AWS Proton-managed pipelines (the service template pipeline section) usually collapse into plain GitHub Actions or GitLab CI workflows - keep the build and test stages, drop the AWS Proton-specific provisioning steps.

Decide what not to migrate. Templates with a single consumer, abandoned template versions, and environments that were really personal sandboxes should die in the inventory. That step alone typically removes a meaningful slice of the estate before any real work starts.

Import, do not recreate. Use terraform import or CloudFormation stack import so existing stacks keep running while ownership moves into your repo. Your verification gate before moving on: a clean terraform plan with no diffs and zero CloudFormation drift on every imported stack.

How do I migrate off AWS Proton without freezing feature work or touching running infrastructure?

Run the migration in three stages and change nothing in production during stage one. AWS Proton and the new platform run in parallel the whole time, so rollback stays a routing decision rather than a restore. These week ranges are estimates reasoned from the three-stage plan for a 30-service estate, not measured benchmarks - your mileage depends on how much self-managed Terraform you already run.

Stage 1 - Freeze and inventory (weeks 1-2). No new AWS Proton service template versions. Inventory environments, templates, instances, consumers and provisioning mode. Tag every resource with its owning team. Nothing in production changes.

Stage 2 - Re-own the IaC (weeks 2-6). Export bundles, strip AWS Proton-specific parameterization, import existing stacks, and confirm a clean terraform plan and zero CloudFormation drift before anyone celebrates.

Stage 3 - Re-platform the self-service layer (weeks 4-10). Take one non-critical service end to end on the new platform, then migrate team by team rather than service by service. AWS Proton keeps serving existing service instances; only new services land on the new platform until a team has fully cut over.

Your cutover checklist per service: Secrets Manager and Parameter Store references, IAM roles and trust policies, VPC and subnet references, database connection strings, DNS and certificates, and observability and alerting hooks. Your rollback plan is free, because the original CloudFormation stacks and state are untouched - rolling back means pointing traffic and CI back at the old path.

The common failure mode is starting with the developer portal before the IaC is re-owned. Build the portal first and you will rebuild it once the templates change shape underneath it. Tie each stage gate to deployment frequency and change lead time, the two throughput signals DORA uses to separate performance cohorts, so you can prove the new path is not slower than AWS Proton was.

Why do platform teams pick a managed internal developer platform over rebuilding the abstraction in-house?

AWS Proton existed so developers could self-serve environments without learning Terraform, and rebuilding that abstraction in-house means owning a portal, a template library, drift detection and provider upgrades forever. A managed internal developer platform that deploys into your own cloud account gives you the same abstraction without the glue code, and keeps the AWS account, Savings Plans and compliance boundaries you already have.

The portal is the easy part of DIY. The recurring cost is template maintenance, Kubernetes and provider upgrades, drift reconciliation, and on-call for the platform itself. That is why bring-your-own-cloud matters specifically to AWS Proton refugees: your existing AWS accounts, Savings Plans and Reserved Instances, VPC peering, private subnets, audit boundaries and data residency cannot be thrown away for a vendor-hosted PaaS.

Qovery is an internal developer platform that deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster. The verified capabilities relevant here: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services such as RDS. Qovery's environment and application model maps cleanly onto AWS Proton's environment and service instance model, which is why the mapping exercise is short for teams coming from AWS Proton. You get Kubernetes without managing it directly, and you can ship without a dedicated DevOps engineer, while the workloads stay in your account.

To be fair about the alternatives: Humanitec is a legitimate platform orchestrator and a strong fit behind an existing Backstage portal. Backstage plus Crossplane is the right answer with five or more platform engineers and strong opinions, and Backstage is a CNCF incubating project with over 100 public adopters including American Airlines and Netflix. Argo CD or Flux is right when the cluster already is the platform. Northflank is a credible managed option with its own BYOC story.

A managed IDP is the wrong answer for heavy non-containerized workloads, strict air-gapped environments, or a platform team whose platform is itself the company's product. And leaving AWS Proton does not mean leaving AWS. Most readers stay on AWS, and that is the right call. A few use the moment to stop being single-cloud locked.

What does an AWS Proton migration actually cost in engineering time and cloud spend?

Your cloud bill barely moves, because AWS Proton carried no additional charge beyond the resources it provisioned. You were already paying for the ECS services, RDS instances and VPCs. The migration is a labor event, and engineering time is where the five options diverge by close to an order of magnitude.

Budget for the hidden costs: duplicated environments during the parallel run, re-testing every pipeline, retraining developers on a new self-service flow, and on-call for two systems at once. Teams genuinely save in three places: environment auto-stop on non-production, right-sizing during the re-platform, and deleting the zombie sandbox environments the inventory always uncovers. That matters because Flexera's 2025 State of the Cloud Report estimates 27% of cloud spend is wasted, much of it idle and oversized non-production resources.

The concrete financial argument for BYOC over a vendor-hosted PaaS is protecting Savings Plans and Reserved Instances. Those commitments apply to usage in your own account, so a managed IDP that deploys into that same account keeps them intact. A vendor-hosted PaaS strands them.

How do I run this AWS Proton migration from Claude Code or Cursor with Qovery?

Install the Qovery Agent Skills once and your coding agent can handle the repetitive part of the migration: read the Terraform you exported from AWS Proton bundles, propose the environment and application mapping, and deploy a first service into your own cloud account. Every action is shown for approval before it runs, and the Qovery MCP Server is read-only by default.

Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Project-scoped install instead of global:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server for Claude Code (OAuth, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Which skill does what in this migration: qovery-onboard connects your AWS, GCP, Azure or Scaleway account or an existing Kubernetes cluster; qovery-terraform works from the IaC you exported from AWS Proton bundles; qovery-deploy takes a first service end to end; qovery-preview builds per-PR environments to replace AWS Proton sandbox service instances; and qovery-troubleshoot and qovery-optimize handle the post-cutover work. After install, ask in plain language, for example: "map this Terraform module to a Qovery environment and deploy the staging service to my AWS account."

Skills create and deploy; the MCP Server operates what already exists. See the AI agent quickstart and the Claude Code integration.

When exactly did AWS Proton reach end of support, and will my existing environments stop working?

AWS Proton reached end of support on October 7, 2026. Your existing environments do not stop working: AWS confirms that deployed CloudFormation stacks and the resources they manage remain intact and continue to function, because the deprecation affects only the AWS Proton control plane and delivery pipelines. What you lose is access to the AWS Proton console and API, and AWS deletes AWS Proton service data after that date, so export your template bundles first.

What is the closest AWS-native replacement for AWS Proton?

The closest AWS-native replacement for AWS Proton is a combination of AWS CodePipeline, AWS CodeBuild or CDK Pipelines, and AWS Service Catalog, which AWS itself recommends for teams needing maximum flexibility. For a lighter GitOps flow, AWS points to CloudFormation Git Sync. Neither gives you AWS Proton's first-class environment and service model or template version promotion out of the box, so you rebuild that abstraction yourself.

Can I migrate off AWS Proton without rewriting my Terraform or CloudFormation templates?

Yes. You can migrate off AWS Proton without rewriting your Terraform or CloudFormation templates by exporting the AWS Proton template bundles from S3, flattening the Jinja parameterization, and importing the existing stacks with terraform import or CloudFormation stack import. The underlying infrastructure definitions are reusable; what you replace is the AWS Proton wrapper, the template catalog, and the self-service layer, not the templates themselves.

Should platform teams move from AWS Proton to Backstage, Humanitec, Northflank or Qovery?

It depends on platform headcount. Platform teams with five or more engineers and strong opinions can justify Backstage plus Crossplane; teams that want self-service back fast with 0-1 engineers are better served by a managed IDP such as Qovery, Humanitec or Northflank. Qovery and Northflank run inside your own cloud account, Humanitec orchestrates well behind an existing Backstage portal, and all keep your workloads and Savings Plans in place.

How long does an AWS Proton migration take for a 30-service estate, and what does it cost?

For a 30-service estate, a realistic estimate is roughly 10 weeks of calendar time across three stages, with engineer-effort ranging from about 2-8 weeks for a managed IDP to 16-40 weeks for a self-built Backstage and Crossplane platform. These are estimates reasoned from the three-stage plan, not measured benchmarks. The cloud bill barely moves, because AWS Proton carried no additional charge; the cost is engineering time, and that is where the options diverge most.

Does moving off AWS Proton mean leaving AWS, and can the replacement run in my own cloud account?

No. Moving off AWS Proton does not mean leaving AWS, and most teams should stay. The replacement can run entirely in your own cloud account: AWS-native tooling and GitOps obviously do, and managed IDPs such as Qovery, Northflank and Humanitec deploy into your own AWS, GCP, Azure or Scaleway account or existing Kubernetes cluster, so your VPCs, Savings Plans and compliance boundaries stay yours.

How do I replace AWS Proton's developer self-service layer without hiring a platform team?

Replace the AWS Proton self-service layer with a managed internal developer platform that runs in your own cloud account, such as Qovery. It restores git-push deployments, preview environments per pull request, environment auto-stop and per-environment RBAC without you building or maintaining a portal, so a small team gets the self-service AWS Proton offered without staffing a dedicated platform team.

A deprecated template catalog is a much smaller problem than a deprecated runtime. Export your bundles, re-own the IaC, and replace the self-service layer last. If you want that self-service back without standing up a platform team to run it, that is the gap Qovery fills.