PHP runtime upgrade & application modernization

Your application needs newer PHP.
It usually doesn’t need a rewrite.

Update incompatible code and dependencies. Keep the workflows your business relies on.

Your host, a new integration or an updated library needs a newer PHP version. We adapt the application code and dependencies to the agreed supported runtime, verify business behaviour and prepare a controlled release.

Usually compatibility work rather than a rewrite. Framework replacement, redesign and new features are separate decisions—not automatic additions to a runtime upgrade.

First review on us →Chat with us →

Typical scoped work: $99–$5,000, depending on version drift, relevant line count and dependencies. Scope and milestone payments are agreed before work begins. A $100 audit is required first and is fully credited toward the service you choose.

Production keeps serving

Engineering changes are built and tested on a separate copy.

Approve each milestone

Review the working result and test evidence before the corresponding milestone payment.

Dependencies included in the plan

If a library needs a maintained fork, ownership and ongoing responsibility are agreed upfront.

When newer PHP meets older code

Changing the PHP version should not become a production experiment.

The server can run newer PHP, but your application may not. Removed functions, changed syntax and stricter behaviour can break a login, calculation, report or background job. The task is to find and fix the affected code without changing the business rules you need to preserve.

Old functions stop existing

Database calls, callbacks and older syntax can fail on a newer runtime. The impact may appear only in a payment, report, upload or scheduled job.

A library nobody maintains

Your application can depend on an abandoned package or custom vendor modification. Replacing it, adapting it or maintaining a fork needs an explicit plan.

The application has to keep running

A test homepage is not enough. Business rules, stored data, integrations and background jobs need to behave correctly after the switch.

We address the right problem. The right layer. The right amount of change.

Choose the amount of change

A PHP upgrade and a new application architecture are different jobs.

Runtime compatibility

Keep the application and its workflows. Fix removed functions, incompatible syntax, changed behaviour and runtime configuration so the agreed PHP target works.

Dependency & framework upgrade

Upgrade compatible package and framework branches. Where an abandoned component blocks the move, assess a replacement or a maintained fork.

Application modernization

Refactor selected modules, separate input and database access, add APIs or improve architecture where the business needs it. Framework migration is separately scoped.

Need to preserve the existing PHP runtime and move the server first? EOL application rescue addresses an obsolete operating system or hosting environment. This service addresses application code and dependencies that must run on newer PHP. A server move alone does not fix PHP compatibility.

Custom PHP, legacy CodeIgniter, CakePHP, Zend Framework/Laminas, Laravel, Symfony and PHP-based CMS extensions are assessed against their actual versions and modifications. A working application does not need to adopt a new framework simply because PHP changes.

PHP upgrade & modernization

$99–$5,000 depending on scope

Version drift and relevant code size establish the starting point. Dependency condition, integrations and acceptance testing determine the work. Larger framework replacements or extensive rebuilds are quoted separately.

Price agreed before engineering

We identify the current and target versions, affected code, dependency work, deliverables and milestone amounts. Vendor libraries and generated files are counted separately from your application code.

A small codebase with a difficult dependency can need more work than a larger, well-tested application. Line count is a scoping input, not the complete price formula.

Audit (required)

$100 · credited toward the service you choose

The audit examines versions, dependencies and affected code before the plan and price are finalised. Its full cost is credited against the work you go ahead with.

Combining server rescue with a PHP upgrade? Server migration and PHP compatibility work are priced as separate components. Shared assessment, cloning and deployment work are identified once in the proposal, so you are not charged twice for the same work.

Safety · milestone payments · traceable changes

Working results at each stage. Your approval before the next.

Each milestone has a defined scope, fixed amount and acceptance checks. Payment follows your approval of its deliverables. Changes outside that scope are priced and approved before they are added.

Audit & agree

Required. $100, fully credited toward the service you choose. Identify versions, includes, calls, libraries and critical workflows. Deliver the upgrade plan, boundaries, tests and payment schedule.

Adapt on a clone

Change the affected functions and dependencies in an isolated copy. Keep a versioned record of what changed and why.

Test

Compare business behaviour, database results, jobs and integrations. You review the working copy and evidence.

Switch

