White-Label WordPress Code Handover: How to Protect Your Work If a Partnership Ends

What is a white-label WordPress code handover, and when does it happen?

A handover is the moment everything behind a client’s site moves from your partner’s control to yours, or to whoever comes next. Code, credentials, licences, accounts, and the understanding of how it was all put together.

It happens at four moments, and agencies plan for one.

You end it. Notice period, project wrapped, everyone professional about it. This is the version the contract describes.

They end it. They raise their rate, change direction, take an in-house role, or decide agencies are no longer their market. Less comfortable, still orderly.

They go quiet. No notice, no handover window, and the only thing holding it together was a relationship that has stopped replying. This is the expensive one, and it is the one nobody prepares for, because preparing means admitting it could happen.

The client leaves. Your account ends and a new agency asks for everything. Same transfer, except somebody else is now grading your work.

Does owning the code mean you can actually run the site?

No, and the gap between those two things is where agencies lose weeks.

Ownership is a question about rights. Who holds the copyright, what was assigned, what the agreement says about pre-existing work. It is settled in writing, it is worth settling properly, and it is its own subject.

Operability is a different question entirely. Can a developer who has never seen this project get it running, change something, and push it live?

You can win the first completely and fail the second. A zip of code you own outright, that nobody on earth can build, is a legal victory and an operational dead end. Your client does not care which of the two you are holding.

What is missing when you have all the files but cannot deploy?

Five things, over and over.

The build step. A theme shipped with compiled CSS and JavaScript, where the Sass or the source modules were never committed. You have the output. You cannot change it without rebuilding something you do not have.

The environment file. Keys, endpoints, feature flags, all sitting in a `.env` that was correctly kept out of the repository and incorrectly kept nowhere else.

The toolchain version. An unpinned Node version. A Composer dependency resolved to whatever was current in 2023. It built on the machine it was built on, and has not built anywhere since.

The thing running outside WordPress. A cron job on a server nobody mentioned. A scheduled function regenerating the product feed every night, which you find out about when the feed stops.

The decision nobody wrote down. Why the checkout bypasses the normal template. Why that plugin is pinned three versions back. Rediscovering this costs more than the other four combined.

None of it is exotic. All of it survives a handover that looked complete, because the handover was measured by what got sent rather than by what could be run.

And none of it is billable. Reconstructing a deploy process is unpaid work on a site you delivered months ago, arriving in a week you had planned for something else.

What steps should I take to retain access to my custom code if a partnership ends?

Stop treating this as something that happens at the end. Every item below is a decision you make at the start, where it costs nothing, instead of at the finish, where it costs a fortnight.

Where should the WordPress repository live during a white-label partnership?

In your organisation. Your partner joins as a collaborator and leaves as one, and the repository itself never moves.

That matters more than it sounds, because moving a repository later is not a neutral act. On GitHub, transferring a repo from an organisation to a user account drops its read-only collaborators, because a user account cannot grant read-only access. A name collision in the destination blocks the transfer outright. And an organisation can be configured so that ordinary members cannot transfer repositories out, leaving only its owners able to do it, which is a quiet form of lock-in nobody checks for until they are trying to leave.

Check that setting now, while asking is an ordinary question rather than a signal.

Who should own the hosting account, you or your partner?

You, or your client. Not your partner, unless you have read what it takes to undo that.

Managed hosts handle it reasonably well, and reasonably well still means a process. Kinsta, for instance, treats transferring a site and transferring company ownership as separate operations with different consequences, and a site transfer needs the receiving side to have an account and a company set up already. None of that is difficult. All of it takes time, and you will be spending that time on the day you have least of it.

Can changing your domain registrant lock you out of a transfer?

Yes. For sixty days.

ICANN’s transfer policy requires registrars to lock a domain against transfer to another registrar for sixty days following a change to the registrant’s name, organisation or email address. A registrar may let you opt out, but only before the change goes through. Afterwards there is usually nothing left to opt out of.

Which sets a trap. The tidy administrative instinct during a breakup, updating the registrant record to show the right owner, is the one move that can strand the domain exactly when you need to move it. Transfer to the registrar you want first. Correct the registrant details afterwards.

