Nonprofit Website Handover Planning | Ops Director Guide

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

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.

Q1: What is website handover planning for nonprofits?

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.

Q2: What should a nonprofit website handover document include?

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.

Q3: When should a nonprofit start website handover planning before a rebuild?

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.

Q4: What is a content audit in the context of website handover?

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.

Q5: How should a nonprofit manage content migration during a website handover?

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.

Q6: What credentials need to be transferred during a website handover?

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.

Q7: What training is needed during a nonprofit website handover?

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.

Q8: How does a website handover differ when changing agencies versus changing internal staff?

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.

Q9: What are the most common failures in nonprofit website handovers?

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.

Q10: What role should the operations director play in website handover planning?

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.