# How to plan a B2B SaaS website migration in 2026

**Published:** July 24, 2026 | **Updated:** August 13, 2026 | **Authors:** Jakub Startek | **Category:** SaaS

**Canonical:** https://www.grafit.agency/blog/b2b-saas-website-migration-process

Do you need a migration or a redesign? If the design is the problem, redesign. If the platform is the problem, migrate. Migrations take six to eight weeks. Expect most of that time to go into reconnecting integrations rather than building the new site.

---

## **Website migration or redesign: which project do you need?**

Most SaaS teams know the site needs work but haven't figured out which project it is, and that costs them time and money. A migration is a platform move. A redesign is a design change on the same platform. Both end with a new site going live, and after that they have almost nothing in common. Get a redesign wrong, and you lose rankings. Get a migration wrong, and you lose rankings, your CRM sync, every form on the site, and every tracking event your team relies on.

## When to migrate a B2B SaaS website

Most rebuilds start with someone saying "the site feels old."

| Signal | What it means | What to do |
| --- | --- | --- |
| Every landing page needs a developer | Your CMS was not built for marketers | Migrate to a platform your team can maintain |
| Plugin conflicts break pages weekly | The dependency stack is too fragile | Migrate off the plugin-heavy platform |
| Integrations only half work | The site was not built for a modern stack | Migrate with integrations as a priority |
| Site speed has plateaued despite optimisation | You have hit the platform's ceiling | Migrate to a platform with better defaults |
| Security patching eats real hours every week | Maintenance cost has outgrown the platform | Migrate to something managed |

