Migration 4: If the Server Dies on Monday, What Happens on Tuesday?
The Question Nobody Wants to Answer
Ask yourself this: if the system your organisation relies on every day stopped working tomorrow morning – crashed, corrupted, or refusing to start – what would you do?
Not in theory. In practice. Who would you call? What would you do for the people who need that data today? How long could your organisation function without it?
Most people, when they think it through, do not like the answer.
How Legacy Systems Fail
Legacy database failures are rarely dramatic. More often than not, they develop quietly and then become a crisis all at once.
Hardware fails: the dedicated laptop, the old server, or the machine that was never replaced because the system depended on it
The operating system becomes incompatible: a Windows update breaks something that was holding everything together
The network setup changes: a new router or IT setup means the database that used to work across the internal network no longer connects
A file becomes corrupted: gradual data corruption goes unnoticed until something important is missing
The one person who knew how to fix it is gone: they retire, leave, or are simply unavailable
We have worked with organisations running a critical national database on a Windows 98 virtual machine, not because they wanted to, but because it was the only way to keep an old FoxPro system going. If that virtual machine had failed, it would have created a crisis with no easy answer.
The Backup Problem
Many legacy databases do not have proper backup systems. The data may sit on a single machine with no offsite copy. Or there may be backups, but nobody has ever tested them – and a backup that has never been tested is not really a backup. It is hope.
GDPR also requires organisations to be able to restore data after a loss. If you cannot show that you have a working recovery process, a serious data loss incident may become a notifiable breach.
The Support Problem
Who do you call when it breaks?
In many cases, the honest answer is nobody. The original developer may have moved on or retired. There may be no support contract. The organisation may have been managing small issues internally for years, with staff relying on workarounds and lacking real technical knowledge of the underlying system.
When something goes seriously wrong, there is no one to turn to.
What a Failure Actually Costs
It is easy to think about the cost of migration as the number on a quote. It is often more useful to think about the cost of failure instead.
– Days or weeks of lost operations while the system is down
– Staff time spent manually rebuilding data from paper records or memory
– Emergency IT costs that are expensive and often unsuccessful with truly old systems
– Loss of historical data that cannot be recovered
– A GDPR notifiable breach if personal data is lost or compromised
– Reputational damage with funders, members, and the people your organisation serves
None of those costs appears on a development quote. But they are real, and in many cases, they can be avoided.
What You Can Do Now
If you are not ready to commit to a full migration yet, there are still sensible steps you can take:
– Find out where the database actually lives – which machine, which server, whether backups exist, and when they were last tested
– Identify who, if anyone, would know how to fix it if something went wrong
– Make sure at least one other person in the organisation knows how to access the system and understands the basics
– Get an assessment – an informal conversation with a developer who can review what you have and tell you honestly how vulnerable it is
That last step costs nothing with us. We will look at what you have, give you a straightforward view of the risk, and if a migration makes sense, explain what it would involve.
Ready to Have a Conversation?
If you have read this series and recognised your organisation in it, the next step is simple. Get in touch. We will have a chat, ask a few questions, and give you an honest view of what is involved. No charge. No obligation.
Back to: Legacy Database Migration Series
