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 migration runs in five phases, in order: inventory and triage, design and build, migration and redirects, testing, and post-launch monitoring. Most run six to twelve weeks from the point content and approvals are signed off, but the sequence is what protects the site, not the calendar.
- 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, 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. Dropping or compressing a phase to meet a launch date risks broken links, lost search rankings, and damaged institutional credibility. Plan for governance, not speed, to protect organisational assets during transition.
Moving a nonprofit website to a new platform is one of the riskiest projects an organisation takes on. The technology is rarely the hard part. The hard part is that mistakes are public and slow to undo.
When a migration goes wrong, it goes wrong in familiar ways:
- Content disappears.
- Search rankings drop.
- Donation links break.
- People who bookmarked a page land on an error screen.
And the organisation often finds out weeks after launch.
Recovery can take longer than the rebuild. If you rely on search for donors, programme referrals or public accountability, that is not an inconvenience. It is a setback.
The difference between migrations that fail and ones that succeed is how they are planned. Failed ones are planned as technical projects: move the content, rebuild the design, launch. Successful ones are planned as governance projects:
- decide what the organisation must keep;
- decide what it is acceptable to lose;
- give every decision an owner;
- test everything before a visitor sees the new site.
| Migration Phase | Key Governance Activity | Risk of Compression | Success Metric |
|---|---|---|---|
| Content Inventory & Triage | 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 | 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 | 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 | Verify content accuracy, redirects, integrations, WCAG 2.2 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 | 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 recovering; zero critical integration failures. |
Why nonprofits migrate
The decision usually comes from one of four triggers:
- The platform has become unmaintainable. The WordPress install runs outdated plugins, the developer who built it has moved on, and nobody can make a basic update without risking a break.
- The organisation has outgrown it. A Squarespace site built when you were smaller cannot carry the content, CMS structure and audience journeys you now need.
- Remediation does not add up. A rebuild vs remediate assessment has concluded that fixing the current site is not cost-effective.
- Something has made credibility urgent. A leadership transition or a major funding round needs a site the current one cannot support.
Every one of these is a valid reason. The danger is that the urgency behind it leads to a migration planned for speed. And speed is how content gets lost and links get broken, at exactly the moment credibility matters most.
What a governance-led migration plan covers
Beyond the build itself, a plan that protects the organisation covers five areas.
1. Content inventory and triage
Before anything moves, list every page on the current site and give it one of four outcomes:
- migrate as-is;
- migrate with updates;
- redirect to a new location;
- retire.
This is a content governance exercise, not a technical one. You are deciding what the organisation takes forward and what it leaves behind, so the Communications Director, programme leads and governance team all need a say. Keep the decisions in one shared spreadsheet. That sheet is the single source of truth for the whole migration.
2. Redirect mapping
Every URL that has received traffic, been shared, or appears in print needs a 301 redirect to its new page. This is not optional. Without it, links you do not control break: funder websites, partner directories, Google results.
Get it wrong and the damage can be severe. A Totally Digital analysis of real migration failures (2025) documented one retailer whose wildcard redirects sent old pages to the homepage or to pages that did not exist. It lost around 99% of its search visibility.
The redirects themselves are not the risk. Google's site move guidance (updated 2026) states that permanent redirects do not cause a loss in PageRank, and advises keeping them for at least a year. Test your redirect implementation before launch, not after.
3. SEO preservation
A migration that is not planned for SEO will lose rankings. That is a certainty, not a risk. You keep the loss small by:
- keeping URL structures where you can;
- redirecting every URL that changes;
- carrying over meta titles and descriptions;
- keeping the heading hierarchy;
- submitting an updated sitemap to Google Search Console straight after launch.
Even done perfectly, a temporary dip is normal. What turns a dip into a permanent loss is a weak redirect map or a late sitemap.
4. Integration continuity
Your current site connects to other systems: donation platform, CRM, email marketing, analytics, cookie consent, forms. Document each one, test it on the new platform, and confirm it works before launch.
Each one fails quietly:
- A donate button pointing at a payment page that no longer exists loses revenue.
- A Google Tag Manager container left behind means analytics goes dark on launch day.
- A sign-up form that submits to nowhere loses every new subscriber.
5. Stakeholder communication
A migration touches everyone who uses your site:
- major donors with the old donation page bookmarked;
- programme partners linking to specific resources;
- funders who reference your governance section in their records;
- board members who use the site to check the organisation's public face.
Build in a step that tells key stakeholders about the change and gives them updated URLs where they need them.
The timeline mistake
The most common migration failure is a squeezed timeline. The board or Executive Director sets a launch date around an external event (a campaign, a conference, a funding deadline) and the migration gets whatever time is left.
Then the shortcuts follow:
- content triage is skipped;
- redirect mapping is cut short;
- testing shrinks to "it looks right on my screen".
The site launches on time, with broken links, missing content and integration failures that take weeks to surface.
A migration has five phases, and they run in order: inventory and triage, design and build, migration and redirect mapping, testing and review, then launch and monitoring.
Most run six to twelve weeks. That window starts when content and approvals are signed off, not on the day the project starts. The distinction matters: the tail on every late migration is copy and sign-off, not build time, and a schedule counted from kick-off quietly blames the organisation for the part it controls. Larger sites, and those with more integrations, sit at the top of the range.
The rule that matters is simple: no phase gets dropped to meet a date. If one has to be shortened, decide that on purpose, not by default.
Testing before launch
Testing is where governance failures are caught or missed. Cover at least these five areas:
- Content accuracy. Does every migrated page show the correct, current content?
- Redirects. Does every old URL land on the right new page?
- Integrations. Do donation forms, contact forms, email sign-ups and analytics all work?
- Accessibility. Do the homepage, donation page, a programme page and the governance section meet WCAG 2.2 AA?
- Mobile. Does every critical page work on a phone, including forms and navigation, rather than just render?
Have someone who did not build the site run the tests. The builder knows what the site is meant to do, so they read past the errors. Fresh eyes find what the builder missed.
Free download
Your website, for the board.
A two-page briefing you can fill in and put in the next board pack. It covers the six things funders check, how to see what AI tools say about you, and the options to put to trustees.
That did not send. Email hello@socialectric.com and I will send you the briefing.
Frequently asked questions
- How long does a nonprofit website migration typically take?
Most run six to twelve weeks, counted from the point content and approvals are signed off, not from the day the project starts. Copy and sign-off are what every late migration waits on. Larger sites and those with complex integrations sit at the top of that range. The phases run in order: content inventory and triage, design and build, content migration and redirect mapping, testing, then launch and post-launch monitoring. Broken links, missing content and integration failures come not from a short timeline but from a phase dropped to meet a date.
- Will we lose our search rankings during a migration?
A temporary dip is normal and expected; without redirects, the loss can be permanent. Google's site move guidance (updated 2026) says medium-sized sites can take a few weeks or more before the new URLs replace the old ones in search, and that permanent redirects do not themselves cause a loss in PageRank. Google advises keeping them for at least a year. The quality of the redirect map is the single most important factor in SEO preservation during a migration.
- Should we clean up content before or during the migration?
Before. Run the content inventory and triage at the start of the project, not during the build. Migrating content and then deciding what to keep wastes build time and creates confusion. Decide what moves, what is updated, what is redirected and what is retired before the first page is built on the new site.
- What are the most common triggers for nonprofit website migrations?
There are four: an unmaintainable platform with outdated plugins or departed developers, outgrowing the platform’s capacity, a rebuild-versus-remediate assessment finding remediation isn’t cost-effective, or an event such as a leadership transition that makes credibility urgent in a way the current site cannot support.
- Why do most website migrations damage search rankings?
Because they are planned as technical projects rather than governance projects. Missing redirect maps, dropped pages, misdirected URLs and late sitemap submissions all cost organic traffic, and recovery can take longer than the migration itself.
- What five areas must a governance-led migration plan cover?
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, telling donors, partners, funders and board members about changes and updated URLs.
- What testing should occur before launching a migrated nonprofit site?
Test five areas independently: content accuracy on every migrated page, redirects for all old URLs, integrations such as donation forms and analytics, WCAG 2.2 AA accessibility on critical pages, and mobile, checking that forms and navigation work on phones rather than just render.
- How do we prevent donation revenue loss during migration?
Document every integration on the current site before migration begins, then test each one on the new platform before launch: donation platform connections, payment page links, form submissions, Google Tag Manager containers, analytics tracking and email sign-up forms. Never assume integrations transfer automatically.
- Who should be involved in content triage decisions?
The Communications Director, programme leads and governance team. Triage is a content governance exercise: deciding what the organisation takes forward and what it is ready to leave behind. Record the decisions in one shared spreadsheet, the single source of truth for the whole migration.
- What is a Blueprint Audit for migration planning?
A Blueprint Audit is a structured assessment of what works, what fails and what to prioritise in a new build. It maps stakeholder priorities, technical bottlenecks and governance gaps, so migration decisions rest on evidence rather than assumption before any platform or timeline is committed.