Days 90–61: understand the estate.
Find every affected installation and assign an accountable owner. Check support agreements and capture the applications, integrations and business processes that depend on the release. Agree on a supported target and a realistic change scope.
Days 60–31: prove the migration.
Test the intended upgrade using representative workloads. Verify backups and recovery procedures. Measure application behaviour, review the vendor’s migration guidance and resolve compatibility problems before the production window.
Days 30–1: execute and verify.
Schedule staged changes, communicate expected downtime and define rollback criteria. After migration, verify the running version, service health and monitoring. Update your inventory so the next deadline belongs to the right release.
If the schedule slips.
Document the remaining exposure and the accountable decision-maker. Investigate vendor-supported extensions or alternative migration routes. Compensating measures can reduce risk, but they do not turn an unsupported release into a supported one.
Source references
Editorial guidance from EOL Alerts. Check current vendor documentation for your exact product, edition and support agreement.
Explore lifecycle alerts →