Release after approval using the agreed traffic, session, queue and data plan. Validate the application under live traffic.

Hand over

Deliver code, dependency records, test results, deployment and rollback instructions, and the agreed maintenance responsibilities.

Keep serving while the upgrade is prepared.

We prepare the newer runtime alongside the working application. For compatible deployments, a blue-green or rolling switch can avoid planned service downtime: route new requests to the tested release, drain existing requests and preserve compatible sessions.

Database changes use compatible staged migrations where feasible. Queue workers and cron jobs have a single agreed execution owner during the switch. If consistency requires a pause in writes, that window is identified and agreed before launch. Zero downtime is a deployment result to establish for your application, not an assumption.

Rollback covers data as well as code. Retain the previous release and runtime, define rollback triggers and account for database changes and new writes. A source backup is verified before deployment.

A fork needs an owner after launch.

If an abandoned dependency must be forked, agree who holds the repository, who reviews security fixes, who maintains compatibility, and how future updates are paid for before work starts. Source access, the original licence, upstream attribution and the handover are documented. A one-time upgrade does not silently include indefinite maintenance.

PHP version compatibility reference

Where PHP functions, syntax and behaviour changed.

An upgrade across several versions must account for every intervening compatibility change. The examples below show common checkpoints; they are not an exhaustive scan of your application. Deprecated means still present with a warning in that version; removed means unavailable.

Version checkpoint	Change to check	Typical compatibility work
PHP 5.2 / 5.3-era applications	Start with an inventory of extensions, framework versions, database APIs, includes and deployment settings. Check all intervening version changes, not just the destination.	Preserve the existing behaviour while identifying the complete compatibility gap. Official PHP reference →
PHP 5.4	register_globals, magic quotes and safe mode removed. Short array syntax introduced.	Make input handling explicit; check code that relied on automatic escaping or injected globals. Official PHP reference →
PHP 5.5 → 7.0	The original mysql extension was deprecated in 5.5 and removed in 7.0.	Replace mysql_* calls with an agreed mysqli or PDO implementation; verify queries, charset, errors and transactions. Official PHP reference →
PHP 5.6	TLS streams verify peer certificates and hostnames by default; JSON parsing rejects invalid mixed-case literals.	Check external HTTPS connections and JSON integrations. Fix trust configuration rather than disabling verification. Official PHP reference →
PHP 7.0	Many fatal errors become Throwable errors. The preg_replace /e modifier is removed.	Update error handling and replace evaluated replacements with reviewed callbacks. Official PHP reference →
PHP 7.1	Too few arguments to user-defined functions raise ArgumentCountError.	Trace call sites and optional/default arguments across files. Official PHP reference →
PHP 7.2	count() on non-countable values emits a warning; mcrypt is removed from the bundled extensions.	Check nullable and non-array values. Plan encryption compatibility and existing-data handling. Official PHP reference →
PHP 7.3	continue targeting a switch emits a warning.	Determine whether the intended action is break or continuing an enclosing loop. Official PHP reference →
PHP 7.4	Curly-brace array/string offset access is deprecated.	Replace $value{$index} with $value[$index] and test the affected paths. Official PHP reference →
PHP 8.0	each() and create_function() removed; curly-brace offsets removed. Numeric-string comparisons and error behaviour change.	Review loops, callbacks, comparisons and TypeError/ValueError handling; do not assume syntax-only fixes preserve results. Official PHP reference →
PHP 8.1	Passing null to non-nullable parameters of internal functions is deprecated. mysqli defaults to exception-based strict error reporting.	Check nullable inputs and database exception handling. Official PHP reference →
PHP 8.2	Creation of dynamic properties is deprecated, with documented exceptions.	Declare intended properties or adapt deliberate dynamic behaviour; review frameworks and hydrated objects. Official PHP reference →
PHP 8.3	Date/time failures use more specific exception and error types.	Check date parsing, invalid inputs and exception handlers. Official PHP reference →
PHP 8.4	Implicitly nullable typed parameters are deprecated.	Use explicit nullable types and review signatures and required parameters. Official PHP reference →
PHP 8.5	Non-canonical casts such as (integer), (boolean), (double) and (binary) are deprecated.	Use (int), (bool), (float) and (string); review the complete target migration guide. Official PHP reference →

