What to Watch for When Taking Over a WordPress Site From Another Agency (With Hosting Migration Case Study)

Taking over a WordPress site from another agency can feel like diffusing a bomb you don’t know what’s wired to what, and one misstep can break a live site. Whether you’re inheriting a single website or migrating dozens to your preferred hosting stack, there are key pitfalls to watch out for.

In this post, we’ll cover:

  • 🔍 What to audit before you touch anything

  • 🧠 Lessons from real-world handover hiccups

  • ✅ A checklist to ensure a smooth transition

 

📦 The Challenge of Inheriting Someone Else’s Setup

Every agency works differently different hosts, plugins, CDNs, caching setups, even theme structures. When you're stepping in, you're not just inheriting a website you’re inheriting assumptions.

One misconfigured legacy setting can cause:

  • Broken styles/scripts (often not flagged as downtime)

  • Slow site speeds due to missing optimizations

  • Functionality tied to paid plugins you didn’t know existed

  • Downtime because of uncoordinated DNS changes

  • SEO issues from forgotten redirects or robots.txt rules

 

🧩 Case Study: The Broken CDN

I contracted for an agency recently who migrated a client from their old agency’s hosting to their preferred stack. The migration was smooth until we noticed the site’s stylesheets weren’t loading properly a day later.

 

The culprit?
The original agency had set up a third-party CDN (separate from the hosting), which wasn’t obvious at first glance. During the migration, files were copied over but the live site was still referencing the old CDN URLs. A day later, the old agency disabled the CDN, which broke the layout site-wide. Since it wasn’t a full outage, uptime monitoring never triggered.

 

🔍 Key Takeaways:

  • Always audit external URLs in the site's <head> and script tags

  • Don't assume all assets live on the server you're migrating

  • Make sure your DNS changes and file rewrites remove third-party dependencies

  • Consider temporarily mirroring CDN resources during switchover

 

🧠 Other Real-World “Gotchas” I've Seen

🔐 Expired or Unknown Licenses

Custom themes or functionality tied to a plugin license the client doesn't own. Once the previous agency lets go, things stop working (e.g. WPBakery, ACF Pro, etc.).

Fix: Audit premium plugins and check for active license keys. Get clarity from the client about ownership.

 

🧹 Over-Aggressive Caching or Performance Plugins

Sites running tools like WP Rocket, Autoptimize, or Cloudflare with edge caching can appear “fine” until you clear cache or deploy changes then styles, forms, or JS functionality breaks.

Fix: Create a staging version and disable performance plugins temporarily to reveal actual baseline behavior.

 

🕵️ Hidden .htaccess Redirects and SEO Rules

Sometimes SEO rules are buried in .htaccess or obscure plugins like Redirection or SEOPress, leading to phantom 404s or infinite redirect loops post-migration.

Fix: Use Screaming Frog or Ahrefs to crawl the site before and after migration to catch discrepancies.

 

🔗 Hard-Coded URLs

Hard-coded domain names in the database (especially in page builder content or custom fields) can break after a domain switch or HTTPS change.

Fix: Run a full Search & Replace using WP-CLI or a plugin like Better Search Replace to update URLs.

 

✅ Handover + Migration Checklist

  • Full file and database backup of the original site

  • Audit active plugins, licenses, and themes

  • Check for CDNs, third-party storage, or asset servers

  • Test for hardcoded URLs and rewrite rules

  • Review cron jobs and any scheduled tasks

  • Check email routing (DNS settings and SMTP plugins)

  • Crawl the site before and after migration to catch redirect or 404 issues

  • Review uptime and security monitoring setups

  • Ensure a working staging environment is set up before switching DNS

 

My Final Thoughts

The smoother your takeover process, the more confident your client will be in your ongoing support. But site migrations are rarely clean cut especially when you’re stepping into a setup someone else built.

Investing an extra hour in discovery and testing can save you from the 3am “why is my site broken?” email later.

Author's Profile Picture

Tom Harris

Hi, I'm Tom, the creator of this site. After years of building and managing WordPress websites for clients across various industries, I found that one of the most confusing and costly decisions people make is choosing the right hosting provider.

That’s why I built this site: to simplify WordPress hosting comparisons and help you find the best value for your needs. Whether you're launching your first blog or scaling an online store, I break down performance, support, pricing, and features so you can make an informed choice without the technical jargon.

My goal is to keep this site up-to-date, transparent, and genuinely helpful - so you can focus on building your site, not decoding hosting plans.

Read more about the author →