Website Handover Planning: What Operations Directors Need Before a Rebuild
Key takeaways
- A handover without full documentation, credential transfer, editorial training, and a maintenance protocol is not a handover but the start of a new dependency on the original provider.
- Rebuild planning tends to focus on the destination and ignore the exit from the current site, which is where the first unplanned costs and delays accumulate.
- The organisation should own the domain, hosting, CMS admin, analytics, email, payment, design files, and the full code repository, and each should be verified independently of the developer.
- Handover also means capturing informal knowledge, such as why the navigation is structured as it is, the backup process, and what breaks when certain plugins update.
- Request a documented handover package as part of contract close, and treat an uncooperative provider as important information to resolve before, not during, a new project.
- A rebuild is the moment to audit content and decide what to carry forward, update, or retire, since migrating outdated or non-compliant content defeats the purpose.
Summary
Website project handovers are one of the most consequential and most poorly managed transitions in nonprofit digital infrastructure. The handover from the agency or consultant who built the site to the organisation that will maintain it determines whether the investment in the build translates into long-term institutional value or begins deteriorating from day one. A handover that does not include full documentation, credential transfer, editorial training, and a clear maintenance protocol is not a handover at all — it is the beginning of a new dependency on the original provider for information that should have been formally transferred.For nonprofits transitioning away from a current provider — whether due to end of contract, dissatisfaction with the relationship, or a planned platform migration — the handover requirements are even more specific. The organisation needs domain and hosting credentials, analytics access, all third-party integration credentials, documentation of custom code and its purpose, a record of redirects and URL structure decisions, and a clear account of the ongoing maintenance obligations the site requires.This post covers what operations directors and Communications Directors should demand from a website handover and how to structure the process to ensure they receive it: the pre-handover audit that identifies what documentation exists and what needs to be created, the credential transfer process that ensures the organisation has independent access to all critical accounts, the editorial training that gives the communications team the knowledge to maintain the site without ongoing consultancy, and the post-handover review period that catches the problems that almost always emerge in the weeks after a handover is nominally complete.
The decision to rebuild a nonprofit website usually focuses on the destination: what the new site will look like, what platform it will run on, what the new agency will deliver. Almost nobody focuses on the exit from the current site — which is where most rebuild projects accumulate their first unplanned costs, delays, and organisational stress.
What a Handover Actually Involves
A website handover is the transfer of every asset, credential, and piece of institutional knowledge required to operate the site — from whoever currently holds it to whoever will hold it next. In practice this includes: domain registrar credentials, hosting account access, CMS login credentials, SSL certificates, DNS configuration, all source code and design files, third-party integration credentials (email marketing, analytics, payment processors), and documentation of how the site is structured and maintained.
It also includes the informal knowledge that’s never been written down: why the navigation is structured the way it is, what the backup process is, which parts of the site are custom-coded and why, what breaks if you update certain plugins, and what the current developer does regularly that nobody else knows about.
The Assets You Need to Own Before You Start
| Asset | Who Should Own It | How to Verify You Have It |
|---|---|---|
| Domain registration | The organisation | Log in to registrar; check renewal email address |
| Hosting account | The organisation | Log in directly; confirm billing is to org |
| CMS admin credentials | At least 2 staff members | Test login independently of developer |
| SSL certificate | Managed by organisation or new host | Confirm renewal process and responsibility |
| Analytics access | The organisation | Log in to GA4 independently |
| Email marketing integration | The organisation | Confirm list ownership and platform access |
| Payment processor | The organisation | Confirm direct account relationship with processor |
| Design files | The organisation | Receive source files (Figma, Sketch, etc.) |
| Code repository | The organisation | Receive full codebase, not just access to live site |
What to Ask Your Current Provider Before the Project Ends
Most agencies and freelancers will cooperate with a handover — but they won’t volunteer information you don’t ask for. Operations directors should formally request a handover package as part of any contract close, including: all credentials in a documented format, a written summary of the site architecture and any custom development, a list of all third-party services the site depends on with renewal dates and costs, and confirmation of who owns the domain and hosting and how to transfer them.
If a current provider is uncooperative with handover documentation, that is itself important information — and a reason to resolve ownership questions before beginning a new project rather than during it.
The Content Audit Before the Rebuild
A rebuild is the right moment to establish what content is actually serving the organisation — and what has accumulated through years of additions without a clear governance process. Before migrating content to a new platform, conduct a structured audit: what pages exist, what their purpose is, when they were last updated, and whether they should be carried forward, updated, or retired.
This is an operations question as much as a content question. Carrying forward outdated, inaccessible, or compliance-failing content into a new site defeats the purpose of the rebuild.
Procurement: What the Contract Should Specify
Any contract for a website rebuild should specify: intellectual property ownership (all assets created belong to the organisation), delivery of source files and documentation on project completion, the handover process and timeline, post-launch support terms, and what happens if the relationship terminates before the project is complete.
Operations directors reviewing web development contracts should apply the same rigour they would to any other significant supplier agreement. Web agencies are not exempt from standard procurement standards.
Further Reading
- Nonprofit Website RFP Process: How to Select Governance-Ready Consultants
- What Happens to Your Website When Your Lead Developer Leaves
- The Real Cost of Developer Dependency in Nonprofit Websites
- Nonprofit Website Planning Timeline: When to Start Projects
What a Clean Handover Actually Enables
Organisations that handle handover properly before a rebuild describe the transition as something that builds confidence rather than consuming it. The new agency arrives with clear documentation, direct access to all assets, and a content inventory that makes architectural decisions easier. The rebuild starts from a position of organisational clarity rather than institutional archaeology — digging through old emails to find credentials, reverse-engineering how the old site was built, discovering surprises in the codebase that add weeks to the project.
The handover work isn’t glamorous. But it’s the difference between a rebuild that delivers what was promised and one that spends the first month resolving problems that should have been resolved before the contract was signed.
Frequently asked questions
Website handover planning is the process of documenting, organising, and transferring all the knowledge, access, and assets required for a new team, platform, or agency to manage the website effectively. In the context of a rebuild project, it covers what happens to the existing site’s content, credentials, and institutional knowledge. In the context of staff transition, it covers what the incoming team needs to manage the existing site without losing capability or access.
A comprehensive handover document should include: all credentials for hosting, domain, CMS, and third-party integrations; a site map showing all pages and their content owners; a description of the CMS architecture and how content types are structured; documentation of any custom code or integrations; a record of all active vendor relationships with contract terms; a content governance framework showing who is responsible for each section; and a training guide for routine CMS tasks. This document should exist before a transition begins, not be assembled during one.
Handover planning should begin at least six weeks before the new build project starts. This time is used to: conduct a content audit that informs the migration plan, document the current site’s structure and any technical dependencies, ensure all credentials are held organisationally and documented, create a record of what content is current and what needs updating, and establish a migration strategy for content that should carry over to the new site. Handover planning done under time pressure during a live project is consistently the primary source of content migration problems.
A content audit is a systematic review of every page and content item on the current website, assessing: is this content current and accurate, does it need updating before migration, should it be retired rather than migrated, who owns this content and can approve changes, and what format is it in (whether it needs reformatting for the new CMS). A content audit before a handover or rebuild prevents the organisation from migrating outdated, inaccurate, or redundant content to the new platform.
Content migration should be planned in phases: first, identify content that is current and can be migrated as-is; second, identify content that needs updating before migration and assign ownership; third, identify content that should be retired and get sign-off for removal; fourth, identify content gaps that need to be created for the new site. Migration should be managed as a project with defined ownership and deadlines — not as a series of ad-hoc copy-and-paste tasks by whoever is available.
Essential credentials for a complete handover: domain registrar login and renewal details, web hosting account credentials, CMS admin credentials, all email addresses associated with the above accounts, Google Analytics and Search Console access, any social media account credentials linked to the site, third-party integration credentials (payment processors, email marketing platforms, CRM), GTM container access, and credentials for any monitoring tools. All of these should be in the organisation’s name rather than an individual’s personal account before handover begins.
The incoming team needs training in: basic CMS operations (creating and editing pages, uploading media, managing navigation), content governance (who approves what, what the publishing workflow is), platform-specific features relevant to the site’s architecture, third-party integration management (particularly analytics, donation platforms, and email marketing), and escalation processes for issues that require developer support. Training should be documented so new staff can be trained from the record rather than requiring a repeated handover.
Changing agencies requires a complete technical handover — all code, all assets, all documentation, all credentials — because the new agency starts from scratch with the technical layer. Changing internal staff requires a primarily operational handover — how to use the CMS, what the governance framework is, who the vendor contacts are — because the technical layer doesn’t change. Both require comprehensive documentation; they differ in what that documentation must cover.
The most common failures are: credentials that are held in personal rather than organisational accounts, insufficient documentation of custom code or integrations, content that is migrated without being reviewed for accuracy or currency, training that is rushed or incomplete, and vendor relationships that the incoming team doesn’t know exist. Each of these failures costs time and money to resolve after the handover — and some, like lost credentials or undocumented code, can be extremely costly.
The operations director is the appropriate sponsor for website handover planning because it is fundamentally an operational risk management exercise rather than a communications project. The operations director should ensure that: the handover is planned sufficiently in advance, that all vendor contracts are documented and accessible, that the credential audit is completed and credentials are held organisationally, that the handover documentation is complete before any transition begins, and that the risk of access loss is included in the organisation’s operational risk register.
