PHP 8 migration without downtime for Quebec business sites

To move a site to PHP 8 without downtime, clone it to a staging copy, run it on the target PHP version there, fix every error and deprecation you find, then switch the live site's PHP version in a low-traffic window with the old version ready as a rollback. The risk is not PHP 8 itself. It is upgrading the live site first and learning what broke from your customers.

AERVIO runs these migrations for Quebec and Canadian business sites from Montreal, weekdays 9–17 ET. Below is the sequence we use, with the checks that matter.

Why this cannot wait

Each PHP branch has an active-support period and then a security-only period, after which it gets no fixes at all. A site on an end-of-life version is running code with known, unpatched flaws, and some plugins and hosts will stop supporting it. The current dates are on php.net's supported-versions page; check it before you plan, because the answer changes every year.

This is also a hosting and security matter, not only a developer one. Hardening basics like MFA, backups and alerting assume the runtime underneath is still maintained.

Step 1: Inventory what you actually run

Before changing anything, write down:

• Current PHP version (hosting control panel or a `phpinfo()` page on a protected URL)
• CMS and version: WordPress, Joomla, OpenCart, Drupal or custom
• Theme and child theme, with who built them
• Every plugin or extension, with version and last update date
• Custom code: mu-plugins, functions files, cron scripts, one-off includes
• Required PHP extensions (imagick, intl, mbstring, curl, zip and others)
• Database engine and version
• Who has hosting access and who can restore a backup

If the inventory takes more than an hour, that tells you something about how long the site has been unmanaged.

Step 2: Back up and prove you can restore

A backup you have never restored is a hope. Take a full backup of files and database, store a copy off the host, and restore it to the staging environment as a test. That restore doubles as your staging build.

Step 3: Build staging on the target version

Create a staging copy with the same database content (scrub or restrict personal data in line with your privacy obligations), and set its PHP version to the target.

Block search engines on staging, disable outgoing email and payments, and make sure cron jobs and webhooks do not hit production services from the copy. We have seen a staging site send real order emails. Do not be that case.

Step 4: Find what breaks

Use several signals, not one.

• Static scan. PHPCompatibility rules with PHP_CodeSniffer flag syntax and function use that changed between versions.
• Error log. Enable logging on staging, browse every template type and form, then read the log.
• Deprecation notices. Treat them as a to-do list, not noise. Some become fatal errors in the next version.
• Plugin and theme updates. Update to the latest compatible versions first. Many fixes already exist upstream.
• Manual test paths. Contact forms, checkout, login, search, uploads, scheduled tasks and any integration.

Typical findings:

Do not suppress errors to make the page load. Silenced errors are the ones you find in production.

Step 5: Decide on every abandoned component

For each plugin, theme or script that fails and has no update, choose one:

1. Replace with a maintained alternative
2. Patch it with a documented diff you can reapply
3. Remove the feature
4. Rebuild the small part that matters

Keeping an abandoned component by staying on an old PHP version is the worst of the four, because the risk is invisible until it is not.

Step 6: Schedule the cutover

Pick a window with low traffic and staff available. For many B2B sites that is early weekday morning or a weekend evening. Freeze content changes and orders if the site sells.

Checklist before switching:

• Fresh full backup, restore tested
• Hosting control panel access confirmed
• Previous PHP version still selectable
• Monitoring on (uptime check and error log)
• Someone ready to test forms and checkout right after
• A named person who can say "roll back"

Step 7: Switch and verify

Change the PHP version for the site in the hosting panel. Most hosts apply it per domain in seconds.

Then verify:

• Home page and three deep pages load
• Admin login works
• Forms deliver and, if connected, create CRM records
• Checkout completes a test order
• Scheduled tasks run
• Error log stays clean for a while
• Search Console shows no spike in server errors in the following days

If something unexpected breaks, switch back first, diagnose after. That is what the rollback is for.

Step 8: Leave the site better than you found it

After a successful migration:

• Record the PHP version, extensions and date in a runbook
• Turn on automatic minor updates where safe
• Put the next PHP end-of-support date in a calendar
• Remove unused plugins, themes and old staging copies
• Add uptime monitoring if there was none

This is where a managed arrangement helps. Hands-off IT covers the operations side, and a growth retainer can include periodic runtime and plugin reviews, so the next migration is routine instead of urgent.

When to bring in help

Do it yourself if the site is a standard CMS with a handful of maintained plugins and you have a staging environment. Bring in help if:

• The site relies on custom code nobody on the team wrote
• The host does not offer staging or per-site PHP switching
• Checkout, bookings or other revenue paths depend on old plugins
• You are on a very old PHP version and a multi-step jump is needed
• You cannot confirm who holds the hosting account

What we will not promise

We will not promise zero issues on a site that has not been touched in years. We will promise a staged process, a rollback and a written list of what changed. Being on a supported PHP version also does not guarantee search results; it removes a security and maintenance risk.

Next step

Send hello@aervio.io your site URL, your CMS and the PHP version you see in your hosting panel, or call +1 438-498-3913, weekdays 9–17 ET. We will tell you whether this is a one-day task or a rebuild in disguise. Our web services page explains how we handle sites after the migration.

Questions

Which PHP 8 version should we target?

The newest version your code and plugins support that still receives security fixes. Check the supported versions page on php.net, because the dates move every year. Do not stop on a version that is about to lose support.

Can we do this migration with zero downtime?

For most sites, yes. If you test on a staging copy, fix errors there, and switch the PHP version in your hosting control panel during a quiet period, visitors usually see nothing. The switch can be reversed in minutes if you keep the previous version available.

What if a plugin or theme is abandoned and breaks on PHP 8?

Replace it, fork it with a documented patch, or remove the feature. Running an unsupported PHP version to keep an abandoned plugin alive trades a visible problem for a security one.