Legacy PHP upgrades without a risky rewrite

Unsupported PHP branches turn hosting notices, security questionnaires and failed feature work into a business crisis, while vendors pitch a full rewrite before anyone lists what revenue still depends on. You Go Media’s legacy PHP upgrade programs are for CTOs and IT owners across Canada and the US who need staged modernization: reduce runtime risk without a reckless all-at-once rewrite.

All work is led from our headquarters in Winnipeg, Manitoba. Part of Application Foundation.

Why unsupported PHP becomes a business problem

End-of-life and security-only PHP branches can complicate hosting renewals, security questionnaires and client reviews, and make it harder to hire for or extend the codebase safely. Then there is the “it still works” code nobody wants to touch, until a failed deploy or questionnaire forces a crisis hire.

If the real job is leaving an unsupported PHP version, with risks ranked and a disciplined cutover, a greenfield rewrite pitch is the wrong product. You Go Media scopes an upgrade program and does the work with you.

What “upgrade” can mean once the work is scoped

• Version remediation: move off EOL or soon-unsupported branches with compatibility inventory
• Targeted refactor: strengthen the parts of the code that block a safe PHP version upgrade
• Staged modernization: replace the old system piece by piece when a full rewrite would be for show
• The right service for your site: we modernize custom PHP applications. Need PHP updated on a WordPress site? See WordPress care. Building a new application from scratch? See custom PHP development.

We refer to official PHP support windows in general terms during your initial consultation; we report only the risks we find in your application.

What the upgrade assessment gives you

Before you commit to the full upgrade, you receive an inventory of what the application runs on and what stands in the way of a supported version:

• Runtime: the current PHP version and extensions, and the supported PHP 8.x release to target
• Framework and dependency blockers: libraries, packages and framework versions that will not run on the target
• Deprecated code: functions removed from newer PHP releases, such as old mysql_* database calls
• Hosting constraints: what your current host supports, and whether a staging environment exists
• A risk-ranked plan: security and hosting blockers first, nice-to-have refactors last, with the dependencies between steps

Work in scope includes moving PHP 5.x and 7.x applications to a supported PHP 8.x release and replacing old mysql_* calls with PDO. The stack we build on afterwards is described on custom PHP development.

Testing, staging and rollback

Each stage of the upgrade runs on staging before it touches production. A stage moves to production only when:

• the application runs on the target version in staging without new errors in its logs
• the workflows your revenue depends on, such as logins, checkout, forms, reports and integrations, have been tested and signed off by your team
• a rollback path is ready: the previous release and a current database backup, so production can return to its last working state

If a stage misbehaves in production, rollback means returning to that last working state while the problem is fixed on staging. Each cutover is planned to keep disruption low.

How we decide between upgrade, refactor and rebuild

The choice comes from evidence in the assessment, weighed against criteria your leadership can check:

• Cost of keeping it: hosting surcharges or restrictions on old versions, time lost to workarounds and feature work that keeps failing
• Security pressure: questionnaire items or customer security reviews the current code cannot pass
• Hiring: whether you can find people able and willing to maintain the code as it stands
• Revenue at risk: which workflows earn money, and how much change each one can absorb at once

A rebuild is recommended only when these criteria point to it, and the assessment shows the reasoning so your team can test it.

Questions to put to any upgrade provider

Whoever does the work, these questions show whether an upgrade plan protects what the application earns today:

• Will the application be inventoried before anyone recommends a rewrite?
• Which workflows are tested on staging before each stage reaches production, and who signs them off?
• What is the rollback path if a stage misbehaves in production?
• Could another developer maintain the code afterwards, and what would they need?

The sections above set out how we answer each one, and your written scope confirms it for your application.

Support and care after the upgrade

Once the runtime is supported, it needs to stay that way. Prices are in CAD, plus applicable taxes:

• Custom applications: support tickets at $150/hour CAD, billed in 15-minute increments, or prepaid blocks at $125/hour CAD with a 5-hour minimum per purchase
• WordPress sites on old PHP: WordPress care, Basic at $49.95/month CAD or Plus at $99/month CAD, which includes 1 ticket hour per month

Starting an upgrade, and what it costs

An upgrade starts with an initial consultation, a non-refundable retainer to build your plan: $399 CAD plus applicable taxes, credited toward your program if Pay on Results is approved.

For most legacy upgrades we recommend starting with a technical diagnostic (from $1,495 CAD plus applicable taxes). The diagnostic fee is credited toward any project or retainer that acts on its findings, if you proceed within 60 days of delivery.

Updating PHP on WordPress vs modernizing a custom app

Brochure or CMS sites stuck on old PHP are usually best served by WordPress care, together with a hosting update. Custom applications and ageing MVC stacks are what we modernize in this service. New modules, once the runtime is safe, are built through custom PHP development.

Services that often follow an upgrade

• WordPress development: when a CMS rebuild is cleaner than fighting legacy themes
• Custom PHP development
• B2B web portals

Legacy PHP upgrade questions

Do you always rewrite legacy applications?

No. Staged upgrades and targeted refactoring are our default. We avoid reckless rewrites.

Can you modernize without downtime?

We design risk controls and staging discipline. We do not offer zero-downtime SLAs.

What about WordPress sites stuck on old PHP?

Often that is a care and hosting job; see WordPress care. Runtime programs for custom applications stay here.

Do you upgrade apps for teams in other cities?

Yes. Our headquarters is in Winnipeg, Manitoba, and we upgrade legacy PHP applications for clients across Canada and the US.

Start a legacy PHP upgrade conversation

Share your current PHP version if you know it, whether hosting or a security review is forcing the timeline, and whether staging access exists. Then request a project scope, and we will confirm next steps.