And if the domain sits at a registrar whose login belongs to someone who left eighteen months ago, that is a problem to solve this month rather than during an incident.

Which plugin licences and API keys break when a partnership ends?

Licences are usually the cheaper half. Gravity Forms, for one, lets you change the key on a live site without affecting existing forms or entries, so re-licensing can be an afternoon rather than a rebuild. Policies differ by product, so check the ones you actually run rather than assuming it either way.

The expensive half is the keys nobody wrote down. Payment gateway, shipping, transactional email, the CRM integration built in month three, the maps key now rate-limited against a project you cannot see. Each one is small. Finding all of them while a client waits is not.

Write that inventory while the partnership is healthy. Nobody has ever regretted the twenty minutes.

If you have already built the leak audit from keeping a white-label partnership invisible, this is the same list of assets read for a different purpose. That one asks what each one reveals about your partner. This one asks what stops working when they go.

What does a complete white-label WordPress handover include?

Most handover checklists are lists of things to send. A list invites a partner to tick boxes, and a ticked box tells you nothing about whether the contents work.

Use a test instead.

The handover test: can a new developer deploy without asking anyone?

One afternoon. A developer who has not worked on the project takes a fresh clone, builds it locally, makes a trivial change, and deploys it to staging. They are not allowed to ask the outgoing partner a single question.

Whatever they get stuck on is your handover gap. There is no faster way to find it and no real substitute, because every other method depends on somebody correctly predicting what a stranger will not know.

Run it while the partnership is still working, when the person who can answer is still answering.

What handover documentation do agencies actually use later?

Most of it is written once and never opened again. Three things get opened.

The build and deploy steps, written as commands somebody can paste, not as prose describing a workflow.

The decisions log. Why the checkout bypasses the template, why that plugin is pinned, why the staging database is sanitised the way it is. Short entries, added as they happen. This is the one that saves days.

The credential inventory, meaning a list of what exists and where it lives rather than the credentials themselves. Those belong in a password manager with a shared vault.

An architecture diagram is nice to have. A narrative onboarding document is nice to have. Neither gets opened when something is actually broken.

Best practices for offboarding a white-label WordPress partner securely

The sequence matters more than the checklist, and it is where agencies hurt themselves.

Freeze. No new work, no new branches, a clear date after which the site is stable.

Inventory. Every asset in the register, each with a named holder.

Transfer. Repository, then hosting, then domain, then licences and keys. The repository goes first because it is the one transfer that can fail quietly, as the collaborator and naming rules above show, and you want the time to notice.

Verify. Run the deploy test. This is the step that gets skipped.

Revoke. Only now.

In what order should you revoke a partner’s access?

After you have verified, never before. That is the entire rule and it gets broken constantly, usually by an agency doing the responsible-looking thing in the wrong sequence and locking itself out of its own client’s site.

Within the revocation itself, work backwards from how much you depend on each thing. Client-facing tools and shared inboxes go first, because those carry a discretion cost as well as a security one. Hosting and the repository go last, after a successful deploy from your own account has proved you no longer need them.

The contractual half of this, the deadline for return or destruction of materials and the written confirmation that it happened, belongs in the confidentiality agreement. What a clause cannot do is tell you what order to work in.

What if your white-label partner stops responding?

The version nobody plans for. Assume a fortnight of silence and a client who needs an answer today.

Start with what you already control. If the hosting account is yours, you have the files and the database, and a competent developer can work from a copy of a running site even without a usable build process. That is not a good position. It is a workable one, and it is the entire argument for the hosting decision above.

What the host will do: give you a backup, spin up a staging copy, and in many cases migrate a site to another account. What you should not expect is for them to hand over control of an account in somebody else’s name, whatever you tell them about the circumstances.

What the registrar will do: very little, quickly. Domain disputes are slow by design.

What you are unlikely to get back: build source that was never committed, anything in a private repository you were never a member of, and the reasoning behind the awkward parts of the build. Budget for rediscovering that third one.

There is also a quieter version of the same problem, and it is far more common than disappearance. A partner who knows you cannot leave does not need to go anywhere. They only need to raise the rate at renewal. You will pay it, because the alternative is the fortnight this article has just described. Everything here is the answer to that too.

What happens when the client leaves and takes the site with them?

