Build

Legacy migration and code takeover

An application nobody dares touch any more, brought back into shape without stopping the business.

Every company we work with has, somewhere, an application whose supplier has gone, whose technology is no longer maintained, or part of whose code nobody understands any more. A complete rewrite in one go is the reflex — and the most reliable way to fail: for eighteen months nothing moves for the business, and on switchover day you discover the rules you had forgotten. We migrate screen by screen, with the old and new versions coexisting, until there is nothing left to migrate.

The method

How we work

  1. 01

    We take over what exists and make it run

    Before judging, we install and execute. Plenty of supposedly incomprehensible codebases are mostly undocumented — not the same thing, nor the same price.

  2. 02

    We set the oracle: current behaviour is the spec

    The old version is the specification, oddities included — those are usually a forgotten business rule. We compare screen by screen; we do not reinvent along the way.

  3. 03

    We migrate in pieces, never in one block

    Both versions live behind the same address, users move over screen by screen. At every step, rolling back takes minutes.

  4. 04

    We keep the addresses and the data

    Redirects, stable identifiers, history preserved. A migration that loses old links or renumbers records does more damage than it repairs.

  5. 05

    We cut cleanly at the end

    Once everything is migrated, the old system is removed. Leaving both in place “just in case” creates two truths and doubles the maintenance, indefinitely.

What you get

Deliverables

  • check_circleAn inventory of what exists: what is used, what is not, what is risky
  • check_circleThe migration plan in batches, with the order and rollback for each
  • check_circleThe migrated application, behaviour identical and verified screen by screen
  • check_circleThe old version switched off, and its documentation archived

Frequently asked questions

Do we have to stop working during the migration?
No, that is the whole point of migrating in pieces. Your teams keep working, and move over screen by screen. We are currently running several migrations of this kind on applications used every day.
Will you take over code written by someone else?
That is a large part of our work. PHP, Symfony, WordPress, older Node: we take it over, we stabilise it, then we decide together what is worth migrating and what can stay as it is.
How long does it take?
A serious migration takes months, sometimes years on a large application. But the business does not wait for the end: from the first batch you get faster screens that are easier to change.

Let's talk about your project

Thirty minutes is enough to tell whether we are the right fit. We reply within 48 hours, and we say no when it is not for us.