AWS Proton End of Support Migration: Export Before October 7

AWS Proton stops working on 7 October 2026, and the migration guide buries the part that actually costs you something. Your ECS and EKS workloads keep running. Your CloudFormation stacks keep running. What disappears is every environment template, service template, schema and spec your platform team wrote over the life of the service, because the same FAQ that promises your infrastructure survives also says the data retention period ends that day. An AWS Proton end of support migration is two jobs, and only one of them has a hard deadline. We have run this pattern on enough sunset services to know which one teams skip.

The deadline is an export deadline

Read the two answers in AWS's Proton deprecation guide next to each other.

On surviving infrastructure: "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."

On data retention: "How long will my data be retained? Until October 7, 2026. After this date, all data will be deleted."

Those two sentences describe different things, and the second one is the one with a countdown. Choosing a replacement platform can happen in November. Pulling your template bundles, schemas and service specs out of a service that is about to delete them cannot. Most of the migration advice we have read this month leads with the replacement decision, which is the wrong order of operations when there are six days left.

New signups were already switched off on 7 October 2025, so nobody is walking into this fresh. Every affected team has had a year of notice. Most of the ones we have talked to spent it waiting for a clearer recommendation from AWS than the one they got.

What survives 7 October and what does not

| Asset | After 7 October 2026 | Where it lives now | |---|---|---| | Deployed CloudFormation stacks and their resources | Intact, still updatable via CloudFormation | Your account | | ECS services, load balancers, databases provisioned by Proton | Running | Your account | | Environment and service templates (bundles) | Deleted | S3 upload or a synced git repo | | Template schemas (schema field) | Deleted | Proton API only | | Service instance specs (input parameter values) | Deleted | Proton API only | | Proton-managed pipelines | Stop working | Proton | | Console, API, CLI access | Gone | Proton | | Environment account connections | Deleted | Proton |

The middle three rows are the loss. A schema is the contract your platform team negotiated with application teams about what they are allowed to configure. A spec is the set of values a given service instance was deployed with. Rebuild those from the deployed CloudFormation stack and you get resolved values with no record of which were defaults, which were overrides, and which parameters existed but nobody used.

Export the API data first, in one pass

Run this today. It takes minutes, and nothing in it writes to Proton.

#!/usr/bin/env bash
# Proton metadata export. Read-only. Requires jq and proton:Get*/proton:List*.
set -euo pipefail
OUT="proton-export-$(date -u +%Y%m%d)"
mkdir -p "$OUT"/{env-templates,svc-templates,environments,services,components}

aws proton get-resources-summary > "$OUT/summary.json"
aws proton list-repositories > "$OUT/repositories.json"

# Environment templates: every major.minor version, with its schema
aws proton list-environment-templates \
  --query 'templates[].name' --output text | tr '\t' '\n' | while read -r t; do
  aws proton list-environment-template-versions --template-name "$t" \
    --query 'templateVersions[].[majorVersion,minorVersion]' --output text \
  | while read -r maj min; do
      aws proton get-environment-template-version \
        --template-name "$t" --major-version "$maj" --minor-version "$min" \
        > "$OUT/env-templates/$t-$maj.$min.json"
    done
  aws proton get-template-sync-config \
    --template-name "$t" --template-type ENVIRONMENT \
    > "$OUT/env-templates/$t-sync.json" 2>/dev/null || true
done

# Service templates: same shape, plus compatible environments
aws proton list-service-templates \
  --query 'templates[].name' --output text | tr '\t' '\n' | while read -r t; do
  aws proton list-service-template-versions --template-name "$t" \
    --query 'templateVersions[].[majorVersion,minorVersion]' --output text \
  | while read -r maj min; do
      aws proton get-service-template-version \
        --template-name "$t" --major-version "$maj" --minor-version "$min" \
        > "$OUT/svc-templates/$t-$maj.$min.json"
    done
done

# Service instances: the spec only comes back from the per-instance get
aws proton list-services --query 'services[].name' --output text \
  | tr '\t' '\n' | while read -r s; do
  aws proton get-service --name "$s" > "$OUT/services/$s.json"
  aws proton list-service-instances --service-name "$s" \
    --query 'serviceInstances[].name' --output text | tr '\t' '\n' \
  | while read -r i; do
      aws proton get-service-instance --service-name "$s" --name "$i" \
        > "$OUT/services/$s--$i.json"
    done
done

Two details in there are worth calling out. list-service-instances returns deployment status and template version but no spec, so you have to call get-service-instance once per instance to capture the input values. And get-resources-summary gives you the counts to check the export against, broken down into environments, services, service instances, pipelines, components, environment templates and service templates.

Commit the output directory to git. It is JSON, it is small, and in six months it will be the only surviving record of how your platform was configured.

The template bundles are not in the API

This is where teams get caught. The export above captures schemas and metadata. It does not capture the bundle, which is the actual infrastructure as code: the CloudFormation or Terraform files, the manifest.yaml that lists them, and the schema file that Proton rendered with Jinja at provisioning time.

Look at the GetServiceTemplateVersion response shape. It returns arn, compatibleEnvironmentTemplates, createdAt, description, lastModifiedAt, majorVersion, minorVersion, recommendedMinorVersion, schema, status, statusMessage, supportedComponentSources and templateName. There is no bundle field, and there is no GetTemplateBundle operation anywhere in the API. Proton was always a write-only store for the files themselves.

So the recovery path depends entirely on how you registered templates, and it splits your fleet into two groups:

If you used a template sync configuration, your bundles are already in GitHub, GitHub Enterprise or Bitbucket, laid out as {template-name}/{major-version}/, with a .template-registration.yaml per major version for service templates. You are fine. The get-template-sync-config calls in the script above tell you the repository, branch and subdirectory for each one.

