Modernizing a Legacy PHP Platform to PHP 8: Full Rewrite or Strangler Fig?

Start with the business risk, not the rewrite

A PHP 5 or PHP 7 application may still process orders, issue invoices and connect to systems that teams rely on every day. Those PHP branches no longer receive security fixes from the PHP project. Unsupported libraries, an aging operating system, incompatible hosting and a shrinking pool of people who know the application can compound the risk. Third-party extended support may mitigate some exposure, but it does not make an old platform current or eliminate the need to migrate.

Inventory the runtime, extensions, Composer packages and custom libraries alongside hosting, databases, scheduled jobs, interfaces, access rights and deployment procedures. Identify who understands each business process and where knowledge exists only in code or in a colleague's memory. Record critical flows, current incidents and acceptable interruption before selecting a target. This is the foundation for custom PHP development that protects what already works.

An in-place upgrade retains the application while updating PHP, dependencies and incompatible code. It can be appropriate when the architecture and business model still fit, dependencies have viable upgrades and regression coverage can be built. A rewrite replaces the application as a coordinated project. Strangler Fig places a routing facade in front of the old and new systems so capabilities can move one at a time. Neither replacement approach removes the need to secure and maintain the legacy system during transition.

Full rewrite or Strangler Fig: compare the trade-offs

Strangler Fig is not automatically cheaper, faster or safer. If the facade cannot reliably separate requests, or shared data requires constant coordination, its overhead can outweigh its benefits. Conversely, a rewrite is not an excuse to defer learning the old system until cutover.

Five steps for an incremental migration

1. Map the system and choose a boundary

Trace a request from the browser through PHP, the database, queues and external services. Map integrations, data ownership, security controls, peak periods and operational dependencies. Interview the people who handle exceptions, not only the original developers. Prioritize a bounded capability with a meaningful business outcome, identifiable owner and manageable dependencies; document what stays behind and how success will be measured.

2. Introduce a routing facade

Put a reverse proxy or application gateway in front of the legacy and new applications, then route a selected path or capability to the new implementation. Define routing rules, authentication, headers, monitoring and failure behaviour; the facade itself can become a bottleneck or single point of failure. Check session compatibility explicitly: cookie scope, signing, encryption, storage and expiry may differ. A shared identity service or a deliberate session hand-off may be safer than assuming the two applications can read each other's sessions.

3. Capture existing behaviour with characterization tests

Before changing a flow, record what the current system actually does with representative inputs, including edge cases and failures. Compare results with business owners: an unexpected result may be an intentional exception or a defect that should not be carried forward. For invoices, test GST and QST calculations, the order in which discounts and taxes apply, and rounding at line and invoice level using agreed examples. Include permissions, exports and integration responses, and protect sensitive production data in test fixtures.

4. Migrate data and integrations deliberately

Name the source of truth for each entity and each stage of the transition. Define ownership of writes, schema mapping, reconciliation, backfills and conflict handling before enabling the new flow. Avoid assuming that two independently writable copies will stay consistent. For external APIs, payments, ERP connections and background jobs, use idempotency keys or equivalent safeguards for retries, set timeouts, and plan for duplicate messages, partial failures and delayed responses. Reconcile records and side effects, not just row counts.

5. Switch, observe and retire

Rehearse cutover and recovery with the teams who operate the service. Shift a controlled slice of traffic when feasible, monitor errors, latency, business outcomes and reconciliation discrepancies, and agree on thresholds for pausing or reverting. A routing switch back is not necessarily a complete rollback: once the new system has changed data or triggered external side effects, recovery may require reverse migrations, replay, reconciliation or manual intervention. Verify the recovery procedure against realistic data and retain backups. Retire legacy routes, jobs, credentials, infrastructure and the facade only after dependencies are removed and the new capability is validated.

Build a budget and decision grid without guessing prices

Estimate from an inventory and a small discovery exercise, not a generic price per page or a promised timeline. Compare the same scope and operating period across options, with explicit assumptions, uncertainties and a contingency for discoveries. Include the cost of staying on the current platform while work proceeds.

Set decision checkpoints after discovery and after a representative pilot. A failed boundary experiment is useful information: it can justify changing the sequence or selecting another approach before the organization commits to a larger migration.

Choose PHP 8 and a framework by support lifecycle

PHP 8.4 and 8.5 are possible targets when the application, extensions, host and chosen framework support them. According to PHP's published schedule, security support for PHP 8.3 ends on December 31, 2027; PHP 8.4 on December 31, 2028; and PHP 8.5 on December 31, 2029. Verify the current schedule and your dependencies before committing. Compatibility with PHP 8 is not a single guarantee: individual minor versions have distinct support windows and breaking changes.

Laravel 13 requires PHP 8.3 or newer. Symfony 7.4 requires PHP 8.2 or newer, while Symfony 8.0 requires PHP 8.4 or newer. Framework and PHP support dates are separate: Symfony 7.4 is an LTS release, while Symfony 8.0 is a short-lived release whose support ended in July 2026. Do not assume all Symfony 8.x releases have the same lifecycle; check the specific release and its dependencies. Choose a maintained release compatible with the target runtime and your upgrade capacity.

A migration to Laravel can be a fit for a team seeking its conventions and ecosystem; Symfony architecture for critical applications may suit a domain that benefits from explicit components and boundaries. Neither framework is mandatory for PHP 8, and the decision should account for team experience, maintainability and the actual domain rather than popularity alone.

Measure performance rather than assuming an upgrade fixes it

Establish a baseline for latency, throughput, database load and error rates on important workflows. PHP 8 may offer improvements, but a runtime change does not automatically fix an N+1 query pattern, missing indexes or slow remote calls. Profile first; batch or eager-load data where appropriate, and measure again using representative workloads.

Use caching only with an explicit invalidation and freshness policy, especially for prices, permissions or personal information. Move suitable work to queues when a user need not wait for it, but monitor backlog and failures and design retries to be idempotent. Protect critical synchronous operations with timeouts and an appropriate failure response.

Treat privacy as part of the migration

The applicable rules depend on the organization, the information and the jurisdictions involved. Quebec's Law 25 modernized its privacy legislation; federal PIPEDA may apply to certain commercial activities, and Ontario's PHIPA can apply to personal health information handled by health information custodians and others in defined circumstances. These regimes are not interchangeable. Obtain legal advice on applicability and obligations rather than treating a technical migration as proof of compliance.

With privacy and security leads, map personal information across production, logs, backups, test environments and vendors. Review access controls, retention and deletion, encryption, incident procedures and cross-border transfers; consider privacy impact assessments where required. Minimize or mask test data and verify that new integrations do not silently broaden access. Document decisions and validate the resulting controls in operation.

Frequently asked questions

Begin with an assessment

A successful migration preserves the business knowledge embedded in the old platform while giving the organization a supportable path forward. An in-place upgrade may be enough; a rewrite may be justified; a Strangler Fig migration may offer useful delivery boundaries. The evidence from your application should decide.

Start with an assessment of your critical workflows, PHP dependencies, data ownership and operational constraints. Nuevamed can help your team evaluate the options and define a migration approach grounded in your business priorities.