Website Migration Planning for Nonprofits: A Governance Approach

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.

The data confirms what most web professionals already know from experience. According to a 2025 analysis by Numen Technology, only one in ten website migrations result in improved search engine rankings. Nine out of ten cause damage: lost organic traffic, broken links, and wasted investment. In the worst cases, recovery takes well over a year, with the same analysis citing a 523-day average recovery period for migrations that go wrong. 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.

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

Question 1: How long does a nonprofit website migration typically take?

Answer: 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.

Question 2: Will we lose our search rankings during a migration?

Answer: 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.

Question 3: Should we clean up content before or during the migration?

Answer: 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.

Question 4: What are the most common triggers for nonprofit website migrations?

Answer: 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.

Question 5: Why do most website migrations damage search rankings?

Answer: According to Numen Technology’s 2025 analysis, nine out of ten migrations cause damage because they’re planned as technical projects rather than governance projects. Missing redirect maps, dropped pages, misdirected URLs, and delayed sitemap submissions cause lost organic traffic. Recovery averages 523 days when migrations go wrong.

Question 6: What five areas must a governance-led migration plan cover?

Answer: 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.

Question 7: What testing should occur before launching a migrated nonprofit site?

Answer: 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.

Question 8: How do we prevent donation revenue loss during migration?

Answer: 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.

Question 9: Who should be involved in content triage decisions?

Answer: 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.

Question 10: What is a Blueprint Audit for migration planning?

Answer: 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.

‍