How to Transfer Managed WordPress Licenses (WP Engine, Kinsta) During a Client Handoff

Article image
How to Transfer Managed WordPress Licenses (WP Engine, Kinsta) During a Client Handoff
When building websites for clients, agencies routinely face a critical operational fork in the road at launch: who owns the hosting billing? Many agencies start by placing client sites on their own bulk agency hosting plans. But as maintenance agreements end, or when a client asks for full ownership of their digital assets, you need to execute a clean handoff.

If you're on a premium managed WordPress host like WP Engine or Kinsta, you can't just hand over a control panel password. These environments require a deliberate transfer process to move the site, its environments, and the billing relationship without downtime, broken DNS, or lost licenses.

This guide walks through the current (2026) transfer procedures for both hosts, plus the plugin-license cleanup and documentation steps that keep the handoff from becoming a liability six months later.

1. The Agency Dilemma: Reselling vs. Direct Client Billing Before initiating a transfer, it helps to separate two ownership models:

The Reseller Model. The agency holds the primary billing account with the host. The agency charges the client a marked-up monthly fee that bundles hosting and maintenance. The agency retains legal ownership of the hosting account.

The Direct Billing Model. The client holds the direct relationship with the host, their card is on file, and the agency is granted developer-level access to manage the technical side.

When a client exits a care plan, or when agency policy requires clients to own their own infrastructure, you need to move from the Reseller Model to the Direct Billing Model. Getting this wrong can mean accidental site deletions, accounts suspended over unpaid invoices, or plugin licenses that quietly lapse.

1. The Universal Agency Hosting Transfer Protocol Regardless of host, a clean transfer follows the same sequence:

Preparation and audit – confirm the client has an active email ready to receive the transfer, and document every premium theme/plugin license currently tied to the agency account.
The environment transfer – move the site (and its staging/production/development environments) to the new account.
The billing handoff – shift financial responsibility so the client enters their own payment details.
DNS and domain finalization – update records only if the transfer changes the underlying server IP or nameservers.
Documentation update – log the new ownership status, billing party, and any support PINs or account IDs in your agency's asset tracker.

1. How to Transfer a WP Engine Site to a Client (2026 Update) WP Engine significantly simplified this process in April 2026. Previously, only sites built as "transferable" environments could be moved without contacting support — regular billable sites required a support-assisted "reparent" request. That's no longer the case: WP Engine now allows self-serve transfer of any site, billable or transferable, directly from the User Portal.

What You Need Before Starting
Self-serve transfer requires Owner or Full (with billing) user permissions on both the source and destination accounts. If you only have that access on one side, you and the client will each complete a separate part of the process.

DNS and Migration Considerations
Whether a transfer requires a full server migration (and possibly manual DNS changes) depends on the network type and plan:

If every domain on the site is on WP Engine's Advanced Network or Global Edge Security (GES) network, no DNS update is needed — the transfer completes without touching name servers.
A server migration is triggered if either account is on a premium Core or Enterprise plan (these have dedicated servers), or if the source and destination accounts sit in different datacenter regions.
Sites still on WP Engine's Legacy Network for DNS will need manual DNS updates, and those transfers still go through WP Engine support.
Step-by-Step: Self-Serve Transfer
If you manage both accounts:

From the site's Overview page in the User Portal, click the gear icon and select Transfer site.
Choose To another account I manage and select the destination account from the dropdown.
If a migration is required, you'll be prompted to enable maintenance mode (it auto-deactivates after 10 minutes once migration begins — use a maintenance mode plugin instead if you need it active longer).
Choose a transfer date/time, select which users should retain access on the destination account, and review which product extensions (Smart Plugin Manager, etc.) need to be reactivated there.
Review the summary and click Transfer Site.
If the client owns the destination account and you don't have access to it:

The client toggles on Allow site transfers via transfer code in their Account Settings and sends you the generated code.
From your site's Overview page, click the gear icon, select Transfer site, then To someone else's account via transfer code.
Paste the code and click Find to populate the destination account, then proceed through the same settings and review steps above.
A few limitations worth knowing: Dedicated Development Environments can't be transferred this way, and sandbox sites must first be converted to billable before they're eligible for transfer.

The Legacy Method: Transferable Environments
WP Engine's older "transferable site" workflow — building a site as a password-protected, non-billable environment and handing it off via a transfer code that expires after 30 days — still works, and WP Engine has confirmed it will eventually be deprecated in favor of the self-serve process above. It remains useful for one specific case: building a new site for a client who doesn't have a WP Engine account yet, without it counting against your own plan's site limit. Once the client accepts the transfer, they still need to click Convert to billable site to remove the password protection and go live.

If neither self-serve option fits — for example, you don't have the right permissions on either account — WP Engine support can complete what they call a "reparent" request, which requires the support PIN for both accounts.

1. The Kinsta Client Billing Handoff Kinsta's transfer tool moves a site between "Companies" (its term for billing accounts) in the MyKinsta dashboard, and its scope is broader than a simple ownership change.

