Changing your Payload agency without rebuilding your website: a handover checklist

A Payload website that works can change agency and keep running. The code, the database and the uploaded files stay where they are, and the new partner learns the site before it changes anything. The move is safest when ownership, access and the site’s dependencies are settled early, while the outgoing agency can still answer questions.

This guide is for the person who looks after the website on the business side, in marketing, digital or operations. The checklist works the same for a multi-site platform and for a smaller corporate site.

WAYF is an official Payload partner, and taking over existing Payload sites is part of our work on large, complex websites. We have an interest in this question, and the checklist is written so that you can run it with any partner.

Keep the site when it does its job

If the website does its job and the trouble is the working relationship, a new partner can fix it without touching the site’s architecture. That covers releases that take weeks, questions that go unanswered, a backlog that does not move, and a team on the agency side that has changed.

Keeping the site makes sense when the content model still fits the way editors work, the integrations do what the business needs, and the site runs on Payload 3, the current major version, or can be brought onto it. When this was written, Payload 3.91.0, released on 15 October 2026, was the latest stable release and Payload 4 was in beta.

Rebuilding part of the site is worth discussing when the review finds a specific problem. A custom plugin may have to be rewritten before Payload can be upgraded. The frontend may run on a framework version that no longer receives security fixes, or the content model may be unable to carry a requirement the business has committed to. Each of those is a finding with evidence behind it, and the fix is scoped to that part of the site.

Three pieces of work, priced separately

A takeover divides into three kinds of work, and each needs its own scope and price.

• Takeover assessment. A fixed piece of work at the start: a read-only review of the code, hosting, content and integrations, a recovery check on a copy of the site, and a written report with risks and recommendations. The report is yours to keep, whichever partner does the work after it.
• Maintenance and support. Recurring work that keeps the site safe and running: dependency and security updates, upgrades within Payload’s current major version, monitoring, backups and incident response. Its terms, response times included, are set after the assessment, once the partner knows what it is supporting.
• Ongoing improvements. New features, design changes and integration work, planned as a backlog in priority order.

Keeping support apart from improvements means urgent fixes cannot quietly use up the improvement budget. WAYF’s audit and ongoing retainer runs planned scope, support and ad-hoc requests on separate tracks for that reason. The prices for support and improvements depend on what the assessment finds, so a figure quoted before it has nothing to rest on.

Start with read-only access

The review needs to see the site without being able to change it. To begin, it needs read access to the code repository, where the site’s code and its history live, a view of the hosting and deployment settings, read access to the analytics, and a CMS account with the least access the site’s roles allow. On Payload, what each role may do is defined in code, in the access control functions of the site’s configuration, so the reviewer can read it in the repository before anyone signs in. Building field-level RBAC in Payload CMS shows what those rules look like.

Production passwords, API keys and other secrets move later, once the new partner is responsible for the site. Send them through a password manager’s sharing feature or the hosting platform’s own team access. Email and chat history can retain copies of secrets, so leave them out of the transfer. After the handover, the new partner changes the credentials the outgoing agency held, in a planned order, and tests each integration once the new ones are in place.

The handover checklist

Use it twice: on the first call, to see which items you can answer today, and during the read-only review, to record the evidence. The owner is whoever can usually provide the item, and the output is what the review writes down.

Item	Owner	Evidence	Output
Accounts and ownership. The code repository, hosting and domain decide who can change the site and keep it online.	You as account owner; the outgoing agency as admin	Who owns and pays for each account, the admin lists, and the contract clause on who owns the code	An account map with an owner for each
Versions and custom code. They decide which upgrades and security fixes apply.	The repository	Payload and frontend versions in the lockfile, the file that pins exact versions, plus custom plugins, checked against Payload’s releases and security advisories	Versions, open advisories, risky dependencies, the upgrade path
CMS roles. They decide who can publish and change settings.	Your content lead; the repository	The access control functions in the Payload configuration and the current user list	A role matrix and the accounts to remove
Content, uploads and backups. A backup nobody has restored is untested.	The outgoing agency; the hosting account	Where the database and uploaded files live, the backup schedule, and one restore into a separate environment	A data map and a recovery record
Integrations. A broken form or CRM sync can lose enquiries without showing an error.	Marketing operations; the outgoing agency	Each CRM, search and email integration, the account it runs under, and what happens when it fails	Integrations with their failure behaviour
Secrets. API keys and passwords outlast the contract.	The outgoing agency; your IT team	Each secret listed by name, without its value, with who holds it and how it will be transferred	A transfer plan and the order for changing each one
Monitoring and releases. They decide who hears about an outage and how a fix goes live.	The outgoing agency; your content team	Alerts and who receives them, the staging environment, the release steps including database migrations, and open defects	Monitoring gaps, written release steps, a defect list
Analytics baselines. They show whether the change affected traffic or enquiries.	Your marketing team	Access to GA4, PostHog or other analytics and to Search Console, with a dated export of recent complete months	A baseline saved with its dates

