When a cloud service goes down, or a vendor disappears

Outages are normal, not rare

Large cloud platforms are generally reliable, but they do have incidents: a faulty update, a networking problem in one region, a sign-in service failing for a few hours. Because millions of businesses share the same platform, an outage often makes the news. For an affected office, the effect is the same as the server failing, except you cannot walk to the cupboard and restart it. Many apparent cloud outages are local. The office fibre is down, a router has failed, a laptop's sync client has stuck or one user's account is locked. Knowing how to tell the difference quickly saves a lot of wasted time and frustration.

Know which services matter most

List your cloud services and rank them by impact. Which ones stop work immediately if they are unavailable for an hour? For many offices that is email and Teams, the main file platform and the system that runs the core business, such as a practice manager, job system or point of sale. Which can wait a day without serious harm, such as the marketing platform or the survey tool? For each critical service, note where its status page is, how the vendor communicates incidents and who in your business should be told. Bookmark status pages in one shared place so nobody has to search during a stressful moment.

Plan for a few hours without it

Decide in advance how staff will keep working through a short outage. Files synced to laptops can be opened and edited offline and will sync later, so make sure the most important folders are set to stay available on devices. Keep an up-to-date contact list for staff, key clients and suppliers somewhere outside the main email system, such as on phones or printed. Agree an alternative way for the team to talk, like a group text, if Teams or Slack is down.

For the core business system, find out whether it has an offline mode or a manual fallback. A clinic might print the next day's appointments each evening. A retailer might know how to take card payments on a standalone terminal. A trades business might keep job sheets available on technicians' phones.

Check the local causes first

When a service seems down, check whether other websites work, whether colleagues have the same problem and whether the vendor's status page reports an incident. If only your office is affected, the cause is likely the internet connection, the firewall or Wi-Fi. If only one person is affected, it is probably their device or account. A backup internet connection, such as a 4G or 5G router that takes over when fibre fails, removes the most common cause of whole-office outages. Test it a few times a year, because a backup that has never been tried has a habit of failing on the day.

When a vendor closes or changes

Smaller software companies are sometimes acquired, merged into another product or closed. Usually there is notice, but the timeline can be short. Larger vendors also retire products and features. In each case you need to get your data out in a usable form and move to an alternative before access ends.

Reduce that risk by knowing how to export from each important system and testing it occasionally. Keep an independent backup of key data where practical, such as a regular export from the CRM or a third-party backup of Microsoft 365 or Google Workspace. Watch for signs of trouble, such as stalled development, slower support or a sudden change in terms.

Check your contracts as well. Many standard terms say how long you will have to retrieve data after a service ends and in what format it will be provided. If a system holds records you must keep for several years, such as financial or client files, make sure you will still be able to read them after the product is gone, not just download a file nobody can open.

Write it down in one page

Pull this together into a one-page cloud continuity plan: critical services, status pages, offline fallbacks, communication alternatives, export methods and who decides what. Share it with key staff and review it yearly or when you add a major system. It does not need to be elaborate to be useful; what matters is that nobody is working it out from scratch during an outage.

After any real outage, spend ten minutes reviewing what happened. Did people know where to look? Did the fallback work? Small adjustments after each event steadily improve how well the business copes next time. Include the plan in new staff induction too. A two-minute explanation of where the status pages are bookmarked, how to work on synced files offline and who to tell when something stops working means the next outage is met calmly by people who know what to do, rather than by a queue of staff asking the same question.