Your website or business system still runs on an old PHP version, on CodeIgniter, on Symfony 2 or on in-house code written fifteen years ago. We rebuild it on a modern, secure and maintainable foundation, without losing the business rules that make it valuable.
A PHP rewrite means rebuilding your website or management system on a supported PHP version and a maintained framework, carrying over the existing features and data. This is not a redesign: the technical foundation itself is replaced.
The signals that make a rewrite urgent:
Every year spent on an obsolete stack raises the bill: that is exactly what technical debt is, and it always gets repaid in the end.
We regularly inherit applications written by someone else, sometimes with no documentation and no original developer available. Our work always starts by understanding the existing code before writing a single line. These are the stacks we take over most often:
The most common framework in Quebec internal systems built in the 2010s. Overloaded controllers, SQL queries inside views, no test layer at all. Migrated to Laravel.
Structured projects, but frozen on a major version too old to be upgraded in place. We move them to a recent Symfony or to Laravel, depending on your team.
Often found in insurance, finance and healthcare applications. Verbose, expensive to evolve, and rare on today's developer market.
Frameworks that still work, but whose local ecosystem has dried up. The risk is not technical, it is human: finding who will maintain the system five years from now.
An older Laravel project can often be upgraded rather than rewritten. We assess both before recommending, because the upgrade usually costs less.
A CMS turned into a management system through plugins and custom code. We separate the marketing site from the application, each on the tool built for it.
PHP files mixing HTML, SQL and business logic, written by an employee who left long ago. This is the most frequent case, and the one where the most value gets recovered.
A rewrite rarely fails for technical reasons. It fails because a business rule buried in an old file was never documented, and nobody noticed before go-live. Our process is built to remove that risk.
We read the code, the database and the infrastructure to establish an honest picture: real volume, risk areas, dead dependencies, security holes. This step is our code audit service, and it stands perfectly well on its own if you first want to know where you stand.
We document your database structure, the relationships between tables and, above all, the implicit business rules: the calculations, the statuses and the exceptions the code applies without anyone ever having written them down elsewhere.
We rebuild the application on PHP 8 and Laravel, using our code generator for everything repetitive (models, migrations, CRUD screens, permissions). The time saved goes where it matters: the business rules that are yours alone.
We move your historical data into the new schema with replayable scripts and reconciliation reports. Every discrepancy is identified and handled before the switch, never after.
A planned go-live, 301 redirects in place if URLs change, and a run-in period with your team. Support and maintenance then takes over.
Taking over someone else's code is a different craft from writing new software. It takes reading, patience and a method that loses nothing along the way.
CodeIgniter, Symfony, Zend, framework-less PHP: we have already taken these stacks over, including with no documentation and no original developer. We know what it costs and we say so before starting.
Every behaviour of the existing system is mapped and validated with your teams before being rewritten. Whatever the old software was doing without your knowledge, you will know about it.
Our generator produces the repetitive base of the application. You pay for the logic that sets you apart, not to rewrite a user management form for the hundredth time.
PHP 8, Laravel, automated tests and up-to-date documentation. You own the code and stay free to hand it to whoever you want.
Witify has understood our needs from day 1, educating us, guiding us and accompanying us through the evolution of our system for over 7 years now. They are the cornerstone of our technological development.
The cost depends on the number of screens, the volume of business rules and the state of the database, not on the number of lines of code. A code audit of a few days is usually enough to produce a reliable range. Our article on the cost of custom software development gives the market orders of magnitude.
Yes, and it is the migration we perform most often. There is no automatic tool: the two frameworks do not share an architecture. We keep the database as it is when it is sound, then rewrite the controllers, models and views to match the observed behaviour. Standard screens are generated, business logic is rewritten by hand.
Yes. Those versions receive no security patches at all. In practice: a flaw discovered today in PHP 7.4 will never be fixed for you. Most hosts eventually remove these versions, which takes the site offline overnight. That is a deadline better planned than suffered.
Both exist. A progressive modernization fits when the architecture is sound and only the technical foundation is outdated. A full rewrite becomes the better option when every fix breaks something else, when the framework is no longer supported, or when nobody understands the code any more. The audit settles that question on facts rather than impressions.
It gets migrated. We transform your existing schema into the new model with replayable scripts, then produce reconciliation reports (record counts, financial totals, statuses) that your teams validate before the switch. No migration goes live without that validation.
Not if URLs are handled seriously. We inventory every indexed address, keep them where possible, and put 301 redirects in place towards the new pages otherwise. Rankings hold, and they often improve thanks to the performance gains of the new stack.
Yes. The old system keeps running while the new one is built in parallel. The cutover is planned with you, often outside operating hours, and a rollback procedure is ready before the deployment even starts.
PHP 8 and Laravel for the application core, with whatever modern interfaces the project calls for. We stay on PHP when your team knows it: switching languages without a reason adds risk without benefit. Our technologies page details the full stack.
