Inventory
The components in scope, their dependencies, data locations, and the integrations, reports and overnight scripts will break once the database address changes.
Success is won long before cut-over night: the switch itself is short compared with the groundwork behind it.
The components in scope, their dependencies, data locations, and the integrations, reports and overnight scripts will break once the database address changes.
Steps in order, an estimated duration for each and decision points where we deliberately choose to carry on or roll back.
Mapping types, character encodings and structures, for example from Firebird or an old MS SQL instance to PostgreSQL. Polish characters stored in Windows-1250 in legacy databases are a classic trap.
A full migration of a data copy on a test environment, stopwatch in hand. Run one nearly always turns up something unexpected; run two seldom does.
Written and rehearsed steps to restore the old system should a serious issue appear after switchover.
Checksums, row totals and sampling of critical figures: unpaid receivables, contractor balances and stock levels as at the cut-over date.
Preparation time depends on data volume and the number of dependencies. The switchover is usually planned for a weekend, and its length becomes clear once the trial run is done.
Size of the data, linked systems and the longest outage your operations can tolerate, such as whether the warehouse works on Saturdays.
An end-to-end pass over a copy, timing every step and producing a list of script fixes.
Within the approved window, by the practised runbook, with a single named engineer online throughout.
For an agreed period we watch the system closely, while the old one stays available for comparison and read access.
Do not switch the old system off the day after migration. Leave it running, or at least readable, for a few weeks. Something that did not come across, or came across wrong, nearly always surfaces. Remember too that accounting records must be kept for years, and update your record of processing activities if personal data has changed location.
Only the dress rehearsal gives a firm figure, because it measures timing on your real data. The cut-over is usually planned to start on Friday evening so everything is running by Monday morning.
For some systems, yes: through live data replication and a brief cut-over at the end. It is more expensive and complex, so it makes sense where even an hour offline means real losses, such as a busy online shop. Most companies manage fine with a weekend.
For migrating data, usually not: we work with the database itself and rebuild the logic from the data and from talking to users. It is trickier if you want to keep developing the old program. Then it is worth first establishing with a lawyer who holds the rights, and it often turns out that writing a new module is the sensible route.
Yes, that is a common choice. We choose the data centre region with you so that it matches your GDPR documentation, and you add the cloud provider to your records as a processor.
Describe the source, the destination and the outage you could live with. We will begin with a dress rehearsal on a copy of your data.
Your enquiry has reached us
You will hear back within one working day, and if you have reported an outage that is holding up work, it goes to the front of the queue.
No match for that name. Try a different spelling or pick a bigger town nearby - all our support is delivered online, so your choice has no effect on the service.