Replace End-of-Life Runtimes

A runtime can fall out of support while the application still passes tests. That creates a maintenance risk: future fixes may not be available for the deployed version. Start by confirming the vendor's support status for the exact runtime and distribution you use. Do not infer support from a major version alone; providers and distributions can have different maintenance terms.

Runtime replacement register

Find the runtime in owned deployment manifests, containers, serverless settings, and build agents. A local development version is not proof of the production version. List each service separately because one repository may deploy several runtimes. Check package compatibility before changing the base image, especially native extensions, cryptography providers, and deprecated APIs.

Move with evidence

Build a candidate artifact with a supported target runtime. Run unit, integration, and deployment tests. Compare startup behavior, request handling, job execution, and resource use in a test environment. Pay attention to certificate stores, TLS defaults, and serialization changes. A passing build does not establish that a worker job or scheduled task still runs correctly.

Record the new artifact digest, rollout group, health signals, and a rollback trigger. A rollback may be unsafe after a database migration or format change, so test that path before production. If the upgrade must wait, assign a named owner, expiry date, exposure reduction, and weekly review. Do not describe an unsupported runtime as patched solely because an application-level package was updated. Close the task only after the deployed runtime, not just the manifest, has been verified. Check the runtime version from a running instance in each deployment group.