How to Plan an End-of-Life Migration
A practical checklist for moving off software before its support ends: what to inventory, how to read the dates, which path to choose, and how to test and roll back.
1. Inventory what you actually run
List every product and version in production, including the quiet ones: database engines, runtimes, hypervisors, load balancers, container runtimes and build agents. Record the version number from the system itself (a command, an admin page or a package list), not from documentation or memory.
Add where each one runs and who owns it. An end-of-life date is only useful if someone is responsible for acting on it.
2. Find the real end date
Use the vendor's own lifecycle or support policy page as the source, and write down the exact wording. Vendors use different terms for different things: general support, security-only support, extended support and end of life are not the same date. The EOL lookup shows each product's dates and links to the vendor page it came from.
Note which date applies to you. Paid extended support, where a vendor sells it, is a separate contract and does not extend the standard support date.
3. Rank by exposure, then by date
Put internet-facing and data-holding systems first, then everything else by how soon support ends. The 120-day list shows what is ending soonest across the products it tracks.
A system that is already past end of life and reachable from outside is a higher priority than one that ends next year behind a firewall.
4. Pick the path
There are four usual choices. Upgrade in place to a supported version. Replace the product with a different one. Buy extended support if the vendor offers it and you need time. Isolate the system (remove outside access, restrict who can reach it) while you plan the real fix.
Extended support and isolation buy time; they do not remove the problem. Put a date on the permanent fix.
5. Test before you touch production
Build a copy of the system and run the upgrade there first. Check that applications, plugins, drivers, client libraries and scheduled jobs still work on the new version, and read the vendor's release notes for breaking changes.
Take a backup you have actually restored at least once. A backup you have never tested is a guess.
6. Plan the rollback and the window
Decide in advance what failure looks like and how you go back: restore a snapshot, switch traffic to the old system, or redeploy the previous version. Write the steps down.
Pick a maintenance window with enough room for the rollback as well as the upgrade, and tell the people who depend on the system.
7. Track it so it does not sneak up again
Keep one list with product, version, owner, end date and planned action. Review it on a regular schedule, and recheck dates when a vendor announces a policy change.
Dates can be revised, so confirm against the vendor page before you commit to a date in a project plan.
Dates and policies are set by each vendor and can change. Always confirm on the vendor's own page before you commit to a plan. Open the EOL lookup.