Modernization and consulting

Legacy code modernization

We move your legacy PHP application to a modern architecture without a rewrite, while it keeps running. This is also how we are migrating ONLINEKURUM.

We move PHP applications that have grown over the years to a modern architecture without a rewrite, while they keep running. We apply the same method to our own platform: the legacy PHP core of ONLINEKURUM is moving to Symfony 7.4 and PHP 8.5 step by step. This page explains how we approach a legacy application, the steps we follow and what we hand over at the end. The code sample below shows how a single page changes along the way.

The problem we solve

A legacy PHP application usually still does its job, but every change gets a little harder. The code depends on an old PHP version, security updates are no longer available, there are no automated tests and only a few people know the system. A small fix breaks something in an unexpected place, and the team becomes reluctant to change anything. When support for a PHP version ends, the hosting provider may remove it, and the application can stop working from one day to the next. A rewrite looks tempting. But until the new system is ready, the old one keeps changing, and business rules collected over the years can get lost in the rewrite. We recommend renewing the system piece by piece without taking it offline. After every step there is a working application in production and measurable progress. You see a return on the investment before the project ends.

How we work

  1. Assessment

    We review the code, the database and the server, and write down the risks and priorities.

  2. Safety net

    We capture the critical flows in tests, so it is clear what must not break.

  3. Gradual migration

    Old and new code run side by side for a while, and modules move to the new structure one by one.

  4. Handover

    We hand the work over with documentation, deployment steps and a walkthrough for your team.

siparis.php OrderController.php

- $sonuc = mysql_query("SELECT * FROM siparis WHERE id=" . $_GET['id']);
- $siparis = mysql_fetch_assoc($sonuc);
+ #[Route('/siparis/{id}', methods: ['GET'])]
+ public function show(int $id, OrderRepository $orders): Response
+ {
+     $order = $orders->find($id)
+         ?? throw $this->createNotFoundException();
+
+     return $this->render('pages/order/show.html.twig', [
+         'order' => $order,
+     ]);
+ }
A query open to SQL injection becomes a typed, testable controller. The address stays the same and users notice no difference.

What we deliver

  • A written assessment report with risks and priorities
  • Automated tests that protect the critical flows
  • An application migrated module by module and running on a current PHP version
  • Documentation, deployment steps and a handover to your team
  • A before and after comparison for every migrated module

Frequently asked questions

Would a rewrite not make more sense?

Sometimes it does, but in most cases it is risky and expensive. While the rewrite is in progress the old system keeps changing, and two systems have to be run at once. In a gradual migration every step runs in production and the investment pays off step by step. The assessment report states which path suits you, with the reasons.

Will the system go offline during the migration?

No. Old and new code run side by side for a while, addresses stay the same and your users notice no difference. A module is verified with tests before it moves to the new structure. If a problem appears, that module can be switched back.

Which PHP versions do you migrate from?

We migrate applications written for PHP 5 and PHP 7 to PHP 8. We recommend Symfony as the target architecture. Depending on the structure of the application, getting the code to run on a current PHP version and protecting it with tests can be a separate first step. The assessment report explains this decision.

Can we keep adding features during the migration?

Yes. That is one of the advantages of a gradual migration: the business does not stop. Wherever possible we build new features directly in the new structure, so each new feature reduces the legacy code that still has to move instead of adding to it. If an urgent fix is needed in the legacy code, we make it under the same tests.

How long does the assessment take and what do we get?

The length of the assessment depends on the size of the application and is agreed in writing before it starts. At the end you receive a written report on the state of the code, the database and the server, the risks and the recommended order of migration. The report is useful on its own: you can decide to do the migration with us or with another team.

Let us review your system together

Describe in a few sentences what you want to build. We review your needs and write back with how we can move forward.