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
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
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.
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
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.
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.
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 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.
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
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.