When a core system fails: the minimum continuity your operation needs

There's a question almost no small or mid-sized company asks until it has to: if tomorrow the system your operation lives in — the ERP, the CRM, whatever platform runs the day — won't start or won't let anyone in, what can the company still do, and for how long? Taking it seriously doesn't require doom-mongering; it requires the opposite. The decision in this article is cold and very specific: how much risk you accept knowingly, and what minimum you put in place before you need it — so that the answer isn't decided by chance on one bad morning.

The likely failure is boring

When continuity comes up, imaginations jump to fires and cinematic cyberattacks. Reality is usually greyer: an update that breaks something that worked yesterday, a vendor that discontinues the product or changes the terms of service, a payment that doesn't go through and an account that wakes up suspended, the one person who knew the admin password no longer working at the company. None of these failures makes the news. Every one of them stops an operation just the same.

Precisely because they're boring, nobody prepares for them: they're not frightening enough to justify a plan, and too varied to anticipate one by one. The good news is you don't need to predict the specific failure. You need to know what you'd do without the system, whatever the reason it's gone.

A backup that has never been restored is not a backup

Almost every company answers yes to "do you have backups?". The useful questions come after that, and that's where the answers get shaky:

• Backups of what, exactly? The data, yes — but also the configuration, the attached documents, the templates, all the things that took months to get right and that nobody could rebuild from memory?
• Where do they live? If the backup sits with the same vendor that might fail, it isn't a plan B: it's the same plan twice.
• Has anyone ever restored one? Actually restoring — into a separate environment, checking that what comes back is usable for real work — is the only proof that the backup exists in the sense that matters. Until that day, what you have isn't a backup: it's a hope with a backup's name.

If you do only one thing after reading this article, make it that one: ask for a backup to be restored, and look at the result with your own eyes.

The dependencies that never appear in the contract

A system can work perfectly and still have the company trapped. Four dependencies are worth checking, because they're rarely written down anywhere:

• The exit. Can you export your data today, in a format another system could read, without asking permission or paying for an extra service? Don't answer from memory: try it. The gap between "the contract says we can" and "we did it last month" is enormous.
• The keys. Who holds admin access? If it's one person, or an external provider, the company doesn't control its own system: it rents it through an intermediary.
• The memory. How is it configured, and why? If the answer lives in someone's head — inside or outside the company — that head is a single point of failure as real as any server.
• The paper. What does the vendor commit to if the service goes down, and what happens to your data if the relationship ends? Reading it before the problem costs an afternoon; reading it during the problem costs far more.

The operational minimum: deciding what must not stop

Not everything deserves a continuity plan, and pretending otherwise is the fastest way to end up with none. The useful exercise is choosing: which processes have to survive a few days without the system? The list is usually short: invoicing and collecting, fulfilling orders already committed, answering the customers who call.

For each one, two questions: what minimum information would you need outside the system (open orders, contact details, current prices), and how would you keep it reasonably up to date? A periodic export to a spreadsheet isn't elegant, and on a bad morning it's worth its weight in gold. Just as important is deciding what you would not try to sustain in degraded mode: reports, campaigns, everything that can wait. A small, realistic operational minimum gets kept; an ambitious one gets filed away.

A plan that hasn't been tested is a document

The difference between a continuity plan and a document with that title is that the plan has been rehearsed at least once. It doesn't take a textbook drill: one verified restore, one export opened in another system to see what gets lost along the way, a one-hour conversation playing out "it's Monday and nothing starts — who does what?". What an exercise like that uncovers — the missing step, the access nobody had — no document ever will.

And one condition so it doesn't evaporate: someone has to own the matter. Not "IT" in the abstract, but a person with a name who can answer "when was the last backup verified?" without looking around the room. It's exactly the kind of periodic check worth assigning — internally or with outside help — because without an owner it drifts back onto the list of important things that are never urgent.

Five questions to know where you stand

1. If the core system won't start tomorrow, what's the first thing you couldn't do?
2. When was a backup last restored, and who saw the result actually work?
3. Can you export your data today, in a usable format, without depending on the vendor?
4. What does one person — or one provider — know that nobody else does?
5. What would you need exported or printed to get through a few days operating by hand?

Most SMEs don't need a textbook continuity plan with annexes and committees. They need honest answers to these five questions, and two or three habits that keep the answers current. It's one of the cheapest investments in management there is: almost all of the work consists of looking before you have to.