Legacy system modernization is how a business keeps the software customers already rely on while replacing the runtime, the framework and the deployment habits that make every change expensive. Orders, accounts and content stay available. The parts that block a PHP upgrade, a new checkout or a safer hosting setup get replaced in slices, with a rollback if a slice misbehaves.
Contents
At CodeWiz we modernize WordPress and WooCommerce sites, Laravel and plain PHP applications, Node.js APIs and the front ends attached to them. We inventory what the system really does, pin that behaviour with tests, upgrade runtimes and frameworks, move hosting forward and leave you with a deploy your team can repeat. Where a full rewrite would throw away working logic, we keep that logic and change the platform under it.
The service is for companies whose site still runs on a PHP version without security updates, whose original developers have left, or whose store cannot take a new payment method because the platform underneath is frozen. It is also for teams that want better performance and a cleaner security posture without betting the quarter on a big-bang rewrite.
System Migration That Keeps the Business Online
System migration moves an application from the server, operating system or architecture it is stuck on, onto infrastructure you can actually operate. The business requirement is continuity: catalogues, customer accounts, orders and editorial content have to survive the move, and the public URLs that already rank have to keep working.
A migration we can roll back
- An inventory of apps, cron jobs, uploads, sessions, queues and the integrations that call in or out, including the ones nobody has documented.
- A staging copy restored from a real backup, so the rehearsal uses production-shaped data rather than a toy database.
- A cutover plan with a freeze window or replication, a DNS or proxy switch, and a timed rollback that has been tried before the launch.
- Sessions, file uploads and caches moved to shared storage or object storage when more than one app server will serve traffic.
- Logging and an uptime check in place before the switch, so the first hour of the new setup is visible.
Many systems only need a new VPS, a current Linux image and a repeatable deploy. Others benefit from containers once several PHP or Node.js versions have to live side by side. We have written about deployment across DigitalOcean, AWS, Hetzner and bare metal for teams choosing where that new home should be. The move is rehearsed before production DNS changes.
Technology Upgrades for PHP, Frameworks and Front Ends
Technology upgrades bring the language, the framework and the front-end build onto versions that still receive fixes. The usual starting point is an application locked to an old PHP release because a plugin, an extension or an untested corner of the code failed on the first attempt to move forward. We upgrade one major version at a time, with the test suite — or a new characterization suite — as the gate.
| Layer | Typical starting point | Where we take it | Main risk |
|---|---|---|---|
| PHP runtime | PHP 7 or an early 8.0 install | A release that still receives security updates | Removed extensions and syntax between versions |
| Framework | Old Laravel, Symfony, CodeIgniter or a custom MVC | A maintained release, one major at a time | Auth, queues, mail and filesystem changes |
| WordPress | Outdated core and abandoned plugins | Current core, plugins replaced or isolated | A plugin that only runs on an old PHP |
| Front end | jQuery pages or an ageing webpack build | Vite, or server-rendered templates where a SPA is unnecessary | Visual regressions on templates nobody listed |
| Database | MySQL 5.7 or an old MariaDB | MySQL 8 or a current MariaDB | SQL mode, charsets and reserved words |
| Node.js | An unsupported major | An active LTS, with a lockfile rebuild | Native addons and transitive dependency breaks |
- Rector and a static analyser such as PHPStan catch mechanical PHP breaks before they reach a browser.
- Laravel and Symfony apps follow the official upgrade guides, with each major version merged only when the critical paths pass.
- WordPress upgrades start from the plugin and theme list: anything abandoned is replaced, forked or inlined before core moves.
- The allowed PHP version is checked in CI, against the list on php.net’s supported versions page, so a future deploy cannot drift back onto an unsupported runtime.
<?php
if (PHP_VERSION_ID < 80300) {
fwrite(STDERR, "This application requires PHP 8.3 or newer.\n");
exit(1);
}Performance Improvements on an Older Codebase
Performance improvements on a legacy application usually come from a few concentrated fixes, not from a rewrite. Old codebases accumulate N+1 queries, missing indexes, images at camera resolution, and work that runs inside the web request when it could be a queue job.
- The slow queries are measured, then fixed with indexes, eager loading or a rewritten query. The database gets an explain plan, not a guess.
- Full-page and fragment caching — Varnish, Redis or a CDN — sit in front of pages that are the same for most visitors.
- Images are resized and served in a modern format, and the first screen is no longer blocked by scripts the template does not need.
- Email, PDF generation, imports and other slow work move to a queue, so the browser gets a response while the job finishes.
- Search that used to be a heavy
LIKEquery can move to a dedicated engine. Our note on Typesense search for older projects describes that split.
We track Largest Contentful Paint, Interaction to Next Paint and server response time before and after, using the same approach as our work toward 100/100 page vitals. Google’s published line for a good LCP is under 2.5 seconds.
Security Enhancements for Legacy Applications
Security enhancements close the gaps that accumulate when an application stops receiving updates. Unsupported PHP, unpatched plugins, an admin URL on the open internet and secrets committed years ago are the ordinary findings. We treat them as part of the modernization, because a faster app on an abandoned runtime is still a liability.
- The runtime, CMS, plugins and Composer or npm dependencies move onto versions that still receive security fixes.
composer auditandnpm auditrun in CI afterwards. - Authentication and session cookies are reviewed: HttpOnly, Secure, SameSite, password hashing and a session store that survives a second app server.
- Forms get CSRF protection, queries stay parameterized, and file uploads are type-checked and stored outside the public web root.
- Admin and debug surfaces are restricted by network or by an extra login, and directory listings and verbose errors stay off in production.
- Security headers and HTTPS are set at the proxy. Old copies of the site on forgotten subdomains are removed or redirected so they cannot serve stale, vulnerable code.
A modernization is a good moment to rotate database passwords, API keys and payment secrets, and to read them from the environment instead of from a file in Git. When the findings call for a deeper assessment, we scope that separately.
Choosing a Legacy System Modernization Path
There are four practical paths, and the right one depends on how tangled the behaviour is and how long the business can wait for value. Martin Fowler’s strangler fig is the pattern we use most: new code takes over one route at a time, the old application keeps the rest, and a proxy decides which side answers.
| Path | Downtime risk | When value arrives | Fits when |
|---|---|---|---|
| Strangler fig | Low | After the first replaced flow | The system must stay live while parts are replaced |
| Replatform | Medium | At cutover | The behaviour is sound and the platform is the problem |
| Wrap with an API | Low | When the new channel ships | A new app or storefront needs data, and the core can wait |
| Rewrite | High | At the end | The scope is small, or the data model cannot be saved |
# one section moves to the new app; everything else stays
location /account/ {
proxy_pass http://new_app;
}
location / {
proxy_pass http://legacy_app;
}A small application with no tests and a data model that fights every feature can be cheaper to rebuild against the same database than to strangle route by route. A large store with years of orders is the opposite: legacy system modernization in slices protects revenue while the risky corners are replaced. We recommend the shorter safe path after the inventory, and we will say when a rewrite is that path.
Data, URLs and Integrations During the Move
The data and the public URLs are the part customers and search engines notice. Code can be replaced twice; a lost order history or a broken ranking is much harder to undo.
- Schema changes follow expand-contract: add the new column or table, backfill, switch reads and writes, then drop the old shape once the new code has run in production.
- URLs stay the same wherever the content is the same. Every changed URL gets a 301 redirect, and the old and new sitemaps are compared before launch.
- Imports from payment providers, ERPs and shipping tools are listed with their owners, then replayed against staging. Idempotent endpoints keep a retried call from creating a second order.
- Editorial content, product data and customer accounts are counted before and after the migration so a silent truncation is visible.
- A short freeze or a replication lag window is agreed with the people who take orders, so the cutover does not split a payment in half.
Common Legacy System Modernization Mistakes
- Starting a rewrite with no inventory, then discovering the old system sends invoices, talks to a courier and recalculates tax in a cron job.
- Jumping several PHP or Laravel majors in one branch, so every failure arrives at once and cannot be bisected.
- Upgrading WordPress core while an abandoned plugin still forces the old PHP version back.
- Changing URLs during the rebuild and hoping search rankings will return on their own.
- Keeping uploads and sessions on the local disk of one server, then losing them the day a second server is added.
- Declaring the project finished on the day of cutover, with no plan for the next security release.
What Drives the Cost of a Modernization Project
Scope varies enough that we estimate after a short audit. The drivers are usually visible in the first look at the repository and the server:
- The size of the codebase and whether any automated tests describe the behaviour that must stay.
- How many versions the runtime and the framework have to cross, and how many abandoned plugins sit in the way.
- Data volume, the downtime the business will accept, and the number of outside systems that exchange orders or customers.
- Whether the public design changes in the same project or the work is limited to behaviour and platform.
- A single cutover versus a strangler programme that replaces one area per release, plus who maintains the result afterwards.
How We Work
- Discovery: we read the code, the server and the integrations, and write down what must keep working, including the jobs that run when nobody is watching.
- Plan: we choose the path, the target PHP or Node.js version, the order of slices and the rollback, and we agree the scope with you.
- Build: we add characterization tests, upgrade in small merges, and route finished slices to the new code through the proxy or the feature flag.
- Test: we compare critical flows with the old system, check redirects, run the backup restore and review the security items above.
- Launch: we cut over on a rehearsed window, watch errors and response times, and keep the old version ready to receive traffic again.
- Support: we hand over deploy notes and stay for the next upgrades, so the stack does not freeze again six months later.
Why CodeWiz
- We already build on these stacks: WordPress, WooCommerce, Laravel, PHP and Node.js are daily work, so the upgrade is grounded in how the code actually behaves.
- Open-source first: PHP, Laravel, MariaDB, Redis, Varnish and Cloudflare, without locking the modernization to a proprietary platform.
- A path matched to the risk: a replatform, a strangler or a small rewrite, chosen because it fits the system, not because it is fashionable.
- Performance and security together: the same engagement that moves the runtime also addresses caching, queries, headers and abandoned plugins.
- Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally. More about CodeWiz.
Frequently Asked Questions
How much does legacy system modernization cost?
It depends on the size of the code, the test coverage you already have, the number of integrations and whether we are replatforming or replacing behaviour. Upgrading one well-structured Laravel app is a much smaller project than strangling a custom store with a dozen external systems. You receive an estimate after the audit, before work starts.
Should we rewrite or modernize in place?
Modernize in place when the business rules are valuable and the platform is the problem. Rewrite when the application is small, untested and resistant to change, or when the data model cannot support the next product. Most of the systems we see are better served by a strangler or a replatform than by a ground-up rewrite.
Can you upgrade PHP without rewriting the application?
Often, yes. Moving one major version at a time, with Rector, static analysis and tests around the critical paths, is enough for a large share of WordPress, Laravel and plain PHP code. A plugin or a custom extension sometimes has to be replaced because it cannot run on a supported PHP. That is a local fix, not a rewrite of the business logic.
How long does a modernization take?
A runtime and hosting move for a single application, with a rehearsed cutover, is often a few weeks. A strangler programme that replaces checkout, account and catalogue one after another runs longer, because each slice is released and watched before the next begins. The audit produces a sequence you can schedule.
Will modernization hurt SEO?
It hurts SEO when URLs change without redirects or when the new templates ship worse HTML and slower pages. We keep URLs stable, add 301 redirects where a change is unavoidable, compare sitemaps and treat Core Web Vitals as part of the release. Search engines then see the same content on a faster response.
What if the original developers are gone?
That is a common starting point. The inventory, the characterization tests and a staging restore from backup are how we learn the system. Undocumented cron jobs and integrations are exactly what the discovery phase is there to find, before any production cutover.
Ready to Modernize the System You Already Have?
Tell us what the application runs on, what you are afraid to touch and what the business needs next. We will propose a legacy system modernization plan with a rollback. Contact us to discuss the project, or see our legacy system modernization services.