Service · Bespoke software

System and database migration

The familiar case: a business application written twenty years ago, a database engine nobody supports any more, a server that stopped receiving security fixes and an author who moved on long ago. It works, right up to the day it does not. We move systems like that onto current versions, onto a different database engine, or onto hosting with OVHcloud or Scaleway. With a company still trading there is only one attempt, so most of the work is preparation, and the switch-over itself is done remotely inside an agreed window.

Rehearsal
a full one before the real thing
Window
calculated from measurements
Rollback
written down and proven
Checks
totals and record counts

Where this service reaches

Preparation decides the outcome. The move itself is short next to the work leading up to it, and when it is short, that is exactly the good sign.

Put your scope to an engineer

Inventory

What moves, what depends on it, where the data really sits, and which reports, flows and overnight jobs will stop working the moment the database address changes.

Migration plan

The operations in order, an estimated duration for each, and the decision points where we deliberately say carry on or go back.

Data conversion

Matching types, character encodings and structures. Accents from an old legacy character set coming out as unreadable symbols is a classic, and it gets settled before the switch, not on the Monday after.

Full rehearsal

A complete migration on a copy, in a test environment, stopwatch in hand. The first run almost always turns up surprises; the second one far fewer.

Rollback plan

The steps that bring the old system back into service, written out and practised, for the case where something serious surfaces in the hours after the switch.

Verification

Checksums, record counts and samples on the figures that matter: open receivables, customer balances, stock levels on the day of the switch.

The way an engagement runs

Preparation time depends on the volume and on how many dependencies there are. The switch is usually planned for a weekend, and only the rehearsal reveals how many hours it will take.

01

Assessment

Data volume, dependencies, flows, and above all the interruption you can tolerate: whether the warehouse works on Saturdays changes the entire plan.

02

Full rehearsal

A complete run on a copy, every operation timed, producing the list of corrections the scripts need before the real date.

03

Switch-over

Inside the agreed window, following the rehearsed script, with a single point of contact online from the first step to the last.

04

Watching period

For an agreed stretch of time we keep a close eye on things, and the old system stays readable so doubts can be settled by comparison.

Do not switch the old system off the day after the migration. Leave it readable for a few weeks: something almost always turns up that did not come across, or came across crooked. Remember the accounting records too, whose retention period runs into years, and update your record of processing activities if personal data has changed host or country.

Questions and answers

The number comes out of the rehearsal, because that measures real time on your own volumes; an estimate given beforehand is worth very little. The switch is usually scheduled from Friday evening to Sunday so that Monday morning is ordinary, and you get the hour-by-hour running order before agreeing the date.

For some systems, yes: data is replicated continuously and the switch at the end is very brief. It costs more and is more delicate, so it makes sense where an hour offline genuinely costs money, an online booking service for instance. For most companies a weekend is ample.

For moving the data, seldom: we work on the database itself and reconstruct the rules from the records and from conversations with users. It is more awkward if you wanted to extend the old program. Your lawyer then has to establish what rights your company holds, and writing a fresh module often turns out to be the sensible route.

It is a common choice and the moment is right. We pick the data centre region together, with a provider such as OVHcloud, Scaleway or Clever Cloud, consistent with your GDPR documentation, and the new provider joins your record as a processor. If your sector demands a particular qualification, SecNumCloud among them, that enters the decision from the start.

That is the part migration plans forget most often. Different screens, shortcuts that have vanished, reports that no longer print in the same layout: the first Monday is always rough. So we prepare a note of the visible changes, a short video session for the teams affected and heavier presence during the first days.

Let us plan the migration

Tell us what you want to move, where to, and how much interruption you can accept. We will start with a rehearsal on a copy of your data.

When we are around
Weekdays, 8:00 to 18:00 CET; answers land inside one working day
Talking it through
A call on Teams or Google Meet, whenever writing is not enough

We set strictly necessary cookies only: they keep the site running and remember the city you chose. Nothing here is used for advertising or tracking. More in our privacy policy.