How to Hand Off a WordPress Site to an Agency Without Losing Your Mind

The first time I ran an agency switch for a client, I thought it was going to be a forty-minute job. Send a polite email to the outgoing developer, get a zip of credentials, log in, done. What actually happened was that the outgoing agency had registered the client's domain on a reseller account they refused to release until a disputed invoice was paid, the GA4 property was owned by an ex-employee's personal Gmail, and the client had been logging into WordPress as a "Shop Manager" for three years without realising they had never been promoted to administrator. That switch took fourteen working days and a small legal letter. Every WordPress handover I have run since has begun with the same assumption: nothing is where the client thinks it is.

This guide is the checklist I wish I had been handed in 2017. It is written for the marketing director or founder who has decided, often after months of frustration, to move their WordPress site to a new agency. It will not make the process pleasant, because it cannot, but it will stop the seven things that always get lost from getting lost on your watch.

What credentials do I need from my old WordPress agency?

Before anything else, here is the self-contained answer, because if you are reading this you probably need it in the next email you send. You need a WordPress administrator account in your own name, with super-admin rights if the site is multisite. You need root or owner-level access to the hosting account, not a sub-user invitation, because sub-users can be revoked the moment the agency relationship ends. You need the domain registrar login and the EPP authorisation code, plus confirmation that the domain is unlocked for transfer. You need the Git repository moved or forked into an organisation you control, along with any deployment pipeline credentials. You need every plugin and theme licence key documented, alongside the parent vendor account email and password for each, because the keys themselves are useless when renewal time comes if the account belongs to someone else. You need owner-level access to your Google Search Console property, your Google Analytics 4 property, and your Google Tag Manager container, and you need to verify that ownership is yours rather than merely shared with you. Finally, you need a written inventory of every third-party API key, webhook endpoint, and external service the site depends on, because at least three of them will be living somewhere unobvious.

That paragraph is the whole article in compressed form. The rest of this piece explains why each of those things is harder to get than it sounds, and what to do when the obvious route fails.

The WordPress admin account that is not actually an admin

The most common failure mode in a handover is the one nobody believes until they check. The client logs into WordPress every week to publish blog posts and updates plugins, so they assume they have administrator rights. When you actually inspect the user table, the agency created an admin account under their own email when the site was first built, and the client was given an Editor or Shop Manager role. For five years nobody noticed, because Editors can publish posts and Shop Managers can manage products, and that is what the client did.

The day the agency leaves, the client discovers they cannot install a plugin, cannot change the theme, and cannot create a new admin user for the incoming team. The recovery path depends on how much access you still have. If you have hosting access, the cleanest fix is to SSH in and run a single WP-CLI command that promotes the existing user to administrator. If hosting access is also missing, you can update the wp_users and wp_usermeta tables directly through phpMyAdmin or the host's database tool, changing the meta_value of wp_capabilities to a serialised administrator role. The lesson, however, is to never get into this position. Before you tell the outgoing agency you are leaving, log in and confirm you hold an administrator account in your own name, with your own email, with a password only you know. If you do not, request it as the first item of the offboarding, framed as a routine audit rather than a divorce.

Hosting accounts are owned, not shared

Hosting is the second thing that gets lost, and it is lost in a particularly expensive way. If your monthly invoice for WP Engine, Kinsta, Pressable, SiteGround, or Cloudways comes from your agency rather than directly from the host, you almost certainly do not own the hosting account. You are a sub-user on their account, and the account itself is in their name with their billing details and their multi-factor authentication.

When the relationship ends, three things can happen. The agency transfers the site to a new account in your name, which is the clean outcome and what reputable shops will do without being asked. The agency moves you to direct billing on the existing account, which is acceptable but leaves their fingerprints on your infrastructure. Or the agency simply shuts down the site at the end of the notice period, because from their perspective it is their account and you are no longer paying. I have seen all three. The recovery, if you find yourself in the third scenario, is to contact the host's account ownership team directly with proof of domain ownership and proof that you are the commercial entity behind the site. WP Engine, Kinsta, and the other premium hosts have explicit ownership-dispute processes, but they take days, not hours, and they require documentation. Get this sorted before notice is given, not after.

Domains, DNS, and the EPP code that is held to ransom

The domain itself is a separate fight from hosting, and it is the one that has the highest leverage against you. If your domain is registered on the agency's reseller account at GoDaddy, Namecheap, or 123-reg, they hold a hostage that breaks your email, your website, and any third-party service that uses your domain for verification. The transfer process requires an authorisation code, sometimes called an EPP code or auth-info code, which only the current registrant can generate. If the agency drags their feet on producing it, or claims it requires a final invoice to be settled, you have very little leverage other than dispute resolution through the registrar or, in serious cases, ICANN.

The recovery is procedural and slow. You request the EPP code in writing, you request the domain be unlocked for transfer, and you initiate the transfer at a registrar of your choice. The transfer will take five to seven days during which the domain still resolves, but during which DNS changes propagate slowly. If the agency genuinely refuses, you escalate to the registrar's abuse team with evidence of the commercial relationship. None of this is fun. The way to never have it happen is to register the domain in your own name, on your own registrar account, on day one of any agency engagement, and to grant the agency DNS management access rather than ownership.

