Most B2B SaaS sites get migrated every 18 to 36 months. WordPress to Webflow. Webflow to Framer. Framer to Lovable. Lovable to a custom Next.js build on Vercel. Each migration is a high-risk technical SEO event that has cost some of our inherited clients 30 to 60 percent of organic traffic. The team did not know it had happened until the new agency audited the site months later.
This is the migration playbook we run on every B2B SaaS engagement. The pre-launch checklist that prevents the common disasters, the launch day discipline that catches problems early, the two-week monitoring window, and the recovery framework when things go wrong despite preparation.
01 / Why B2B SaaS sites get migrated so often
The platform churn is real. WordPress was the dominant marketing site platform from 2010 to 2018. Webflow took over for design-focused teams from 2018 to 2022. Framer gained share from 2022 to 2024 for marketing-led teams. Lovable and similar AI-assisted builders emerged 2024 to 2025. Custom Next.js builds on Vercel became the default for engineering-led companies from 2023 onward.
Each platform shift is driven by something legitimate: better DX, better designer-developer collaboration, faster page builds, lower hosting costs, more flexibility. But each migration is a chance for the SEO program to lose ground.
The migration mistakes we have inherited are remarkably consistent across platforms. Same patterns, different platforms. Which means the playbook to avoid them is also consistent.
02 / The pre-launch checklist
Twelve items, in order. Skip any of them and the migration risk increases meaningfully.
1. URL mapping document. Every old URL maps to a new URL or returns a 410 (gone). The mapping is documented before the migration begins, not improvised after. Spreadsheet format with columns: old_url, new_url, redirect_type (301 or 410), notes.
2. 301 redirects, not 302s. Verify every redirect is a 301. The single most common mistake we audit: migration tools default to 302, the engineer accepts the default, every redirect is temporary, link equity is silently lost.
3. Sitemap regeneration. New sitemap files for the new URL structure, listed in a sitemap index, ready to submit at launch.
4. Internal links audit on the new site. Every internal link inside content should point to the new equivalent URL, not rely on the redirect chain. Direct linking to current URLs is cleaner than relying on 301s.
5. Schema markup re-deployment plan. Schema gets stripped during migrations more often than any other technical SEO element. Document which pages have which schema and verify each is intact post-launch.
6. Core Web Vitals baseline measurement. Capture LCP, INP, CLS for the highest-traffic 50 URLs before migration. You will need this comparison post-launch.
7. Rendering verification on the new platform. If the new platform's defaults differ from the old (CSR vs SSR vs SSG), confirm explicitly which mode each page type renders in.
8. Top 50 traffic pages spot-check. Manually open each in the new platform's preview environment. Verify rendering, content, canonicals, internal links.
9. Robots.txt audit. The new platform's default robots.txt may differ from the old. Verify allow/disallow rules match what you intend.
10. Tracking and analytics. Google Analytics 4, Google Tag Manager, HubSpot tracking, Hotjar, etc. Verify each is firing correctly on the new platform.
11. Search Console property verification. The new domain (if changing) needs verification before migration. The DNS change to verify can take 24+ hours, so do this in advance.
12. Rollback plan. Documented conditions under which you roll back to the old platform. Includes who has authority to call the rollback and the technical steps to execute it.
03 / Launch day discipline
The single most common migration mistake we encounter: launching on a Friday afternoon and not monitoring until Monday. By Monday, broken redirects have been crawled, indexed, and started showing in search. The recovery takes 2 to 4 weeks of compounded pain.
The launch day discipline:
- Migrate on a Tuesday or Wednesday morning, between 9 and 11 AM in your highest-traffic timezone. Engineering is fully staffed. The bulk of the day is available for monitoring and triage.
- Engineering on standby for 72 hours minimum. Not "available," not "monitoring slack." On standby. First-shift critical issues need response within 30 minutes for the first 4 hours.
- First 4 hours: synthetic monitoring on the top 20 traffic pages. A simple uptime check that hits each URL every 15 minutes and alerts on any non-200 response.
- First 24 hours: GSC Coverage report check, top 50 pages manual spot-check, sitemap re-submission verified.
- First 72 hours: full site crawl with Screaming Frog. Compare to the pre-migration crawl. Investigate every difference.
Do not launch and walk away. Migrations fail in the first 72 hours.
04 / The two-week monitoring window
Most migration issues surface between days 3 and 10 post-launch as Google re-crawls and re-indexes the new structure.
Daily checks for 14 days:
- GSC Coverage report (look for "Indexed but not submitted in sitemap," "Submitted but not indexed," any spike in error categories)
- GSC Performance report (compare clicks and impressions trend against pre-launch baseline)
- Top 20 traffic pages: are they ranking where they were?
- Brand search results: is your homepage still ranking #1 for your brand name?
- Any sudden drops in any segment
Weekly checks for the rest of the first month:
- Full Screaming Frog crawl
- Internal linking audit
- Schema validation re-check
- Backlink profile (Ahrefs Backlinks, GSC Links report) for any drop in incoming links
Most issues surface in days 3 to 10. After day 14, the migration is generally locked in. After day 30, you are working with the new normal.
05 / The five common migration disasters and how to recover
Disaster 1: 302 instead of 301 redirects. Caught usually in week 2 when traffic plateaus instead of recovering. Fix: change every redirect to 301. Re-submit affected URLs to GSC for re-crawl. Recovery: 4 to 8 weeks.
Disaster 2: Pages canonicalized to wrong URLs. Migration template introduces canonical bugs. Pages tell Google "do not index me, index this other page." Caught usually in week 2 to 4 when ranking drops on pages that were previously stable. Fix: audit canonical tags, correct, re-submit. Recovery: 4 to 8 weeks.
Disaster 3: noindex left on staging-cloned templates. Staging environment had <meta name="robots" content="noindex">. Production templates inherited it. Entire site sections become uncrawlable. Caught usually in week 1 if monitoring is good, week 4 if not. Fix: remove the noindex tag, re-submit URLs. Recovery: 2 to 4 weeks if caught early.
Disaster 4: Switch from SSG to CSR. Old platform had server-rendered content. New platform's default rendering is client-side. Most non-Google crawlers cannot see content. Google indexes slowly. Rankings drop 20-40 percent over 4 to 6 weeks. Caught usually in month 2 to 3. Fix: enable SSR or SSG in the new framework. Recovery: 8 to 16 weeks.
Disaster 5: Schema markup stripped, never re-deployed. Article schema, FAQPage schema, BreadcrumbList all disappeared in the migration. Rich results disappear from SERP within 4 weeks. Caught usually when monitoring rich results impressions in GSC. Fix: re-deploy schema. Recovery: 4 to 8 weeks.
06 / Platform-specific gotchas
WordPress to Webflow. Webflow's default URL structure may differ from WordPress's permalinks. Map carefully. Webflow strips schema by default unless you re-deploy it via custom code embed. Webflow's image optimization is good but verify CWV post-migration.
Webflow to Framer. Framer's CMS structure differs significantly. Plan for restructuring blog and resource library URL hierarchies. Framer has limited internal linking control; you may need to reduce expectations on internal linking density.
Webflow or Framer to Lovable. AI-assisted site builders are still maturing on technical SEO. Expect to manually verify schema, sitemap, robots.txt, and rendering mode. Lovable has improved significantly through 2025 but is not yet at the level of mature platforms for SEO defaults.
Anything to custom Next.js on Vercel. Highest-quality outcome possible if implemented correctly. Verify default rendering is SSG or ISR (not CSR). Verify Image component is being used (handles WebP, lazy loading, dimensions automatically). Verify metadata is server-rendered, not client-injected.
HubSpot to anything. HubSpot's URL structure has quirks. The blog URL pattern is different from most other platforms. Plan extensive URL mapping and 301 redirects. HubSpot tracking will need to be re-implemented separately on the new platform.
07 / The migration cost-benefit framework
Migration is expensive. Engineering hours, agency hours, downtime risk, ranking risk, opportunity cost during the disruption period.
Before committing to a migration, ask:
- What problem on the current platform is the migration solving? Is it solvable without migrating?
- What is the realistic ranking risk? Have we audited inherited migrations from this platform pair?
- What is the engineering cost in hours? In opportunity cost?
- What is the downtime budget?
- Is there a smaller migration (single section, single feature) that produces 80 percent of the benefit at 20 percent of the risk?
Most migrations we are asked to consult on do not need to happen. The team thinks the platform is the bottleneck when the bottleneck is content production, technical debt, or strategic alignment. A migration does not fix those.
When a migration does need to happen, plan it with the same rigor as a major product launch. Pre-migration audit, detailed checklist, launch day discipline, post-launch monitoring. The cost of getting it right is small. The cost of getting it wrong is multi-quarter recovery.
08 / Part of a larger technical playbook
This article covers migrations specifically. For the full B2B SaaS technical SEO process, see our B2B SaaS technical SEO checklist. For related deep dives, see JavaScript SEO for B2B SaaS marketing sites and Core Web Vitals targets for B2B SaaS in 2026.