If the signals point to design being weak rather than the platform, you are looking at a redesign. The two projects overlap at launch, but they answer different questions. When we scope work with a client, the first job is usually deciding which one they actually need, and [the audit that separates the two](https://www.grafit.agency/blog/redesign-b2b-website-without-losing-seo) is where that call gets made.

## The migration website process, phase by phase

![Six-phase B2B SaaS website migration process: discovery and scoping, content and integration audit, design and CMS architecture, build and integration rewiring, testing and staging, and launch with 90-day monitoring](https://cdn.sanity.io/images/2uwh1hy5/production/aefc89e2386bad13834617b4fd654af83cd49bae-1548x871.webp?w=1600&fm=webp&q=75)

Most B2B SaaS website migrations run six to eight weeks end to end. The phases below are how we scope [website migration](https://www.grafit.agency/services/website-migration) projects.

### Phase 1 Discovery and scoping

Get the brief right before anyone opens Figma. Work out what breaks if this goes wrong, which integrations are load-bearing, which URLs bring in revenue, and who owns each decision.

- Output: a scoped project plan. A wireframe isn't what you're after at this stage. Skipping this step is the number one reason migrations run over.

### Phase 2 B2B content and integration audit

Run two audits at the same time. The content audit catalogues every URL, CMS collection, and form on the site. The integration audit maps [every third-party tool the site talks to](https://www.grafit.agency/services/website-integrations), from HubSpot and Salesforce to Segment, GA4, Intercom, and any custom scripts.

- The redirect map also comes out of this phase. Integrations that generate URLs on the fly, such as gated content, personalised paths, and product signups, need their own rules on top of the standard URL mapping.

### Phase 3 Design and CMS architecture

[Web design](https://www.grafit.agency/services/web-design) and the content model get built together in this phase. Let your [content strategy](https://www.grafit.agency/services/content-strategy) drive how the CMS is structured, so it reflects how the marketing team publishes rather than how the current site happened to be built.

- This is where you fix the compromises your old CMS forced. Content-model decisions ripple through URL structure and editor autonomy, and the [difference between how platforms like WordPress and Webflow handle this](https://www.grafit.agency/blog/webflow-vs-wordpress-b2b-saas) usually comes down to what the CMS forces you to do at scale.

### **Phase 4 Build and integration rewiring**

The build itself rarely causes problems. Integrations are where projects get stuck. Every tool that talked to the old site has to be reconnected and tested against real data rather than staging placeholders.

- Marketing automation, lead scoring, CRM sync, and analytics events are the usual culprits when something breaks quietly after launch. The mechanics of [clean Webflow development](https://www.grafit.agency/services/webflow-development) all live here.
-

### **Phase 5 Testing and staging**

Test every form, every integration, every CMS template, and every conversion path against the same criteria the live site meets today. Staging exists so that things fail in a safe environment.

- Add load testing if the site handles product signups or gated content at any volume. A staging site that works with three test users can still fall over on launch-day traffic.

### **Phase 6 B2B website launch and 90-day monitoring**

Launch doesn't close out the project. The first 90 days are when hidden problems surface: a form that submits but does not sync to HubSpot, a tracking event that fires twice, a redirect that lands on the wrong page.

- This is also when [conversion rate optimisation](https://www.grafit.agency/services/cro) work starts. Migrations usually cause a small conversion dip while users relearn the site. Testing after launch is how you turn the new platform into a real advantage.

**Not sure if you need a migration or a redesign?**

## Technical website migration playbook for devs and technical PMs

The rest of the guide covers the parts that most often go wrong on launch day: DNS strategy, redirect implementation, CMS API work, and the environment discipline that keeps rollback fast.

> The rule I use on every migration is simple: never send live traffic to something you have not verified yourself. If you cannot hit the new environment with a hosts-file override and get a clean response, DNS was never the problem, and pushing it live will not fix it. The actual bug is usually a certificate conflict, the old host or registrar still serving its own SSL cert instead of letting Webflow issue one for the domain, a redirect loop, or a CDN rule that never got copied over. DNS just gets blamed because it's the last thing anyone touched before the site went dark.

— Adam Muchowski,  Developer, Grafit

### DNS cutover and TTL planning for a website migration

DNS is what tells the internet where your site lives. When you migrate, that pointer moves. The trick is shortening how long the old address is cached before you flip it, so the switch propagates in minutes instead of hours.

| When | Do this | Why it matters |
| --- | --- | --- |
| T minus 7 days | Audit every DNS record. Export the zone file. | Your rollback reference |
| T minus 48 hours | Lower TTL on A, AAAA, and CNAME records to 300s | Faster propagation at cutover |
| T minus 24 hours | Verify the new environment via hosts-file override | Confirms SSL, headers, and origin before DNS moves |
| Cutover | Update A/AAAA/CNAME. Keep the old origin online for 72h. | Serves visitors with cached DNS |
| T plus 1 hour | Run dig +short from multiple regions | Confirms global propagation |
| T plus 72 hours | Restore TTL to 3600–14400s | Reduces DNS resolver load |

If the site sits behind a CDN (Cloudflare, Fastly, Bunny), the cutover happens at the CDN layer, not the origin. Faster, but purge the CDN cache after the cutover or visitors keep seeing the old site.

### 301 redirects and URL mapping during a website migration

Redirects are the single most preventable cause of ranking loss in a [website migration](https://www.grafit.agency/services/website-migration). Every URL that changes has to point to the closest match on the new site. Miss one, and visitors and search engines land on a 404 while the ranking history for that URL disappears.

Start by crawling the old domain with Screaming Frog and exporting every live URL. That export becomes the baseline for both the new slug structure and the redirect map, so nothing gets missed or invented from memory.

Build the map in a spreadsheet first, three columns minimum: old URL, new URL, redirect type. Then follow these rules:

| Rule | What it means | What breaks if you skip it |
| --- | --- | --- |
| Crawl the old domain first | Export every live URL with a tool like Screaming Frog before mapping anything | Redirect map based on memory or a sitemap misses orphaned or unlinked URLs |
| One-to-one mapping | Every old URL points to one specific new URL | Homepage-funnelling tells Google the old URLs are dead |
| No redirect chains | A → C and B → C, never A → B → C | Crawl budget wasted, users slower to load |
| 301 for permanent moves | Use 302 only for A/B tests or temporary changes | Google treats 302s as non-authoritative |
| 410 for removed content | Only when there is no replacement page | Soft 404s leave orphan URLs indexed |
| Test top 50 URLs by traffic manually | Automated crawlers miss content mismatches | A 200 response with the wrong content still counts as "working" |

Where the redirects live depends on the destination platform:

| Platform | Where redirects go | Practical ceiling |
| --- | --- | --- |
| Webflow | Site Settings, Publishing, 301 Redirects | ~10,000 rules before UI lag |
| WordPress to Webflow | Yoast sitemap export, row-by-row mapping, CSV import | Category archives usually consolidate to the blog |
| Headless (Next.js, Astro) | nginx config, CDN edge, or _redirects file | Effectively unlimited |

The URL classification method for a migration is the same one that keeps rankings safe through a rebuild, and the [pattern for sorting URLs into keep, redirect, merge, remove](https://www.grafit.agency/blog/redesign-b2b-website-without-losing-seo) applies here line for line.

### CMS content migration through the API

For anything over a few hundred CMS items, moving content through the API beats CSV import on speed and safety. Four steps:

| Step | What you do | Common failure |
| --- | --- | --- |
| Extract | Pull content from the source CMS as structured JSON | Missing custom fields the API does not expose by default |
| Transform | Map source fields to destination CMS collections | Reference fields and image URLs left pointing at the old origin |
| Load | Write to the destination via API | Rate limits ignored, batch fails halfway through |
| Validate | Diff source and destination programmatically | Item counts match but slugs or metadata do not |

Source APIs to know:

| Source CMS | API surface |
| --- | --- |
| WordPress | REST API at /wp-json/wp/v2/, or GraphQL via WPGraphQL |
| HubSpot | CMS API |
| Contentful, Sanity | Content models exposed natively |

Destination for Webflow migrations: the [Webflow Data API v2](https://developers.webflow.com/data/reference) handles collections, items, and asset uploads. Rate limit is 60 requests per minute on most endpoints, so batch writes with backoff logic. For migrations under 5,000 items, the [Webflow MCP Server](https://developers.webflow.com/mcp/reference/overview) launched in February 2026 handles the transform and load steps conversationally and produces a validation diff automatically.

### Integration reconnection order after a B2B website migration

Every integration has three failure modes. Fix them in the right order or you cannot measure whether anything else is working.

| Failure mode | What it looks like | Where to look |
| --- | --- | --- |
| Authentication | API keys tied to the old domain | Reconnect from the new site, generate fresh credentials |
| Event tracking | Events firing from the wrong origin | Check GA4 real-time and Segment debugger |
| Webhooks | Endpoints hardcoded to the old URL | Update endpoint on the destination service, not the source |

The reconnection order that works:

| Priority | Category | Tools |
| --- | --- | --- |
| 1. Analytics first | You cannot measure anything else until this works | GA4, Segment, GTM |
| 2. CRM and marketing automation | Verify test form lands in the CRM correctly | HubSpot, Salesforce Web-to-Lead, Marketo |
| 3. Chat, intent, enrichment | Identity resolution takes time to reconcile | Intercom, Drift, RB2B, Clay |
| 4. Webhooks and outbound | Update endpoints on the destination service | Zapier, custom webhooks, form-to-Slack |

Run the sequence on staging first, then repeat every step on production after DNS cutover. The staging-to-production gap is where events break quietly, because tracking IDs and webhook secrets are usually environment-specific.

### Environment setup and rollback plan for website migrations

Three environments minimum. Each one does something the other two cannot.

| Environment | What it is for | Constraint |
| --- | --- | --- |
| Staging | Building and testing on the destination platform | Unindexed, password-protected or IP-restricted |
| Pre-production | Final QA pass, production-identical | Nothing shipped from here goes public |
| Production | Live site | No unverified changes ever land here |

Rollback plan, written before launch:

| Rule | Reason |
| --- | --- |
| Old origin stays online for 72h post-cutover | Serves stragglers with cached DNS |
| DNS records for the old origin stay in the zone (unpublished) | One-click swap back if you need it |
| Full database and file backup from the source kept for 30 days | Last-resort recovery |
| One owner has authority to trigger rollback | Removes decision-by-committee under pressure |
| Rollback thresholds defined in advance | e.g. "error rate above 5% for 15 minutes, or conversion down 40% in the first 24 hours" |

The point of a rollback plan is not to use it. It is to make the cutover decision boring, because the fallback is already defined.

### How long a B2B SaaS website migration takes

Six to eight weeks is realistic for a B2B SaaS site of 50 to 200 pages, provided discovery is clean and both teams are available.

The [Callstack rebuild](https://www.grafit.agency/case-studies/callstack) took six weeks and lifted conversions by 176%. The timeline held because we fixed the scope early, audited the integrations before building, and moved the content across as-is, leaving the rewrite until after launch.

![Six-week B2B SaaS website migration timeline: strategy and discovery, design, Webflow development, and launch with ongoing CRO](https://cdn.sanity.io/images/2uwh1hy5/production/3de32aff1daac775ab6da108e159c4afd3259500-1488x1110.webp?w=1600&fm=webp&q=75)

---

Ready to talk about your B2B website? [Contact us](https://www.grafit.agency/contact)

**More posts:** [All blog posts](https://www.grafit.agency/blog.md) | [Case studies](https://www.grafit.agency/case-studies.md)