Payload’s deployment documentation lists a database, file storage, an email provider and a CDN as what most Payload projects need besides the application, which makes a useful cross-check for the account map. If the site stores uploads on its server, check that the host keeps files across restarts; Payload’s documentation warns that some hosts do not and points to cloud storage instead. Its migration guide recommends running database migrations before the production build, which is one of the release steps to confirm.

An illustrative first month

This is an example sequence for a site that keeps its code and hosting. The order and the length change with what the review finds.

1. Week one: the read-only review. It starts once read access is in place and nobody on the new side can write to production. It produces the completed checklist and a first list of risks.
2. Week two: the recovery check. The latest database and upload backups are restored into a separate environment. The check passes when the restored site opens and a sample of pages, documents and images matches production. It produces a recovery record, including anything the backups did not hold. If the review found no usable backup, this moves to the first week, ahead of everything else.
3. Week three: a first release. One small, low-risk change goes through the release process, with the outgoing agency available if they agreed to stay on, or against the written release steps if not. It passes when the change reaches production and the rollback path, including any database-migration limits, is documented. It produces release steps that have been tested.
4. Week four: terms and backlog. It passes when the support scope and response times are agreed in writing and the credentials have been transferred and changed. It produces the assessment report, the support scope and an improvement backlog in priority order, with the evidence for any part of the site the review recommends rebuilding.

When the outgoing agency helps, and when it cannot

The easiest handover has the outgoing agency on a call. They walk through the repository, the hosting and the release steps, answer the questions the review raises, and stay available for the first release. Agree that time with them in writing before the contract ends, as part of closing it.

Where documentation is thin, the site still carries most of the record. A Payload site’s content model and access rules are code in the repository, and the commit history shows how they changed. The hosting settings name the environment variables the site needs, and the database holds the content. A reviewer can rebuild a working map from those. A decision nobody wrote down stays with the people who made it, so the questions for the outgoing agency come first. The bus factor audit covers the same risk when the knowledge sits with your own engineers.

If access to the repository or to an account is withheld, the contract decides who owns what, and that conversation belongs to the people who signed it. Payload’s MIT licence and your own database and storage keep the site portable once access is settled; our guide to migrating off Payload sets out what you hold.

Questions for the first call

These are questions a marketing or operations lead can answer, or find out, before speaking to a new partner:

• Who owns the code repository, the hosting account and the domain, and who pays for each?
• Which Payload version does the site run, and when was it last upgraded?
• How does a change reach the live site, and who can make one?
• What breaks most often, and how do you find out when it does?
• Which integrations matter most: forms, CRM, search, email?
• What does the current agency do each month, and what is waiting in the backlog?
• Which analytics and Search Console properties exist, and who can read them?
• What should be different with a new partner?

A responsible partner will not give you three numbers on that call: the cost of fixing defects nobody has found, a date for the next major Payload upgrade, or guaranteed response times before monitoring is in place. Those come after the review, once there is something to base them on.

FAQ

1. Do we need to rebuild our Payload website to change agency?

   Not by default. The code, the database and the uploaded files can move to a new partner as they are, provided you own or control the accounts that hold them. Rebuilding part of the site is worth discussing when the review finds a specific problem, such as a custom plugin that has to be rewritten before Payload can be upgraded.

2. What access does a new agency need to review a Payload site?

   Read access first: the code repository, a view of the hosting and deployment settings, the analytics accounts, and a CMS account with the least access the site's roles allow. Production passwords and API keys move later, once the new partner is responsible for the site, through a password manager or the hosting platform's own team access and never by email.

3. What can a new agency not promise before reviewing the site?

   A price for fixing defects nobody has found yet, a date for the next major Payload upgrade, or response times for incidents before monitoring is in place. Those come after the review, once there is something to base them on.

Sources

• Payload documentation, read 19 October 2026: Production deployment (what a deployment needs, the secret, access control, the database and file storage) and Database migrations
• Payload on GitHub, read 19 October 2026: Releases, with 3.91.0 published on 15 October 2026 as the latest stable release and 4.0.0-beta.2 as a prerelease, and Security advisories