How long does a PHP 8 migration take?

It depends heavily on the tool being audited: code size, number of abandoned dependencies, whether tests exist. As a rough guide, the audit itself takes from 3 to several weeks depending on these factors. I give a precise range for the migration itself once the audit is done, never before.

Do we have to rewrite everything?

Almost never. A full rewrite makes sense on narrow scopes, for example a module whose logic has become unreadable or whose business need has changed. Everything else gets migrated. Your code holds years of business decisions, and discarding them means paying for them twice.

What happens to my business logic?

It is identified during the audit, isolated, tested, then moved. This is the most delicate part of any migration: those rules are rarely documented and often scattered. I extract them and cover them with tests before changing anything, so the observed behaviour stays the same after the switch.

Will my application go offline during the migration?

No, that is the point of working in batches. The application stays live throughout. Switchovers that need a maintenance window are announced in advance, scheduled in a slot you pick, and backed by a tested rollback procedure.

Can we keep developing the application during the migration?

Yes, with one trade-off. Fixes and urgent changes go through, but new features belong on the migrated part rather than the old one, otherwise you pay for the same work twice. We set that rule during scoping.

How do I know whether my application is worth migrating?

That is exactly what a legacy PHP code audit answers. It compares the cost of migrating against keeping things as they are and against replacing the application with an off-the-shelf product. Sometimes the conclusion is not to migrate, and I will tell you so.

Do you only work in Réunion Island?

No. I am based in Saint-Denis and travel across the island for on site work, and I work remotely for clients in mainland France. Migration work suits remote collaboration well: the work happens in the code, with regular checkpoints and direct access to progress.

Legacy PHP migration to Symfony: modernising without stopping production

Your application has been running for years. It keeps your business going, it holds business rules that were never written down anywhere else, and its technical foundation is no longer viable. A legacy PHP migration done properly is not about throwing everything away and starting over. It is about moving your application onto a supported base while keeping your business logic intact, one piece at a time.

I am Marc-Antoine Boyer-Dager, a freelance Symfony developer based in Saint-Denis (97400), Réunion Island. I work on site locally and remotely for clients in mainland France. My speciality is legacy migration: PHP 5 to 8, Symfony 3 to 7, ageing monoliths towards clean, tested architectures. I work on production code, with real users and business constraints nobody can afford to ignore.

Signs that it is time to act

Your PHP version is no longer maintained

An application running on PHP 5, or on an unsupported 7.x release, no longer receives security fixes. Your host will eventually force the move, often with short notice. Planning a PHP 5 to PHP 8 migration in advance costs less than doing it under pressure.

Every change breaks something else

This is the clearest symptom of PHP technical debt: no tests, mixed responsibilities, and files nobody dares to touch. Development slows down until the smallest change becomes a project of its own.

You depend on a single person

When only one developer understands the application, you no longer control your own production tool. A migration is also the moment to make the code readable by others and to document past decisions.

A framework frozen on an old version

A Symfony 2 or 3 application cuts you off from current tooling, maintained bundles and easy hiring. A Symfony 3 to Symfony 7 migration happens in steps, version by version, not in a single leap.

What I actually do

I handle the technical side end to end, on a stack I use daily: Symfony 7, PHP 8.3, Doctrine, MariaDB.

Legacy PHP code audit: mapping the existing system, listing dependencies, spotting risk areas and business rules buried in the code.
Incremental migration plan: work split into deliverable batches, ordered so that blockers and security issues come first.
Language and framework upgrade: moving to supported PHP and Symfony versions, replacing abandoned components.
Data migration: schema and content scripts, with integrity checks before switching over.
Business application rewrite where rebuilding a module is more sensible than repairing it, a call we make together based on measured complexity.
Automated tests added as we go, so each migrated batch can be verified by something other than the naked eye.

How I work

Audit and scoping. I read the code, talk to your teams and list the features actually in use. This step produces a written document: current state, ranked risks, migration options and their consequences. You can stop there and keep the document, it is yours.
Incremental migration plan. We split the work into batches that reach production one after another. Each batch has a scope, a success criterion and a rollback procedure. The goal is simple: at no point should you end up with two versions of your application ignoring each other.
Batch delivery, with the old application still live. I work on branches, add tests to the code I touch and deliver in increments. Old and new coexist as long as needed. Switchovers happen in time slots you choose, never on a Friday evening by surprise.
Knowledge transfer. I document architecture decisions, deployment procedures and things to watch out for. If you have an internal team, I train them on the delivered code. I am FPA certified and have trained more than 50 learners, so transmission is part of the work rather than an afterthought.

A decision made without a written trace is a context debt. That is why every non obvious choice is recorded, with its context and the alternatives that were set aside.

Why incremental migration rather than a full rewrite

A full rewrite looks attractive on paper. In practice it means reproducing years of business rules from documentation that does not exist, while the old application keeps evolving. The new project runs behind the old one and the switchover keeps being postponed.

Incremental migration takes the existing system as its starting point. You see production results early, you keep control of the budget, and you can pause between batches if your business requires it. On applications with real users, it is the only approach that leaves you room to manoeuvre.

Working with a freelance Symfony developer in Réunion

I have seven years of experience on production applications. Around Saint-Denis and the north of the island I travel for scoping meetings and sensitive phases. Otherwise, and for mainland clients, I work remotely with regular check-ins and direct visibility on progress.

You deal with the person who writes the code. No sales layer, no relay: technical questions get answered the day you ask them.

Frequently asked questions

How long does a PHP 8 migration take?: It depends heavily on the tool being audited: code size, number of abandoned dependencies, whether tests exist. As a rough guide, the audit itself takes from 3 to several weeks depending on these factors. I give a precise range for the migration itself once the audit is done, never before.
Do we have to rewrite everything?: Almost never. A full rewrite makes sense on narrow scopes, for example a module whose logic has become unreadable or whose business need has changed. Everything else gets migrated. Your code holds years of business decisions, and discarding them means paying for them twice.
What happens to my business logic?: It is identified during the audit, isolated, tested, then moved. This is the most delicate part of any migration: those rules are rarely documented and often scattered. I extract them and cover them with tests before changing anything, so the observed behaviour stays the same after the switch.
Will my application go offline during the migration?: No, that is the point of working in batches. The application stays live throughout. Switchovers that need a maintenance window are announced in advance, scheduled in a slot you pick, and backed by a tested rollback procedure.
Can we keep developing the application during the migration?: Yes, with one trade-off. Fixes and urgent changes go through, but new features belong on the migrated part rather than the old one, otherwise you pay for the same work twice. We set that rule during scoping.
How do I know whether my application is worth migrating?: That is exactly what a legacy PHP code audit answers. It compares the cost of migrating against keeping things as they are and against replacing the application with an off-the-shelf product. Sometimes the conclusion is not to migrate, and I will tell you so.
Do you only work in Réunion Island?: No. I am based in Saint-Denis and travel across the island for on site work, and I work remotely for clients in mainland France. Migration work suits remote collaboration well: the work happens in the code, with regular checkpoints and direct access to progress.

Let us talk about your application

If you are hesitating, start with the audit. You will know what your code contains, what keeping it as is costs you, and what the migration really involves. No commitment to a rewrite is needed to have that conversation. Book a first call. Tell me about your application, its PHP version and what worries you, and I will tell you on that call whether I am the right person for the job.

Book a slot Send a message