For mysql_* → mysqli/PDO, we follow connections and queries across includes and functions. Connection scope, escaping or parameter binding, character sets, transaction boundaries and error handling are verified together. Renaming functions alone is not a database migration.

Encryption changes need particular care: switching away from mcrypt must preserve the ability to read existing encrypted data, or include an explicit data-conversion plan. Hashing and encryption are not interchangeable replacements.

Choose a target with useful support life.

As checked on 8 October 2026, PHP 8.2 and 8.3 receive upstream security support; PHP 8.4 and 8.5 remain under active support. The target is selected around dependency compatibility and the support window, rather than automatically stopping at the oldest supported release.

Official PHP support windows · Official migration guides. Recheck the target and support dates when the project is scheduled.

PHP modernization, security & scaling

Prove the behaviour. Then measure the improvements.

Compatibility checksReview parse errors, removed APIs, types, signatures, comparison behaviour and extension availability. Static analysis and automated transformations assist the work; reviewed tests determine acceptance.

Business regression testsUse representative data to verify permissions, calculations, reports, payments, uploads and integrations. Test jobs and failure paths as well as successful requests.

Security scopeA patched runtime removes runtime exposure but does not automatically fix application flaws. SQL injection, output escaping, CSRF, authentication and file handling are assessed or remediated where included in the agreed scope.

Performance & scaleCompare latency, error rate, throughput, memory and database load before and after. Tune PHP-FPM and OPcache where appropriate. Additional application instances require suitable sessions, shared files, database capacity and job coordination.

Versioning & handoverRecord source revisions, runtime and extension versions, dependency lock files, configuration and deployment identifiers. Deliver function-level change explanations and test outcomes so the work can be reconstructed.

A framework migration—for example, CodeIgniter, CakePHP or Zend Framework to Laravel or Symfony—is an architecture project with its own routing, models, templates and test scope. Incremental module replacement may be suitable; it is not sold as a small runtime compatibility fix.

Before you upgrade PHP

How is this different from EOL application rescue?

EOL rescue moves or contains an obsolete server environment while preserving the working application where possible. This service changes application code and dependencies for a newer PHP runtime. They can be combined, with separate scopes and shared work priced once. EOL application rescue →

Does the application have to be rewritten?

Usually not. Runtime upgrades typically need targeted compatibility changes. Replacing a framework or redesigning the application is a separate decision with its own scope.

Can the application stay online?

Yes, while the upgrade is prepared and tested on a clone. Zero planned service downtime at release depends on traffic switching, compatible data changes, sessions and jobs. Any required write pause is agreed before deployment.

Is the audit required?

Yes. The $100 audit is required for every PHP upgrade. It examines versions, dependencies and affected code before the plan and price are agreed, and it is fully credited toward the service you choose.

Why does the price range from $99 to $5,000?

A small compatibility fix differs from a multi-version application upgrade. Version drift, relevant line count, abandoned dependencies, integrations and testing establish the agreed price. Extensive replacements are quoted separately.

How do milestone payments work?

Before engineering, we agree each milestone's deliverables, acceptance checks and payment amount. You review and approve the result before its payment and the next stage. Additional scope needs a separate agreement.

What if a dependency is abandoned?

We assess updating, replacing or forking it. If a maintained fork is needed, repository ownership, licence obligations, maintenance responsibility and future costs are agreed before work begins.

Can you keep my existing framework?

Where its code and dependencies can run on the chosen runtime, yes. Framework replacement is not required by default. Unsupported components that remain are identified in the maintenance plan.

Will newer PHP make the application faster?

We measure it. Runtime improvements can help, but database queries, external services, memory use and configuration still matter. Performance targets and any optimization work are included explicitly in scope.

What happens if the release fails?

The agreed rollback plan restores the previous release and runtime where appropriate, with a defined approach to schema changes, sessions, queues and data written after the switch.

Start with the application you already have

Make your application compatible with the PHP version you need.

Send your PHP version, framework or custom application details, approximate code size and the upgrade you need. Tell us which functions cannot fail. We will explain the likely compatibility work, dependency responsibilities and milestone plan.