If you uploaded bundles to S3 from the console or the CLI, go and find that bucket now. Check its lifecycle rules and check whether versioning was ever on. We have seen a platform team discover in week one of a sunset migration that their template bundle bucket had a 90-day expiration policy set by a tagging sweep two years earlier, and the only copy of their production service template was the one Proton held.

Teams that never wired up template sync and cannot find the source bucket have one option left: re-derive the IaC from the deployed CloudFormation stacks with aws cloudformation get-template, then re-introduce the parameters by hand using the exported schema and spec files as the map. That is a week of work per template, not an afternoon.

AWS names four replacements and one of them is dead

The deprecation guide lists four alternatives. Here is what each one offers, and what we think of it.

| Replacement | Fills the Proton role of | The catch | |---|---|---| | CloudFormation Git sync | Template-to-stack GitOps | AWS's own doc lists "No concept of environments" as a limitation, which was half of what Proton did | | Harmonix on AWS | Self-service developer portal | Unmaintained since December 2025 | | CodePipeline and CodeBuild | Pipeline execution | "Requires more implementation work", per AWS. No self-service layer at all | | GitHub Actions | Pipeline execution | Platform team controls have to be built, not configured |

Start with the second row, because AWS still recommends it. The Harmonix README opens with "This project is no longer actively maintained as of December 2025" and a notice telling users to upgrade to v0.4.2 immediately to address critical security vulnerabilities. It is Apache-2.0 licensed Backstage tooling, so you can fork it and carry it yourself. Do not adopt it as a product. Migrating off one unmaintained platform onto another unmaintained platform, at AWS's suggestion, is how a one-quarter project becomes a three-year one.

CloudFormation Git sync is the closest thing to a like-for-like path, and it is the one we recommend by default for CloudFormation shops. Check two constraints before you commit. It supports GitHub, GitHub Enterprise, GitLab, Bitbucket and GitLab self-managed, which is a wider provider list than Proton template sync ever had. But it is available in 17 regions, and the list does not include Europe (Zurich), Europe (Spain), Middle East regions, GovCloud or China. If your platform account sits in one of those, Git sync is a blocker rather than a migration target.

The environments gap is the real design problem. Proton let a platform team define an environment once and stamp service instances into it with inherited outputs. Git sync has no equivalent. You replace it with naming conventions, separate deployment files per environment, and a CI job that enforces the mapping. That is not worse, exactly. It is just code you now own.

What we would pick, by team shape

We would not run a single migration for the whole fleet. Split by what the templates were doing.

Teams with fewer than about ten service templates, all CloudFormation, all in a Git sync region: go to CloudFormation Git sync directly. Two to three weeks including the parallel run. You keep the templates, you keep the review workflow, and you drop the self-service console.

Teams whose Proton value was the pipeline, not the portal: go to GitHub Actions or CodePipeline and stop pretending you need a platform product. Most Proton deployments we have reviewed were used this way, with the console barely touched after onboarding.

Teams whose Proton value genuinely was self-service for dozens of application teams: you are in a portal decision, not a Proton decision. We wrote the framework for that in internal developer portal build vs buy, including the three-year cost comparison and why Backstage stalls at low adoption. Read that before you fork Harmonix.

Teams on Terraform templates in Proton: Git sync is CloudFormation only, so your path is your existing Terraform workflow plus a pipeline, and the decision is really about pipeline architecture. Our CI/CD pipeline architecture decision framework covers the managed versus self-hosted call.

One number to keep in mind while you evaluate. Proton had no service charge: "There is no additional charge for AWS Proton. You only pay for the AWS resources that you create to store and run your application." Every replacement on this list costs something, whether that is a per-seat SaaS bill or the engineering time to build environment handling yourself. Budget for a line item that used to be zero.

The next six days, in order

Today is 1 October 2026. The shutdown is 7 October. That is six days with a weekend in the middle, which is enough for the part that matters and not enough for the part that does not.

| Day | Action | |---|---| | Thursday 1 October | Run the export script in every account with Proton resources. Commit the output to git | | Friday 2 October | Resolve bundle sources: check get-template-sync-config output, locate the S3 upload bucket, confirm lifecycle rules and versioning. Clone every synced template repo to a location you control and copy S3 bundles down with aws s3 sync | | Monday 5 October | Re-derive any missing bundle with aws cloudformation get-template against the deployed stacks. Inventory the pipelines Proton was running and note what has to exist on the other side | | Tuesday 6 October | Verify the export against get-resources-summary counts. Confirm no environment account connection is load-bearing for cross-account deploys | | Wednesday 7 October | Proton stops. Your stacks do not | | After | Pick a replacement without a countdown running |

Notice that no replacement platform gets chosen in that window. That is the point. Choosing under a deadline this short is how teams end up on an unmaintained fork.

One thing not on the list: do not delete Proton resources to tidy up before the shutdown. delete-service removes the service together with every instance and its pipeline, and a deleted instance is a deprovisioned stack. The same goes for delete-environment. Let the service expire around your stacks instead.

When to get help

Two situations are worth an outside pair of hands. The first is a fleet where template sync was never configured and the S3 bundles are gone, which turns a metadata export into a reverse-engineering project across live stacks. The second is a multi-account setup using environment account connections, where the cross-account provisioning role structure has to be rebuilt in whatever replaces Proton before anyone can deploy again.

We have run sunset migrations on Ingress-NGINX, containerd 1.7 and a handful of retired managed services, and the failure mode is always the same: the export slips while the team debates the replacement. If you want a second set of eyes on the export, or a call on which replacement fits your team, get in touch. The useful conversation is this week.