Migrating 3.100 URLS from a 14 year old Wordpress site…
0 reactions
Migrating 3.100 URLS from a 14 year old Wordpress site - fear and loathing in Redirect spreadsheet
Last year we took on one of the larger migrations our agency has handled. A nonprofit CRM platform that's been running since 2012, needed to move off WordPress.The issue wasn’t necessarily Wordpress but 12 years of accumulated complexity had turned their site into something nobody could move fast on. Basically every change was a developer ticket. The marketing team was blocked.
**The size of the project when we mapped it out:**
3100 URLs total. 1300+ blog articles, 550 webinars, 120 case studies, 75 guides, 100+ news pages. All that sitting on a WordPress build that had been patched together with page builders over a decade. It had no shared templates and no unified system.
So we went about replacing 12 years of accumulated architecture with something that could scale, without losing the SEO equity the domain had been building since 2012… it was a headache no one was prepared for, but we pushed on.
**How we structured it**
Before writing a line of code, we spent time cataloguing every URL, identifying content types, and grouping pages by structure. What looked like thousands of unique design problems collapsed into a somewhat manageable set of reusable templates once we mapped it properly. Looking back at it, that upfront work is what makes the difference between a migration that holds together and one that falls apart mid-project.
**We split the work into five phases:**
Phase one was foundation, meaning building the global component library and CMS collection structure from scratch. We made sure every schema, every template, every reusable block was defined before content migration started.
Phase two was high-priority pages first. So core conversion flows, product pages and the homepage… The point is to validate the system works before moving content at scale.
Phase three was content migration. Export, clean, and import 1,300+ articles. Verify formatting, preserve internal linking, make sure every embed and media file rendered correctly.
Phase four was remaining pages and redirects. Every legacy URL mapped to its new destination with 301 redirects. This is the step that protects organic rankings on a domain with over a decade of authority… skipping it or doing it sloppily is how you give Google a reason to tank your traffic.
Phase five was QA, launch, and handoff. Full cross-device testing, launch coordination, and documentation so the editorial team could manage content independently post-launch.
**How it got very complicated**
Scope expanded mid-project, as it does on migrations of this size. We pulled in three to four extra people at peak to keep the timeline intact. The thing that kept it manageable was having the architecture fully mapped before we started building. When you know exactly what you have, adding resources to a specific phase is straightforward. When you don't, adding people causes extra confusion.
The other thing worth mentioning: content migrations surface a lot of “website trauma” that nobody knew existed. Orphaned pages, broken internal links, inconsistent metadata, embeds that no longer work. You find all of it when you're moving 3,100 URLs individually. If you take any advice from this, it would be to budget time for cleanup, not just for the move itself.
**What we'd do differently**
Start the redirect mapping earlier. We built it into phase four but in retrospect it should run in parallel from day one… By the time you're mapping 3,100 URLs late in a project, everyone is tired and the margin for error goes up.
Also: Freeze content earlier and harder. On a site with an active editorial team, new posts kept going up during the migration window. That's manageable at low volume but becomes a real coordination problem at scale.
How would you guys take on a project like this? Is there anything we missed?
*(This is a Flowout project - we're a Webflow agency… Posting because the process is relevant regardless of which platforms you're migrating between.)*
#dev #technology #programming
Last year we took on one of the larger migrations our agency has handled. A nonprofit CRM platform that's been running since 2012, needed to move off WordPress.The issue wasn’t necessarily Wordpress but 12 years of accumulated complexity had turned their site into something nobody could move fast on. Basically every change was a developer ticket. The marketing team was blocked.
**The size of the project when we mapped it out:**
3100 URLs total. 1300+ blog articles, 550 webinars, 120 case studies, 75 guides, 100+ news pages. All that sitting on a WordPress build that had been patched together with page builders over a decade. It had no shared templates and no unified system.
So we went about replacing 12 years of accumulated architecture with something that could scale, without losing the SEO equity the domain had been building since 2012… it was a headache no one was prepared for, but we pushed on.
**How we structured it**
Before writing a line of code, we spent time cataloguing every URL, identifying content types, and grouping pages by structure. What looked like thousands of unique design problems collapsed into a somewhat manageable set of reusable templates once we mapped it properly. Looking back at it, that upfront work is what makes the difference between a migration that holds together and one that falls apart mid-project.
**We split the work into five phases:**
Phase one was foundation, meaning building the global component library and CMS collection structure from scratch. We made sure every schema, every template, every reusable block was defined before content migration started.
Phase two was high-priority pages first. So core conversion flows, product pages and the homepage… The point is to validate the system works before moving content at scale.
Phase three was content migration. Export, clean, and import 1,300+ articles. Verify formatting, preserve internal linking, make sure every embed and media file rendered correctly.
Phase four was remaining pages and redirects. Every legacy URL mapped to its new destination with 301 redirects. This is the step that protects organic rankings on a domain with over a decade of authority… skipping it or doing it sloppily is how you give Google a reason to tank your traffic.
Phase five was QA, launch, and handoff. Full cross-device testing, launch coordination, and documentation so the editorial team could manage content independently post-launch.
**How it got very complicated**
Scope expanded mid-project, as it does on migrations of this size. We pulled in three to four extra people at peak to keep the timeline intact. The thing that kept it manageable was having the architecture fully mapped before we started building. When you know exactly what you have, adding resources to a specific phase is straightforward. When you don't, adding people causes extra confusion.
The other thing worth mentioning: content migrations surface a lot of “website trauma” that nobody knew existed. Orphaned pages, broken internal links, inconsistent metadata, embeds that no longer work. You find all of it when you're moving 3,100 URLs individually. If you take any advice from this, it would be to budget time for cleanup, not just for the move itself.
**What we'd do differently**
Start the redirect mapping earlier. We built it into phase four but in retrospect it should run in parallel from day one… By the time you're mapping 3,100 URLs late in a project, everyone is tired and the margin for error goes up.
Also: Freeze content earlier and harder. On a site with an active editorial team, new posts kept going up during the migration window. That's manageable at low volume but becomes a real coordination problem at scale.
How would you guys take on a project like this? Is there anything we missed?
*(This is a Flowout project - we're a Webflow agency… Posting because the process is relevant regardless of which platforms you're migrating between.)*
#dev #technology #programming
| 3,000 mlx | |
| 4 | |
| 0 |