The handover nobody rehearses, because it arrives as bad news about something else.

Your client moves to another agency and asks for everything. The transfer is the same transfer. What changes is the audience. A partner receiving a messy codebase shrugs and gets on with it. An incoming agency reads it as evidence, writes a paragraph about it in their onboarding notes, and your former client sees that paragraph.

So run the deploy test on your own work before you send it, not on your partner’s. Anything a stranger cannot build is about to be described by a competitor.

Two practical points. Hand over to the client, not to the new agency, unless the client instructs you otherwise in writing, because the relationship and the authority are theirs. And resist the urge to strip things on the way out. Removing a licence the client paid for, or a staging environment they still need, turns a clean exit into the story they tell about you.

How do you run an exit test on a white-label partnership you already have?

Most agencies reading this are not choosing a partner. They are two years into one and have never checked whether leaving is possible.

One week, four moves. Three of them are requests. One you run yourself.

Ask for a fresh clone of the repository, then build it on a machine nobody has touched.

Ask for a current copy of the database, and restore it somewhere you control.

Ask who holds the domain, in writing.

Then, on your own: pick one credential you have never personally used, the mail service or the payment gateway, and confirm you can log in with it today.

The useful result is not the answers. It is how long the three requests take to come back. A partner with good habits returns all of it inside a day, because none of it needs creating first. A partner who needs a fortnight has shown you what a real handover would look like, and shown you while nothing is on fire.

Which white-label WordPress services offer built-in protection if a collaboration ends?

The answer is structural rather than a list of vendors.

A partner working inside your repository, your hosting, your licences and your accounts from the first commit has no handover to perform. There is nothing to transfer because nothing ever moved. They were a collaborator on your infrastructure, and then they were not.

So the question worth asking on a sales call is not “what is your handover process.” Everybody has an answer ready for that. Ask whose accounts the work will live in, and listen for whether the answer is already their default or something being invented while you watch.

The best handover is the one you never have to run.

Do you need a source code escrow for a WordPress project?

Almost certainly not.

Escrow is a real instrument. A third-party agent holds the source and releases it when a trigger fires, typically the supplier’s bankruptcy, discontinuation of the product, or joint written instruction from both parties. It exists because enterprise software buyers cannot see inside their vendor.

It fits a WordPress build badly. The apparatus costs more than it protects at this size, the standard triggers are written for product companies rather than service partners, and suppliers routinely argue about who pays the agent’s fees before anything is signed.

The cheap substitute does most of the work. Keep your own copy, refreshed quarterly, where refreshed means you built it rather than downloaded it. That is escrow without the agent, and it is available to you this afternoon.

Frequently asked questions

Who owns the code in a white-label WordPress project?

Whatever the written assignment says, which is why the assignment clause earns more attention than it usually gets. Without one, the rights can sit with whoever wrote the code rather than with the agency that paid for it, which surprises people who assumed an invoice transferred everything. Ownership and vendor lock-in are a separate subject with their own article.

What tools help manage code ownership and access control for freelance developers?

A private repository under your organisation with the developer added as a collaborator covers most of it, because access becomes something you grant and revoke per person without moving any code. Pair it with a password manager that supports shared vaults, so credentials are issued rather than forwarded over Slack. Avoid any arrangement where your access depends on a personal account doing you a favour.

What should I do if I inherit a WordPress site with no handover at all?

Take a full backup and confirm you can restore it somewhere you control, because everything else depends on holding a copy that is genuinely yours. Then inventory what is actually running: active plugins, scheduled tasks, outbound integrations, and anything that sends email. Expect to rebuild the deploy process rather than recover it, and price that work honestly instead of absorbing it.

What happens to backups and site data when a white-label partnership ends?

Backups usually live with the host, so whoever holds the hosting account holds the history. If the backup schedule runs inside your partner’s account, that history leaves when they do, including the restore points you would want if something broke mid-transition. Take an independent copy before offboarding starts and keep it somewhere neither party controls alone.

How long should a white-label WordPress handover take?

A partnership set up well takes days, because the assets never moved and the work is confirmation rather than transfer. One set up badly takes weeks, and the long pole is almost always rebuilding a deploy process for a codebase nobody can build. Run the deploy test first and scope the rest from whatever it breaks on.