Website Migration Planning for Nonprofits: A Governance Approach
Key takeaways
- A nonprofit website migration is a governance project, not a technical one, and planning it for speed rather than governance is how content is lost and credibility damaged.
- A realistic timeline for a 50 to 200 page site is roughly eight to twelve weeks, moving through inventory and triage, design and build, migration and redirects, testing, and post-launch monitoring.
- Content inventory and triage comes first: every page is categorised to migrate as-is, update, redirect, or retire, with input from communications, programme, and governance leads recorded in one shared source of truth.
- Every URL that has received traffic, been shared, or appears in print needs a 301 redirect, tested before launch, because mis-redirected pages can cause a near-total loss of search visibility.
- A migration not planned for SEO will lose rankings; preserving URL structures, meta data, and heading hierarchy, plus prompt sitemap submission, is what separates a temporary dip from a permanent loss.
- Every integration, donation, CRM, email, analytics, cookie consent, and forms, must be documented, tested, and confirmed working before launch, or revenue and analytics can silently break.
Summary
Nonprofit website migrations are governance projects, not technical ones. Success requires content triage, comprehensive redirect mapping, SEO preservation, integration testing, and stakeholder communication. A realistic timeline is eight to twelve weeks for 50–200 page sites. Compressing this timeline risks broken links, lost search rankings, and damaged institutional credibility. Plan for governance, not speed, to protect organisational assets during transition.
Migrating a nonprofit website from one platform to another is one of the highest-risk projects an organisation can undertake. Not because the technology is complex, although it can be, but because the institutional consequences of getting it wrong are significant and difficult to reverse. Content disappears. Search rankings drop. Donation links break. Redirect chains fail. Stakeholders who bookmarked specific pages find themselves on error screens. And the organisation discovers, weeks after launch, that the migration plan did not account for something critical.
This matches what most web professionals know from experience. Migrations planned as technical projects rather than governance projects routinely cost search visibility: lost organic traffic, broken links, and wasted investment — and recovery takes far longer than the rebuild itself. For a nonprofit that depends on search visibility for donor acquisition, programme referrals, or public accountability, that is not a temporary inconvenience. It is an institutional setback.
Most website migrations are planned as technical projects: move the content, rebuild the design, launch the new site. The ones that succeed are planned as governance projects: identify what the institution needs to preserve, define what is acceptable to lose, assign accountability for every decision, and test everything before a single visitor sees the new site.
| Migration Phase | Timeline (50–200 Pages) | Key Governance Activity | Risk of Compression | Success Metric |
|---|---|---|---|---|
| Content Inventory & Triage | Weeks 1–2 | Categorise every page: migrate as-is, update, redirect, or retire. Document in shared spreadsheet. | Unnecessary content migrated; critical pages overlooked; stakeholder input missing. | Complete inventory signed off by Comms Director and programme leads. |
| Design & Build | Weeks 3–6 | Build new site architecture aligned with triage decisions and governance requirements. | Design proceeds without confirmed content strategy; rework required post-migration. | Design system approved; CMS structure validated against content inventory. |
| Content Migration & Redirect Mapping | Weeks 7–8 | Migrate approved content; implement 301 redirects for every URL with traffic or external links. | Broken URLs; lost SEO equity; donation links fail; stakeholders hit error pages. | 100% redirect map tested; zero 404s on high-traffic pages. |
| Testing & Review | Weeks 9–10 | Verify content accuracy, redirects, integrations, WCAG AA compliance, and mobile functionality. | Errors missed by builders; accessibility failures; forms submit to nowhere; analytics dark. | Independent tester sign-off; all five test areas passed. |
| Launch & Post-Launch Monitoring | Weeks 11–12 | Deploy site; submit sitemap; monitor rankings, broken links, and integration performance. | Ranking dip becomes permanent loss; revenue-losing failures surface weeks after launch. | Sitemap indexed; rankings recover within 4–8 weeks; zero critical integration failures. |
Why nonprofits migrate
The decision to migrate usually comes from one of four triggers. The current platform has become unmaintainable: the WordPress installation is running outdated plugins, the developer who built it has moved on, and nobody on the team can make basic updates without risk of breaking something. The organisation has outgrown the platform: a Squarespace site built for a £200K organisation cannot support the content architecture, CMS structure, and stakeholder journeys required by a £2M organisation. A rebuild vs remediate assessment has concluded that remediation is not cost-effective. Or a specific event, such as a leadership transition or major funding round, has created urgency around institutional credibility that the current site cannot support.
Each of these triggers is valid. The danger is that the urgency of the trigger leads to a migration planned for speed rather than governance. And speed, in website migration, is how content gets lost, links get broken, and institutional credibility gets damaged at exactly the moment it matters most.
What a governance-led migration plan covers
A migration plan that protects institutional interests covers five areas beyond the technical build itself.
The first is content inventory and triage. Before any content moves to the new platform, every page on the current site must be inventoried and categorised: migrate as-is, migrate with updates, redirect to a new location, or retire. This is a content governance exercise, not a technical one. It requires decisions about what the organisation wants to take forward and what it is ready to leave behind. The Communications Director, programme leads, and governance team all have input. The inventory should be documented in a shared spreadsheet that serves as the single source of truth throughout the migration.
The second is redirect mapping. Every URL on the current site that has received traffic, been shared externally, or appears in printed materials needs a 301 redirect to the corresponding page on the new site. This is not optional. Broken URLs mean lost visitors, lost SEO equity, and broken links from external sources (funder websites, partner directories, Google results) that the organisation does not control. The consequences of getting this wrong are severe. A Totally Digital analysis of real migration failures documented cases where mis-redirected URLs and dropped pages caused near-total loss of search visibility, with one organisation losing 99% of its rankings because old URLs were redirected to the wrong destinations or sent to the homepage instead of the correct new pages. Redirect implementation should be tested before the new site goes live, not after.
The third is SEO preservation. A website migration that is not planned for SEO will lose search rankings. This is not a possibility; it is a certainty. The risk can be minimised by maintaining URL structures where possible, implementing redirects for every changed URL, preserving meta titles and descriptions, maintaining the heading hierarchy, and submitting an updated sitemap to Google Search Console immediately after launch. Even with perfect execution, a temporary ranking dip is normal. What separates a recoverable dip from a permanent loss is the quality of the redirect map and the speed of the sitemap submission.
The fourth is integration continuity. The current site has integrations: donation platform, CRM, email marketing, analytics, cookie consent, form handling. Each of these needs to be documented, tested on the new platform, and confirmed working before launch. A donation button that links to a payment page that no longer exists is a revenue-losing failure. A Google Tag Manager container that was not migrated means analytics goes dark on launch day. An email sign-up form that submits to nowhere means every new subscriber is lost.
The fifth is stakeholder communication. A website migration affects every external stakeholder who interacts with the site. Major donors who have the old donation page bookmarked. Programme partners who link to specific resource pages. Funders who reference your governance section in their records. Board members who use the site to monitor the organisation's public presence. The migration plan should include a communication step that notifies key stakeholders of the change and provides updated URLs where relevant.
The timeline mistake
The most common migration failure is timeline compression. The Board or Executive Director sets a launch date based on an external event, such as a campaign launch, annual conference, or funding deadline, and the migration is squeezed into whatever time remains. Content triage gets skipped. Redirect mapping gets abbreviated. Testing gets reduced to "it looks right on my screen." The site launches on time but with broken links, missing content, and integration failures that take weeks to surface.
A realistic migration timeline for a nonprofit website with 50 to 200 pages is 8 to 12 weeks. This includes content inventory (week 1 to 2), design and build (week 3 to 6), content migration and redirect mapping (week 7 to 8), testing and review (week 9 to 10), and launch with post-launch monitoring (week 11 to 12). Compressing this below 8 weeks requires accepting increased risk. The organisation should make that decision consciously, not by default.
Testing before launch
The final testing phase is where most governance failures are caught or missed. Testing should cover five areas at minimum.
Content accuracy: does every migrated page show the correct, current content? Redirect verification: does every old URL redirect to the correct new page? Integration testing: do donation forms, contact forms, email sign-ups, and analytics all function correctly? Accessibility testing: does the new site meet WCAG AA on at least the homepage, donation page, a programme page, and the governance section? Mobile testing: does every critical page work on a phone, not just render but function, including forms and navigation?
Each of these should be tested by someone who was not involved in building the site. The person who built it will not see the errors because they know what the site is supposed to do. A fresh pair of eyes will find what the builder missed.
Frequently asked questions
Eight to twelve weeks for a site with 50 to 200 pages, including content inventory, design, build, migration, redirect mapping, testing, and launch. Larger sites or organisations with complex integrations may need longer. Compressing below eight weeks increases the risk of broken links, missing content, and integration failures.
A temporary ranking dip is normal and expected. With proper redirect mapping, preserved meta data, and a promptly submitted sitemap, rankings typically recover within four to eight weeks. Without redirects, the loss can be permanent. The quality of the redirect map is the single most important factor in SEO preservation during a migration.
Before. The content inventory and triage should happen at the start of the project, not during the build. Migrating content to a new platform and then deciding what to keep wastes build time and creates confusion. Decide what moves, what gets updated, what gets redirected, and what gets retired before the first page is built on the new site.
Four primary triggers drive migrations: an unmaintainable current platform with outdated plugins or departed developers, outgrowing the existing platform’s capacity, a rebuild-versus-remediate assessment concluding remediation isn’t cost-effective, or a specific event like leadership transition creating urgency around institutional credibility that the current site cannot support.
Migrations cause damage when they are planned as technical projects rather than governance projects. Missing redirect maps, dropped pages, misdirected URLs, and delayed sitemap submissions all cost organic traffic, and recovery takes far longer than the migration itself.
Content inventory and triage, redirect mapping for every URL with traffic or external links, SEO preservation through maintained metadata and heading hierarchy, integration continuity for donations, CRM, analytics and forms, and stakeholder communication notifying donors, partners, funders, and board members of changes and updated URLs.
Five areas require independent testing: content accuracy on every migrated page, redirect verification for all old URLs, integration testing for donation forms and analytics, WCAG AA accessibility compliance on critical pages, and mobile functionality testing ensuring forms and navigation work on phones, not just render correctly.
Document every integration on the current site before migration begins. Test donation platform connections, payment page links, and form submissions on the new platform before launch. Verify Google Tag Manager containers and analytics tracking are migrated. Confirm email sign-up forms submit correctly. Never assume integrations transfer automatically.
Content triage requires input from the Communications Director, programme leads, and governance team. This is a content governance exercise determining what the organisation wants to take forward and what it’s ready to leave behind. Decisions must be documented in a shared spreadsheet serving as the single source of truth throughout migration.
A Blueprint Audit provides a structured assessment of what works, what fails, and what to prioritise in a new build. It ensures migration decisions are based on evidence rather than assumption, mapping stakeholder priorities, technical bottlenecks, and governance gaps before any platform decision or migration timeline is committed.
