Sanity CMS project handover checklist: what you should receive

A good Sanity CMS project handover checklist answers one question: if your developer vanished tomorrow, could you or the next person keep the site running? Most handovers I see skip half the list, and the gaps only show up months later when a key expires or someone needs to be added to an account.

This is written for the person receiving the site: founders, marketing leads, agency owners. You do not need to understand the code to check these items. You need to confirm each one exists and that your name is on it.

Ownership comes first

Everything else on this list is recoverable. Ownership is not, or at least not without an awkward conversation. Before launch, verify these accounts sit under your organization, not the developer's personal login.

• Sanity project and organization. The project should belong to an organization your company created. At least two people on your side should have the administrator role. The developer stays on as a collaborator, which you can remove in a minute.
• Vercel team. The production deployment should live in a team your company owns, with billing on your card. If the developer deployed from a personal account and promised to transfer it later, put a date on that transfer. A personal hobby account is also not meant for commercial use, so this matters beyond convenience.
• Git repository. The code should be in a GitHub, GitLab, or Bitbucket organization you own, or at minimum you should be an owner of the repository. A zip file by email is not a handover.
• Domain and DNS. The registrar login should be yours. Ask where DNS is managed and who can change records.
• Third-party services. Search, email, analytics, video, form handling. Each one should be a named account with an owner on your side.

A simple test: log in to each of these yourself, on your own device, while the developer is not on the call. If you can see billing and members, you own it.

Environment variables and secrets

A Next.js site talks to Sanity and other services through environment variables. If nobody documents them, a rebuild on a new host fails with errors that look mysterious. Ask for a list with three columns: the variable name, what it does, and where its value is issued.

A typical list for a Sanity + Next.js site looks like this:

The real names will differ by build, and there may be more for search or email. What matters is that the document exists, that no secret values are pasted into the README or committed to the repository, and that the values are stored in Vercel project settings where you can see them.

If your site uses tokens, ask who created them. Tokens made under a developer's account can break the day that account is removed. Have them reissued under your organization at handover, then rotate any that were shared during development.

A useful companion is a committed example file with names only and no values:

# .env.example (names only, no real values)
NEXT_PUBLIC_SANITY_PROJECT_ID=
NEXT_PUBLIC_SANITY_DATASET=production
SANITY_API_READ_TOKEN=
SANITY_REVALIDATE_SECRET=

A README a stranger can follow

The README is the cheapest insurance in the project. Read it as if you were hiring the next developer. It should cover:

1. What the project is and the major versions it uses, such as Next.js 16 and Sanity Studio v6.
2. How to install dependencies and run the site and Studio locally.
3. Where the Studio lives, whether embedded in the site or deployed separately, and its URL.
4. How content publishing triggers a site update, including the webhook and revalidation setup.
5. How to deploy, and which branch goes to production.
6. Where the environment variables are documented.
7. Known limitations and anything deliberately left undone.

If you want context on how the build phases lead up to this point, I wrote about what happens in a Sanity project phase by phase. The handover is the last step of that, and it should not be improvised.

Roles and permissions for your editors

Do not give everyone administrator access because it is easier. Set up roles deliberately at handover:

• Administrators: two people, who manage members, tokens, and billing.
• Editors: staff who write and publish content.
• Contributors or viewers: people who draft or review without publishing, depending on your plan.

Check which roles your Sanity plan allows, since custom roles and fine-grained document permissions depend on the plan. Confirm on Sanity's pricing page before you promise a workflow to your team. If you need document-level rules, I covered the setup in Sanity roles and document-level permissions.

Also remove accounts that should not outlast the project: the developer's test users, shared logins, and any former contractors.

Editor training and a content guide

A site nobody can edit comfortably is a failed project, whatever the Lighthouse score. Training should be a live session, recorded, with your actual editors doing real tasks: creating a page, replacing an image, publishing, previewing a draft, and unpublishing something.

Ask for a short written guide that covers your site's specifics, not generic Sanity documentation. It should explain what each page type is for, which fields affect SEO, image requirements, and what to do when a change does not appear on the live site. If editors avoid the Studio after launch, the cause is usually setup rather than the tool, which I explain in why editors avoid the Studio and the fix.

Backup and export

Sanity stores and manages your content, but you should still hold a copy that you control. At handover, ask the developer to run a dataset export with the Sanity CLI, assets included, and deliver the archive file to a location your company owns.

# Run from the Studio project folder
npx sanity dataset export production ./backups/production-handover.tar.gz

Then decide on a schedule. A monthly export is enough for many marketing sites, and busy publishing teams may want weekly. Test the restore path once, in a non-production dataset, so you know the file is usable. A backup nobody has restored is a hope, not a backup.

Monitoring, costs, and the support window

Finish the checklist with the operational facts:

• Monthly costs. A list of every paid service, its current plan, and who is billed. Prices change, so check vendor pages rather than trusting a number in a document. My breakdown of what a Sanity site runs per month gives a realistic frame.
• Alerts. Who is notified if a deployment fails or the site goes down.
• Analytics and search tools. Access to Search Console, analytics, and any performance monitoring.
• Support window. How long the developer fixes bugs from the original build at no charge, and how requests are sent.
• Next steps. A short list of known improvements, with rough priority.

A one-page version to print

Before you pay the final invoice, confirm each of these:

1. Sanity project is in my organization, with two admins on my side.
2. Vercel team and billing are mine.
3. Repository and domain access are mine.
4. Environment variables are documented, with no secrets in the repo.
5. Tokens were reissued under my organization.
6. README tested by someone other than the author.
7. Editors trained, session recorded, written guide delivered.
8. Roles assigned, stale accounts removed.
9. Dataset export delivered and restore tested.
10. Costs, alerts, and support window written down.

If you are scoping a build and want handover included as a fixed deliverable, my Sanity + Next.js site builds start from $4,000 and include this list. Whoever you hire, put the checklist in the contract before work starts, not at the end when your leverage is gone.