PHP application: modernize or rewrite?

A grown PHP application rarely becomes a topic while it runs reliably. Once changes take months, security updates pile up, or nobody wants to touch the checkout, the same question appears: rewrite everything or modernize what exists?

The answer is rarely a matter of taste. It depends on how much business knowledge lives in the current code, how easily that code can change, and how much risk the company can carry.

The question usually starts in the wrong place

A rewrite sounds clean. The old code has visible problems, and a new project could finally follow current standards. That view does not explain what the business needs.

The decisive question is not whether the existing code is elegant. It is which business rules must survive and which should change. Without that distinction, nobody knows the real scope of the project.

What a rewrite quietly discards

An application that has been in production for eight to twelve years contains more business logic than any requirements document. Special cases for individual customers, invoice rounding rules, shipping exceptions, historical discounts. These rules are rarely documented. They exist as code, as comments, or as a workaround nobody has touched in years.

A rewrite initially carries over only the rules someone actively remembers. The rest disappears. That does not show up on day one. It shows up weeks later, when an invoice is off by two cents or a customer can no longer place an order.

A rewrite is therefore not only a technical effort. It reconstructs knowledge that already exists in the old system.

The cost profile of both paths

A rewrite concentrates cost and risk into a single project. The team builds for months without users benefiting. Often the old application keeps running in parallel and keeps receiving fixes. The cutover day is the riskiest moment, because defects become visible in production for the first time.

Modernization spreads the effort across several quarters. The application stays deployable, releases continue, and each change can be verified on its own. The price is patience: visible progress is smaller, and the team needs discipline so the effort does not become a permanent side project.

Both paths can be right. They fail in different ways. A failed rewrite costs years. A failed modernization costs trust, because it never reaches the finish line.

The riskiest moment of a rewrite is cutover day. Modernization does not have that day.

Four checks before the decision

Before choosing between the two paths, review four areas. They say more about risk than the condition of the code.

Test coverage. Are the paths where money moves covered by tests? Invoices, payments, refunds, taxes, shipping. Thirty percent coverage can be enough if it covers exactly those paths. It can be worthless if the tests were written where testing was easy.

Dependencies. Which PHP version runs, which framework version, and which Composer packages are abandoned? Tools such as composer outdated and composer audit provide a first list. The practical question is whether every package has a supported successor.

Deployments. Can you ship a change today and roll it back without copying files by hand? If that is not repeatable, it complicates both paths. A rewrite without dependable deployment simply reproduces the problem.

Knowledge spread. How many people can deploy, fix incidents and manage access? If the answer is one, the company has an operations problem first, regardless of the decision.

Hybrid paths: strangler and staged replacement

You do not have to choose between full modernization and a complete rebuild. The strangler approach places a new layer in front of the existing application and moves one area at a time. A routing layer sends one route to the new code first, then more. The old code stays reachable as a reference until each area is fully replaced and verified.

With staged replacement you replace individual domains, such as the customer portal, while the rest keeps running. During the transition both parts run in parallel, and you compare results before switching off the old path. This works well when modules are cleanly separated. It works poorly when data models and business logic are tightly interwoven.

Both hybrid paths generate experience. Each finished stage shows how the application actually behaves and makes the next estimate more reliable.

What a serious estimate needs

A number without a foundation is a guess that gets corrected at high cost later. A defensible estimate comes out of an assessment:

• list of business-critical flows and their technical paths
• modules, dependencies and known problem areas
• data model and migration needs
• external integrations and their contractual terms
• access, infrastructure and deployment path
• test strategy for the critical paths
• cutover plan with a fallback path

That foundation lets you compare the two options instead of arguing about them.

When a rewrite can make sense

There are cases where a rewrite is the better choice. When the product is changing fundamentally, when the technology is no longer supported and no migration path exists, or when the application is small, well tested and fully understood. Even then, ship in stages rather than in one large step.

For most grown PHP applications, modernization is the more economical path. It preserves business knowledge, removes the largest risks first, and keeps the application deployable during the work.

Conclusion

The choice between modernization and a rewrite is not a matter of belief. It depends on what the existing code does, how well you can change it, and how much risk the business can carry.

If you want to establish that foundation, the next step is a PHP modernization or a broader software modernization. The article on signs of technical debt covers how to spot the risks beforehand.