Find out what is actually reaching end of support
A website may rely on several layers of server software: an operating system, a web server, a programming language, a database, and a content management system. An end-of-support notice may apply to just one layer, but changing that layer can affect the others. Start by recording the installed versions, who manages each one, and where the site runs. Your hosting control panel, provider, or developer may be able to help you fill gaps in that inventory.
Clarify what “end of support” means for the specific product and provider. Routine fixes, security updates, and hosting compatibility may have different schedules. You do not need to predict every future problem; you do need to know when the current setup will stop receiving the support you rely on. Put that point on a project calendar and allow time for testing and corrections before it arrives.
Map the parts of the site that could be affected
List the features that matter most to visitors and staff: forms, search, logins, payments, email delivery, scheduled publishing, file uploads, and backups. Then note the themes, plugins, custom code, and outside services behind them. A new language or database version may work with the main content management system but not with an older extension. Conversely, delaying an extension update may prevent you from moving the underlying software forward.
Prioritize this list by impact. A broken contact form may need attention before a minor layout difference on a rarely visited page. If your site uses custom code and no one is sure who maintains it, treat that uncertainty as a task rather than assuming it will work. Ask the maintainer or hosting provider which combinations they support, and record any replacements or code changes needed before the upgrade.
Choose a route and make it a small project
There may be more than one sensible path. Your host might offer an in-place version change, a move to a newer hosting environment, or a managed plan that handles some server updates. Compare these routes against your site's requirements, the access your team has, and the time available to test. Avoid choosing solely because a button promises a quick upgrade; the important question is whether the resulting site works and can be maintained.
Write a short project plan with an owner, a target launch window, and clear checks for completion. Include time to update dependent software, fix incompatibilities, review access permissions, and tell staff about possible disruption. If the site is too complex to assess confidently, getting help early is more useful than waiting until the support deadline is close.
Test a copy before changing the live site
Where possible, create a staging copy that uses the proposed server versions without exposing the copy to visitors or search engines. Protect any copied personal data and avoid sending real emails or processing real transactions during tests. Update the software in the intended order, then check the important visitor and staff journeys from your priority list. Look beyond the home page: submit a test form, edit and publish content, check mobile layouts, and review error logs if you have access.
Before launch, make a verified backup of both site files and the database. Knowing that a backup exists is not the same as knowing it can be restored, so confirm how restoration would work and who can perform it. Write down what would trigger a rollback, such as failed logins or a broken critical form. Some database or content changes can complicate a rollback; plan how to handle content added during the launch window.
Launch deliberately and keep the record
Schedule the live change for a period when someone can test it promptly and respond to problems. Tell people who publish on the site when to pause edits, if a pause is needed. After the upgrade, repeat your essential checks on the live site rather than assuming staging results carry over exactly. Confirm that backups, scheduled tasks, notifications, and routine updates still run as expected.
Keep a brief record of what changed, which versions are now in use, any unresolved issues, and who to contact next time. Add the new software to a regular maintenance review so the next support deadline is not a surprise. A successful upgrade is not simply one that finishes without an error message; it leaves the site usable, supportable, and easier to maintain.
