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.
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.
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.
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.
The operations in order, an estimated duration for each, and the decision points where we deliberately say carry on or go back.
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.
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.
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.
Checksums, record counts and samples on the figures that matter: open receivables, customer balances, stock levels on the day of the switch.
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.
Data volume, dependencies, flows, and above all the interruption you can tolerate: whether the warehouse works on Saturdays changes the entire plan.
A complete run on a copy, every operation timed, producing the list of corrections the scripts need before the real date.
Inside the agreed window, following the rehearsed script, with a single point of contact online from the first step to the last.
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.
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.
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.
Message received
An answer follows inside one working day. Report an outage that is stopping people working and it moves ahead of everything else.
Nothing here under that name. Check the spelling, or simply choose the nearest large city instead. Since every engagement runs remotely, whichever you pick changes nothing about what we do for you.