Migrating a 100+ Page Tech Law Site to Webflow: Lessons from EIP

Most Webflow migration projects don't go wrong during the build. They go wrong in the weeks before the build starts — or more accurately, because no one spent those weeks doing the discovery work that should have happened.

We've been brought in to rescue migrations that were already underway, and the pattern is remarkably consistent: the brief was a URL, a vague scope, and a deadline. No content audit. No redirect map. No SEO baseline. No agreement on what the new CMS structure should look like. By the time anyone noticed, the team was a week from launch with hundreds of unmapped redirects and no clear owner for the legacy content decisions.

This article covers the pre-project phase — the four to six weeks before a Webflow migration begins in earnest. It's the least glamorous part of the process and the most important. If you're planning a migration, treat this as a scoping checklist. If you're briefing an agency, look for evidence that this work is budgeted and planned.

Why the Pre-Project Phase Matters More Than the Build

A Webflow migration is not a website rebuild. It's a content migration, an infrastructure change, and an SEO event happening simultaneously. Each of those three dimensions has failure modes that compound when the planning is inadequate.

The content migration fails when no one has audited what exists, so pages are missed, duplicated, or migrated in the wrong state. The infrastructure change fails when redirect logic isn't defined before go-live, causing broken links and crawl errors. The SEO event fails when there's no baseline measurement, so no one knows whether rankings recovered after launch — or can prove they didn't decline.

None of these failure modes are inevitable. They're all prevented by doing the right work before the migration starts.

Step 1: The Content Audit

Before anything else, you need an accurate inventory of what you're migrating. This sounds obvious; it is consistently underestimated.

Start with a full crawl using a tool like Screaming Frog, Sitebulb, or Ahrefs Site Audit. The crawl should capture every URL currently indexed or linked — not just the pages in your CMS. Expect to find pages that no one on the current team knows about: legacy campaign landing pages, old blog categories, product pages for discontinued lines, microsites that were folded in years ago.

For each URL, record:

• Page title and meta description
• HTTP status (200, 301, 404, etc.)
• Word count (rough indicator of content depth)
• Inbound internal links (a proxy for page importance)
• Organic traffic and ranking keywords (pulled from Google Search Console or a rank tracking tool)
• Backlinks (pulled from Ahrefs or Majestic)

The last two are particularly important: they tell you which pages carry SEO equity and therefore can't afford to have their URLs broken or their content thinned without risk. A page with no traffic, no rankings, and no backlinks can be migrated or retired with minimal care. A page ranking for twenty commercial keywords with forty referring domains is a different conversation entirely.

Once the inventory is complete, assign each URL a migration decision:

• Migrate as-is — content is current, valuable, and should move unchanged
• Migrate with updates — content should be refreshed during migration
• Consolidate — merge with another page (requires redirect planning)
• Redirect to existing page — legacy URL with a clear destination
• Retire (410) — genuinely dead content with no SEO value
• Exclude from scope — out of scope for this migration, handle separately

This decision layer is what turns a raw crawl into an actionable plan. It also surfaces scope questions that need stakeholder answers before the build begins — which brings us to the next step.

Step 2: SEO Baseline Benchmarking

Before a migration, establish a clear picture of where you stand. This is the data you'll compare against post-launch to determine whether the migration preserved SEO performance.

Pull and document:

• Organic sessions (trailing 90 days from Google Analytics or GA4)
• Indexed URLs (from Google Search Console's Index Coverage report)
• Top 50 ranking keywords by position (from GSC or a rank tracker)
• Core Web Vitals scores (LCP, CLS, INP) for key pages
• Crawl depth and internal linking structure
• Structured data currently in use (JSON-LD, Open Graph, etc.)

Screenshot and export this data. Store it in a shared location that the whole project team has access to. When (not if) there are questions post-launch about whether a ranking change was caused by the migration, you need this data to exist.

We also recommend taking a manual snapshot of the top 20 ranking pages in Google around two weeks before launch. Rankings can fluctuate, and having a timestamped record gives you a solid comparison point.

Step 3: URL Mapping and Redirect Strategy

The redirect map is one of the most labour-intensive deliverables in the pre-project phase, and it must be complete before migration begins. Building it during or after the build is how projects end up launching with hundreds of broken URLs.

The redirect map is a spreadsheet with three essential columns: old URL, new URL, and redirect type (301 permanent, or 410 gone). Add a fourth column for notes, which will be used more than you expect.

Building the map requires decisions that often involve stakeholders outside the project team. Some examples:

• The site currently uses category-based URL structures (/blog/category/post-title) but the new site will use flat URLs (/blog/post-title). Every existing blog post URL needs a redirect.
• Several old product pages are being retired. Do they redirect to the product category page, or to a general "we no longer offer this" page, or do they return a 410?
• The current site has a /news section and a /blog section. The new site is consolidating them into /insights. Which posts go where?

These decisions cannot be made by the migration team alone. They require content owners, marketing leads, and sometimes legal or compliance input. Getting them resolved before the build starts prevents the scenario where a developer is waiting on a stakeholder answer in the final week of the project.

One practical tip: for large sites, build the redirect map incrementally as you work through the content audit. Don't leave it until the audit is complete — you'll end up with a bottleneck.

Step 4: CMS Collection Architecture Planning

Webflow's CMS is a collections-based system. Before migrating content into it, you need to define the collection structure — and that structure should reflect the new site's content model, not be a direct copy of whatever the old CMS used.

This is a design exercise as much as a technical one. For each content type on the current site, answer:

• What are the required fields? (Title, body, author, date, category — and what else?)
• What are the optional fields that some items use but not all?
• What are the relationships between collections? (Blog posts linked to authors; case studies linked to services; etc.)
• What does the URL slug structure look like for each collection?
• What content will be managed by editors vs. what's hardcoded in the design?

The last point matters particularly for Webflow: there's a tendency to put everything in the CMS that might ever need to change, which creates unwieldy collection structures. A cleaner approach is to put content in the CMS that is genuinely content (it changes regularly, there are multiple instances of it, it's owned by non-developers) and to hardcode things that are structural (navigation patterns, section layouts, one-off page elements).

