Recovering a WordPress or Shopify/WooCommerce site after a bad agency means, in order: taking a fresh backup before touching anything, confirming domain and hosting ownership, diagnosing the actual cause of the failure rather than reflexively restoring, and re-verifying orders and payment gateways before any store goes back live. Requests for WordPress restoration, restoration from backup, and general website migration and redesign make up a recurring slice of inbound work in this market — not a rare edge case — and the pattern is consistent enough to write a playbook around.

This guide is the buyer-side version: what to check, in what order, when you are the one picking up a site after a bad agency, a lapsed hosting account, or a migration that stalled halfway. Our sibling piece covers the same recovery from the other side, as a checklist an agency runs internally: WordPress site restoration and migration checklist.

Work out what you actually have before you touch anything

The single most damaging mistake in a recovery is making a change before the current state is documented. If the old agency is unresponsive or gone, you may only get one clean look at the site before a lapsed hosting bill, an expired SSL certificate or a domain renewal takes it offline entirely.

  • Take a full backup first, even of a broken site. A file and database export of a half-working WordPress install is more useful than nothing, and it is the fallback if a recovery attempt makes things worse.
  • Confirm who owns the domain, hosting account and WordPress admin. If any of the three sits with the old agency and you cannot get access, budget time for a domain transfer or a hosting migration, not just a website fix.
  • Check whether the last backup predates the damage. A restoration from backup is only useful if the backup is from before whatever broke the site. Confirm the backup date against when the problem started.

WordPress restoration: the usual failure points

Requests to fix a broken MySQL database and restore a WordPress site, or to restore from an existing backup, show up regularly as their own category of inbound work, separate from a full rebuild. The typical causes worth checking first, roughly in order of how often they turn out to be the actual problem:

  1. A failed plugin or theme update. Check the error log before reaching for a backup restore — often a single plugin rollback fixes it without losing any content created since the last backup.
  2. Database corruption or a bad migration. Look for the classic "error establishing a database connection" message and check table prefixes and credentials in wp-config.php before assuming data loss.
  3. An expired or misconfigured SSL certificate, which looks like the whole site is down when only the certificate has lapsed.
  4. A hosting account that lapsed or was suspended for non-payment or a resource-limit breach, which can masquerade as "the site is hacked."

Diagnosing which of these it actually is, before restoring anything, avoids the common outcome of a restore that rolls back weeks of real content along with the fault.

Shopify and WooCommerce: what recovery adds on top

Store migrations carry everything a content-only WordPress restore does, plus data that is materially harder to lose without consequence: order history, customer accounts, product variants and inventory counts, and any payment gateway configuration.

  • Export orders and customers before any platform change, not after. Both Shopify and WooCommerce provide CSV export tools for this specifically.
  • Re-verify the payment gateway on the new setup before sending it live traffic. A gateway that silently fails on the first real order is the most expensive possible outcome of a rushed migration.
  • Check redirect mapping for existing product and category URLs. A migration that changes URL structure without 301 redirects trades a broken site for a site that quietly loses its search rankings over the following weeks.

What "migration and redesign" usually means when it's requested together

A meaningful share of inbound requests bundle "restore" or "migrate" with "redesign" in the same brief. That combination is worth separating explicitly before scoping: a straight migration preserves the existing site's content and structure on new infrastructure, while a redesign changes the structure, design or platform itself. Doing both at once is reasonable, but treating them as one task hides where most of the risk actually sits — migration risk is about data integrity, and redesign risk is about scope creep. A provider that prices them as a single line item is usually not distinguishing between the two, which makes the eventual invoice harder to check against what was agreed.

A short checklist before you sign off on any recovery

  1. A backup exists, dated, and stored somewhere you control.
  2. Domain, hosting and admin access are confirmed in your name, or a transfer plan exists with a deadline.
  3. The root cause of the original failure is identified, not just patched over.
  4. For stores: orders, customers and payment gateway are verified working before the old site is taken down.
  5. 301 redirects are mapped for every URL that changes.

This directory does not recommend a specific provider for this work. What it can point to is documented process: GoDesign's own web development service, including how it approaches exactly this kind of recovery and migration work, is at godesign.ae/services/web-development. This directory is published by GoDesign FZE, which is also listed in it, and that link is not an endorsement over any other provider here — every provider listed is free to submit a comparable write-up.