Plugin and theme licences are tied to accounts, not sites

This is the area where most handovers quietly bleed money for a year before the client notices. Plugin licences in the WordPress ecosystem are almost always tied to the parent vendor account, not to the site or the licence key. Yoast Premium licences sit inside a MyYoast account; Gravity Forms licences sit inside a Gravity Forms account; Rank Math Pro, WPML, Elementor Pro, WP Rocket, and ACF Pro all work the same way. The licence key in your wp-config.php or plugin settings will keep the plugin functioning until renewal, but on the day of renewal, the charge goes to the agency's card, the renewal email goes to the agency's inbox, and if either party drops the ball the plugin stops receiving security updates.

Each vendor handles transfer slightly differently, and the differences matter. Yoast and Rank Math allow you to transfer a subscription to a new account email through the vendor dashboard. Gravity Forms requires you to either change the account owner email or add a new user to the licensing account. ACF Pro is more relaxed because the licence key itself is portable across sites, but you still need the original purchase email to manage renewals. WPML requires a support ticket with proof of purchase to move ownership. Elementor Pro requires deactivation on the old account before reactivation under the new. WP Rocket handles transfers manually through their support team. The recovery, when you have not done this in advance, is a series of support tickets and proof-of-ownership requests that take a week per vendor. The prevention is a single spreadsheet, maintained from day one, listing every paid plugin, the parent account email, and the renewal date.

The repository, the pipeline, and the part of the codebase nobody mentions

If your site is built properly, there is a Git repository somewhere with the custom theme, custom plugins, and probably a deployment pipeline through Buddy, DeployHQ, GitHub Actions, or Bitbucket Pipelines. If your site is not built properly, the only copy of the code is on the production server, and the agency has been editing it through sFTP for the last three years. Either situation is recoverable, but they are recoverable in different ways.

In the first case, the repository lives in the agency's GitHub or Bitbucket organisation, and you need it forked or transferred into an organisation you control. The deployment pipeline lives on the agency's CI account, and either needs to be rebuilt under your account or pointed at the new repo with new credentials. In the second case, you need to pull the entire wp-content directory down via sFTP and treat it as the source of truth, then create your own repository from it. Be aware that in the second case there will almost certainly be hardcoded API keys, environment-specific paths, and forgotten test code scattered through the codebase. I take it as a rule that any WordPress site that has not been version-controlled has at least one third-party API credential committed somewhere in the theme's functions.php. Search for it before the new agency does.

Google Search Console, GA4, and the verification you do not actually own

Google properties are the trap that catches even careful clients. Your agency set up Google Analytics on day one, used their own Google account to do it, and added you as a user with Edit permissions. From your perspective you can see all your data. From Google's perspective the property belongs to the agency. Search Console is worse, because verification is often through a DNS TXT record or an HTML file the agency placed, both of which can be removed without your knowledge. Tag Manager is the same story, with the additional twist that the container ID is hardcoded into your site, so losing the container means losing every event and conversion you have configured.

The recovery here is non-trivial because Google does not arbitrate ownership disputes, but the process is the same in each case. For Search Console, add yourself as an Owner using a verification method you control, ideally a DNS TXT record on the domain you now own, then remove the agency's verification. For GA4, the property cannot be transferred between accounts, but you can grant a new account Administrator access to the property, then remove the original owner. The data stays. For Tag Manager, you can grant a new Google account Administrator access to the container, then have that account remove the original. None of this works if the only owning account belongs to a person who no longer answers email, which is why this needs to be sorted before the relationship ends, not after.

The third-party integrations nobody documented

The seventh thing that gets lost is the messiest, because it is not one thing. Most WordPress sites of any commercial substance are wired into a constellation of external services. Mailchimp or Klaviyo for email, Stripe or GoCardless for payments, reCAPTCHA for forms, Cloudflare for the CDN, Postmark or SendGrid for transactional email, and a handful of bespoke integrations into the client's CRM, ERP, or booking system. Each of these has an API key, a webhook endpoint, or an OAuth connection, and each of them is sitting somewhere you have probably never looked.

The recovery is investigative. Pull the codebase and search for anything that looks like a key, token, or secret. Check the wp-config.php for defined constants beyond the standard set. Log into every external service the site uses and check who owns the workspace, who created the API key, and where the webhooks are pointed. Cloudflare is a common surprise, because the zone often lives in the agency's Cloudflare dashboard, with full DNS control, and the new agency cannot make changes without ownership transfer. Treat the recovery of third-party integrations as a multi-week task, because something will surface in week four that nobody mentioned in week one.

How WitsCode handles the switch

Most clients come to WitsCode mid-frustration, halfway through a handover that is not going well, with a checklist they downloaded from somewhere and a growing list of things their old agency has not responded to. We run the switch as a single engagement. We audit what you actually have access to, recover what you do not, document the entire stack in a vault you own, and then roll the engagement into a monthly retainer that keeps the site maintained, secure, and up to date without ever putting you back in the position of not knowing where your own infrastructure lives.

If you are looking at the seven categories above and recognising more than two of them, that is the engagement. Get in touch and we will run the handover, end the bleed, and make sure this is the last WordPress migration you ever have to negotiate.