+

This planning phase is also where you should identify the Webflow collection limits that apply to your plan tier and check that your content volume fits within them. We've seen migrations hit collection item limits mid-build — not a position you want to be in.

Our Webflow migration service always includes a dedicated CMS architecture workshop before build begins — this is one of the reasons why.

Step 5: Stakeholder Alignment

Technical planning is necessary but not sufficient. Migrations fail when the people who need to make decisions aren't aligned, aren't available, or aren't aware of what's being asked of them.

At the start of the pre-project phase, map your stakeholders:

• Decision makers — who can approve content retirement decisions, brand changes, structural changes to the site?
• Content owners — who is responsible for each content type? (Often different people for blog, product pages, legal pages, etc.)
• Technical reviewers — who needs to sign off on the redirect map, the CMS architecture, the tracking implementation?
• Launch authority — who makes the final call on go-live?

For each stakeholder, establish their availability during the project and the decisions they'll be required to make. This is particularly important for content decisions — in our experience, the bottleneck in most migrations is waiting for stakeholders to review and approve content, not the build itself.

A practical way to surface alignment early: run a one-hour kickoff workshop where you walk through the audit findings, the proposed CMS architecture, and the redirect strategy in broad strokes. Disagreements that surface in a workshop are cheap to resolve. Disagreements that surface in the final week of a build are expensive.

Step 6: Phased Rollout Planning

For sites above a certain scale — roughly 200+ pages, or any site where sections have different content owners — a single-day cutover isn't always the right launch strategy. Phased rollouts allow different sections to go live on different timelines, reducing the blast radius if something goes wrong.

Common phasing approaches:

• By content type — marketing pages first, then blog, then product/service pages, then resource library
• By traffic priority — highest-traffic pages first, long tail last
• By business criticality — core commercial pages first, legacy content last

Phased rollouts require more redirect management (you're maintaining two live environments simultaneously during the transition) but significantly reduce risk for large migrations. They also allow you to monitor SEO performance on migrated sections before committing everything.

If you're planning a phased rollout, the phasing plan needs to be defined in the pre-project phase — not retrofitted once the build is underway. Decisions about which sections go live when affect the build sequencing, the testing plan, and the stakeholder sign-off process.

Pre-Project Deliverables Checklist

To summarise, here's what should exist before migration build work begins:

• Full site crawl with HTTP status for every URL
• Content audit spreadsheet with migration decision for each URL
• SEO baseline report (organic sessions, rankings, Core Web Vitals, structured data)
• Complete redirect map (old URL → new URL → redirect type)
• CMS collection architecture document with field definitions and relationships
• Stakeholder map with decision ownership and availability confirmed
• Phased rollout plan (if applicable)
• Scope of work agreed and signed off based on the above

If any of these are missing at the point the build is due to start, we recommend pausing the build until they're in place. The cost of the delay is always lower than the cost of discovering mid-build that the redirect map is incomplete or the CMS structure doesn't support the content.

How Long Does Pre-Project Take?

For a small to medium site (under 100 pages, single CMS owner), two to three weeks is realistic. For a large site (200–1,000 pages, multiple content owners, complex redirect requirements), four to six weeks is more accurate. For enterprise-scale migrations, the discovery phase alone can run to eight weeks.

These timelines assume dedicated resource from both the agency and the client. The agency handles the technical audit, the CMS architecture, and the redirect map draft. The client handles the content decisions, stakeholder alignment, and sign-off. When client availability is limited, the timeline extends accordingly.

If your timeline doesn't accommodate a proper pre-project phase, that's a signal to either extend the timeline or reduce the scope of the migration. Attempting a large migration without this work is a reliable way to create problems that cost more to fix post-launch than the pre-project work would have cost to do properly.

If you're approaching a migration and want a structured audit before committing to a full scope, our Webflow migration team offers standalone pre-project discovery engagements. It's often the most valuable work we do on a project.