Website Migration Planning for Nonprofits: A Governance Approach | Socialectric

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.

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

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?

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?

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.

If your organisation is considering a platform migration and needs a clear picture of what works, what fails, and what to prioritise in the new build, a Blueprint Audit provides the structured assessment that ensures migration decisions are based on evidence, not assumption.