Types of Hosting Failure

Hosting crises come in several distinct varieties, each with a different recovery path:

  • Provider insolvency - Your hosting company has ceased trading. Servers may go dark with very little notice, and access to your files, databases, and control panel may be cut off immediately. This has happened to numerous UK hosting providers, particularly smaller resellers.
  • Account suspension - Your account has been suspended, usually for alleged violations of terms of service, non-payment, or because your site has been detected as serving malware. Your files are still on the server but inaccessible.
  • Data centre incident - Fire, flood, power failure, or hardware failure has taken a data centre offline. Even reputable enterprise-grade hosts are not immune - major incidents have caused extended outages for thousands of businesses.
  • Forced migration - Your host has been acquired and is shutting down its legacy platform, leaving you with inadequate notice to migrate and little technical support in the process.
  • Resource limit breach - A traffic spike, a runaway script, or increased usage has pushed your account beyond its resource limits, triggering automatic suspension by an oversold shared hosting provider.

Your First Priority: Secure Your Data

If you still have access to your hosting account - even if the site is down - your absolute first priority is to download a complete backup of everything before you lose access entirely. This means:

  • All website files (public_html or equivalent)
  • All databases (via phpMyAdmin or a database export tool in your control panel)
  • All email accounts and stored messages
  • Any configuration files, SSL certificates, and custom server settings

If you are already locked out, contact your host's support immediately and request an emergency data export. If the company is insolvent, data may be retrievable for a limited window before servers are decommissioned - time is genuinely of the essence.

What If You Have No Backup?

This is unfortunately where many businesses find themselves. They assumed their host was handling backups - but either the host's backup system failed, backups weren't included in their package, or the account was suspended before a backup could be retrieved. All is not necessarily lost. Options include:

  • The Wayback Machine - archive.org can provide cached versions of your public-facing pages. Not a functional website, but a resource for recovering content, copy, and imagery.
  • Google Cache - Search your site on Google and check cached versions of individual pages via the dropdown on each search result.
  • CDN or caching layer - If your site used a CDN such as Cloudflare, cached copies of pages may be retrievable even if the origin server is offline.
  • Local developer backups - If an agency built your site, they may hold a copy of the codebase, even if database content (articles, products, etc.) is not current.
  • Git repositories - If your codebase was version-controlled, a developer repo may hold a recent copy of the theme, custom code, or application layer.

Domain control is separate from hosting. Even if your hosting has completely failed, your domain name is typically registered independently. Ensure you have access to your domain registrar account - this controls where your website "points" and is the key to redirecting to a new host or activating a holding page quickly.

Emergency Migration: What the Process Looks Like

An emergency website migration, done properly, involves the following stages:

  1. Provision a new hosting environment - Selecting and spinning up appropriate hosting for your site's technology stack (PHP, .NET, Node.js, etc.) immediately.
  2. Restore files and databases - Deploying your backup (or reconstructed files) to the new environment.
  3. Configuration and testing - Updating database connection strings, file paths, email settings, and any environment-specific configuration. Testing thoroughly before going live.
  4. DNS cutover - Updating your domain's DNS records to point to the new hosting. DNS propagation typically takes between 15 minutes and 48 hours depending on TTL settings. A skilled team can minimise this window.
  5. SSL certificate installation - Ensuring HTTPS is active and valid on the new environment before going live.
  6. Post-migration monitoring - Confirming the site is fully operational across all pages and functions before standing down.

Choosing a More Resilient Hosting Setup

Once you are back online, the right time to think about hosting resilience is right now - not after the next incident. Warning signs that your current (or future) hosting is inadequate:

  • Your host is a small reseller with no published SLA or uptime guarantee
  • Backups are your responsibility but the process is manual and poorly documented
  • Your hosting is bundled with a legacy web package and has not been reviewed in years
  • You have no idea who to call if the site goes down at 11pm on a Friday
  • There is a single point of failure - one server, one person who manages it, no redundancy

Robust hosting for a business website should include automated daily backups stored off-server, a clearly documented recovery process, and a support team with a meaningful response time commitment.