App Engine Legacy Runtimes — when and how should I migrate?
Organizations that depended on re-enabling legacy App Engine runtimes need to decide how to unwind that exception path now that Google no longer allows new deployments after the January 31, 2026 cutoff.
Blockers
- breaking_change_in: runtime/java-8 → vendor/google
- breaking_change_in: runtime/python-2.7 → vendor/google
- breaking_change_in: runtime/go-1.11 → vendor/google
- breaking_change_in: runtime/php-5.5 → vendor/google
- runtime/python-2.7 — EOL 2027-01-31
- runtime/go-1.11 — EOL 2027-01-31
- runtime/php-5.5 — EOL 2027-01-31
Who this is for
- serverless
- low-ops
- enterprise
Candidates
Migrate to App Engine standard second-generation runtimes
As of 2026-04-02, this is the main in-place path if you want to stay on App Engine standard. Google states that first-generation legacy runtimes such as Python 2.7, Java 8, Go 1.11, and PHP 5.5 were deprecated on January 31, 2026, and can no longer be deployed even if an organization previously used the runtime-deployment exemption policy. The current App Engine standard support schedule lists supported second-generation options including Java 17, 21, and 25; Python 3.10 through 3.14; PHP 8.2 through 8.5; and Go 1.22 through 1.26. App Engine pricing also states that when legacy bundled services are used in supported second-generation migration paths, the same pricing and quotas apply as in first-generation runtimes; check official pricing docs for exact current rates by resource and region.
When to choose
Use this when you want the lowest-disruption path and still want App Engine standard operations, routing, and deployment model. It is the best fit when your app can move to supported runtimes and either replace bundled services with Cloud Client Libraries or stay within the subset of bundled services that Google supports in second-generation migration paths.
Tradeoffs
Keeps the App Engine standard model and can preserve part of your existing architecture, but migration can still be non-trivial because runtime behavior and some bundled-service assumptions change.
Cautions
Do not assume all legacy bundled services carry forward unchanged. Google explicitly says only a subset is available in second-generation migration projects, and recommends unbundled Google Cloud services or other replacements for proprietary bundled services.
Freeze existing first-generation services and run them only as a temporary bridge
As of 2026-04-02, this is no longer a redeployable steady state; it is only a short-term containment option. Google says existing applications on deprecated first-generation runtimes continue to run and receive traffic after the January 31, 2026 deprecation date, but new deployments are blocked even for organizations that previously used the exemption policy. The App Engine support schedule shows decommission dates of January 31, 2027 for Java 8, Python 2.7, Go 1.11, and PHP 5.5. Pricing pages still describe legacy App Engine resources, but exact current billing details should be checked in the official pricing docs.
When to choose
Use this only when the deployed service is stable enough to avoid redeploys while you execute a controlled migration or replacement. It is the least immediate engineering work, but only works if you can accept a shrinking safety margin and a hard stop before decommission.
Tradeoffs
Buys time and avoids rushed changes now, but removes your ability to ship fixes on the legacy runtime and leaves you operating on software that is already out of support.
Cautions
Treat this as an emergency runway, not a platform strategy. After January 31, 2026, the organization-policy workaround is gone for these runtimes, and the support schedule already sets January 31, 2027 as the decommission date for the main first-generation legacy runtimes.
Use the forced migration window to move off legacy App Engine patterns, potentially to Cloud Run
As of 2026-04-02, Google explicitly recommends that teams also consider migrating to Cloud Run, which it describes as the latest evolution of Google Cloud Serverless and as improving on features from both App Engine standard and App Engine flexible. This is the higher-change path, but it is the cleanest way to stop depending on first-generation runtime behavior and proprietary bundled services. Google’s migration guidance says teams using legacy bundled services should either replace them with Cloud Client Libraries and equivalent Google Cloud services or use the limited second-generation bundled-service support where available. Check official Cloud Run pricing docs directly for current compute and networking rates.
When to choose
Use this when your blocker is not just the runtime version but the legacy App Engine programming model itself. It is the better choice when you want to reduce dependence on proprietary bundled services and accept a larger migration now to avoid repeated platform-specific rewrites.
Tradeoffs
Can produce a cleaner long-term architecture and reduce legacy coupling, but it is usually a larger migration than staying inside App Engine standard second-generation runtimes.
Cautions
Do not start with a lift-and-shift assumption. The migration center frames bundled-service replacement as a core workstream, so inventory those dependencies first before committing to scope or timeline.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "App Engine Legacy Runtimes — when and how should I migrate?"