What Actually Moves With the Site
When you transfer a site on Kinsta, the following goes with it automatically: SSH/SFTP settings, caching configuration, SSL certificates, domain settings, and any active PHP, Redis, or Premium Staging add-ons. If your DNS is managed through Kinsta, you can choose to move those records along with the site so they don't need to be re-pointed. Kinsta also automatically preserves PHP performance — if your site is using a larger PHP memory pool than the destination company's plan includes by default, Kinsta adds a matching performance add-on so nothing slows down after the move. Any other add-ons not on that list are disabled and would need to be re-enabled by the new owner.

Step-by-Step: Transferring a Site
Get the destination company's ID or email. Company Owners and Administrators can find their own Company ID under Company settings > Billing details. If the client doesn't have a Kinsta account yet, you only need their email — Kinsta will walk them through account creation as part of accepting the transfer.
Initiate the transfer. In MyKinsta, go to Sites, click the kebab (three-dot) menu next to the site, and select Transfer site. Enter the client's Company ID or email, optionally recommend a hosting plan, and — if DNS is hosted on Kinsta — select the domain(s) to move under Transfer domain.
Confirm. Type the site name to confirm and click Transfer site. The site now shows as Pending transfer in your account.
Client accepts. The client receives an email prompting them to log in (or create an account), then Commit transfer and Accept transfer in MyKinsta. If the destination plan doesn't have room for the site, they'll be prompted to upgrade first.
One detail agencies often miss: if the destination company doesn't accept the transfer within 72 hours, the request is automatically canceled and has to be reinitiated. Build that window into your offboarding timeline so a client's inbox delay doesn't stall the handoff. Until they accept, you can revoke the transfer at any time from Sites > [site name] > Info.

Once the client accepts, the site leaves your plan's quota and they assume full financial responsibility going forward.

1. Migrating Managed WordPress Licenses Securely Transferring the host is only half the job. You're also moving an ecosystem of premium themes, plugins, and license keys — and this is where handoffs quietly go wrong.

The License Disconnect Risk
Agencies often build sites using their own developer licenses for plugins like WP Rocket, Advanced Custom Fields (ACF) Pro, or Gravity Forms. If those agency-owned licenses stay active on a site after billing transfers to the client, the agency is still on the hook for that plugin's updates and support — even after the client stops paying for maintenance.

The Clean Handoff Protocol
Audit premium licenses. Before transferring the host, list every premium plugin installed and note which license key it's using.
Set a grace period. Tell the client your agency licenses will remain active for a defined window (commonly 1–2 weeks) post-transfer, purely to keep the site stable while the swap happens — not indefinitely.
Have the client procure their own keys. Point them to purchase pages for each essential plugin.
Swap the keys. Once the client has their own license, log into the (now-transferred) site, deactivate your agency's key, and activate theirs.
Remove agency-specific tooling. If the maintenance contract has ended, delete agency management plugins (ManageWP or MainWP worker plugins, for example) so the agency no longer has a technical foothold on a site it's not being paid to maintain.

1. Documenting the Handoff The most common failure in a hosting transfer isn't technical — it's a documentation gap. A junior team member two years from now shouldn't have to guess whether a client's site is still on the agency's WP Engine plan or was handed off to their own Kinsta account back in 2026.

This is where keeping the transfer logged in an asset tracker like InstaRenewal earns its keep:

Update the billing status. Flip the hosting asset's record from "Agency-billed" to "Client-billed" so accounting doesn't invoice the client for hosting they now pay for directly.
Record the new account reference. Log the client's new Kinsta Company ID or WP Engine account/support PIN in the asset's notes so future team members can find it without digging through old emails.
Reassign plugin license ownership. If you swapped keys as part of the handoff, update the tracker to show the client now owns the ACF Pro or Gravity Forms license, along with its renewal date.
Keep renewal alerts active where it helps the relationship. Even after billing moves to the client, keeping their domain and SSL renewal dates tracked means you can flag an upcoming expiration before it becomes a crisis — which costs you nothing and keeps the door open for future work.
Worth being precise about scope here: a tracker like InstaRenewal is a record of what exists and when it renews — it's not a credentials vault or a live uptime monitor. It won't store the client's WP Engine password or alert you if their site goes down; it tracks the ownership record and the renewal clock so nothing falls through the cracks after the handoff.

1. Conclusion Transferring a site off WP Engine or Kinsta to a client's own billing shouldn't be a stressful event. Both hosts have invested in making the financial handoff itself fast — WP Engine's self-serve transfer now works for any site, and Kinsta's tool moves DNS, SSL, and performance settings automatically.

The part that still depends entirely on your agency's discipline is everything around the transfer: untangling premium plugin licenses from your accounts, giving the client a clear grace period instead of an abrupt cutoff, and logging the new ownership record somewhere your team will actually find it later. Get those three right, and the technical transfer becomes the easy part.