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 provider is gone, whose technology is no longer maintained, or whose code nobody fully understands any more. Rewriting it all at once is the reflex, and the most reliable way to fail: for eighteen months nothing moves on the business side, and on switchover day you discover the rules everyone had forgotten. We take the other road. The new application is built on its own domain, next to the old one still running, and replaces it only once the tests prove it does everything.

Parity, feature by feature

The new application is built on its own domain, and replaces the old one only once it does everything.

dnsCurrent application

  • check_circleSign-in and permissions
  • check_circleSearch and lists
  • check_circleRecord entry
  • check_circleDocuments and exports
  • check_circleInvoicing
  • check_circleInherited business rules

Switched off: only one truth left

rule

The tests decide

arrow_forward

rocket_launchNew application

  • check_circleSign-in and permissions
  • check_circleSearch and lists
  • check_circleRecord entry
  • check_circleDocuments and exports
  • check_circleInvoicing
  • check_circleInherited business rules
Functional parity100%

groupYour beta users already work on it

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 write the tests before converting

    Current behaviour becomes the oracle, oddities included, since those are usually a forgotten business rule. Those tests are what settles parity, and they are written while we read the old code, not afterwards.

  3. 03

    We open a second project, on a second domain

    Migrating screen by screen forces you to keep the constraints of the old application, and wastes most of the point of the rework. The new version therefore starts on its own technologies, alongside, owing nothing to the old one.

  4. 04

    We converge to parity, under audit

    A conversion loop runs until every test passes, with three audits alongside it: security, performance, code quality. Nothing switches over until functional parity is reached.

  5. 05

    We switch, we cut, then we modernise

    Some of your users move to the new domain as beta testers and confirm it in the field. The old one is then switched off: keeping it « just in case » creates two truths and doubles the maintenance. Only then do we evolve the business side.

What you get

Deliverables

  • check_circleAn inventory of what exists: what is used, what is not, what is risky
  • check_circleThe test suite that pins down current behaviour, and that stays yours
  • check_circleThe new application, at verified parity, on maintained technologies
  • check_circleThe old version switched off, and its documentation archived

The proof

Where we have done it

STS Arbres et Jardins

STS Arbres et Jardins

Since 2026

A one-year-old site built on an abandoned theme, with an American contact page still live. Full rebuild, migration off WordPress, and local pages built on verified facts.

Read the case studyarrow_forward
Gextra

Gextra

Since 2010

Patient referrals, care records, team scheduling, recruitment, billing, mobile apps: a complete business system, sixteen years of rules, thirty sites — and an interface being rebuilt screen by screen without ever stopping the work.

Read the case studyarrow_forward
Gextra Academy

Gextra Academy

Since 2026

The vendor was cutting off access: courses, materials and assessments would have left with the subscription. Everything was recovered, then put back in service on a platform the organisation owns.

Read the case studyarrow_forward
Premium Goods

Premium Goods

Since 2019

An online shop and the internal tool that runs it: stock, orders, suppliers, field work. Modernised progressively, without ever closing.

Read the case studyarrow_forward
Premium Goods — site public

Premium Goods — site public

Since 2018

Vanilla, flavours, tobacco: the same product is not named the same way in Europe and in the United States. The public site handles that, from the copy through to the form.

Read the case studyarrow_forward
Clinalliance — réservation

Clinalliance — réservation

Since 2016

A centre opens its slots, clients book, pay and get their invoice. The service has been running since 2016 and has followed every version of our stack.

Read the case studyarrow_forward
HAY HuaHin

HAY HuaHin

Since 2024

A studio rental in Hua Hin, Thailand. Site rebuilt, hosted, deployed and optimised by us — and it is our own money going into the Google Ads campaigns.

Read the case studyarrow_forward
Notre flotte

Notre flotte

Since 2010

Git, continuous integration, image registry, SSO, DNS, metrics, logs, monitoring: all of it runs on our own machines, on open-source components. Not out of principle — because it holds load better, costs a fraction, and does not stop when a vendor changes its mind.

Read the case studyarrow_forward
Pré-admission patient

Pré-admission patient

Since 2025

Eight steps, eighty-one fields, identity documents to photograph — completed by patients who are often elderly, or by a relative on their behalf. Here accessibility and clarity are not optional: they decide whether the file ever arrives.

Read the case studyarrow_forward

Frequently asked questions

Do we have to stop working during the migration?
No. Your current application keeps running on its domain while the new one is built. The switchover is a date, not an outage, and it only happens once parity is reached.
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 brochure site takes a day. Around twenty pages, a week. A thousand-page business application, a few months. We migrated our own fleet, 45 applications since late May, and the new versions of our three largest client applications are in production.

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.