NewBase
Get in touch

Webflow to Astro for B2B SaaS

A SaaS marketing site is usually the largest Webflow site a company owns, and the one with the most wired to it. The migration is mostly about the wiring: the templates that generate dozens of pages, the attribution carried into the CRM, and who gets to publish once the site lives in a repository.

Get in touch

Name the seam before the rebuild.

Where the line usually falls

Astro

The marketing site

  • Pages, and the components behind them
  • The content model, and who can publish to it
  • URLs, metadata and the structure under them
  • Experiments on the marketing pages

The handoff

Signup, and what follows

  • Form to record
  • Campaign attribution
  • Analytics events
  • Route into auth

Your product

The application

  • Login and account data
  • Billing, plans and entitlements
  • Provisioning
  • Anything reading live data
A migration is a good moment to write down which system owns what. The marketing site moves into a repository your team can review; the product keeps everything it already owns; the handoff in the middle is the part that has to be tested on both sides.

The page systems come across as systems.

SaaS sites grow in predictable directions: integrations, comparisons, alternatives and use cases. Each of those is a collection with one template in the new codebase, so the pages that already exist move as data and the next twenty are content rather than a build.

One template Many pages, one structure

Comparisons

Integrations

Alternatives

Use cases and industries

Comparisons
Product-versus-product pages from one model.
Integrations
One structure for every product connection.
Alternatives
Replacement-intent pages on the same template.
Use cases and industries
The same product positioned for different audiences.

The stack matters as much as the pages.

Astro The marketing site

What gets decided before a SaaS migration starts.

  1. 01

    Which page systems are templates and which are one-offs

    Forty integration pages generated from a model move differently from forty pages built by hand. The count in the CMS tells you which you have.

  2. 02

    Which system owns the lead, and what carries with it

    The destination decides what the form does, which attribution fields travel with it, and what happens when a write fails. That is the part worth testing at the destination.

  3. 03

    Who publishes after the move, and how often

    A team shipping campaign pages weekly needs a content model and an editing setup chosen around that, not a repository they have to file tickets against.

  4. 04

    Where the marketing site stops and the product starts

    Usually further into the marketing site than expected. Naming the seam is what stops the migration from quietly growing into the application.

Questions about B2B SaaS.

Can our marketing team still publish without waiting on engineering?

That is a decision made before the rebuild, not a property of Astro. If the team publishes weekly, the content lives in a CMS such as Sanity and the components they compose pages from are agreed up front. Editing copy and arranging approved sections stays their job. Designing a section that does not exist yet becomes a change in the codebase, which is the trade being made.

What happens to our HubSpot, Salesforce and Segment wiring?

It is rebuilt against the new site and checked at the destination. The test is the record that lands in the CRM with its attribution intact, not the success message in the browser. Anything that was quietly broken before the migration usually surfaces here, because this is the first time somebody looks.

Do the forty integration and comparison pages have to be rebuilt one by one?

No, if they were generated from a collection they stay generated from a collection. The template is rebuilt once and the entries move as content. Pages built individually in the Designer are the ones that take real time, which is why the page count matters less than how many distinct templates are behind it.

Can our in-house team take it over afterward?

That is the usual reason for moving. The site ends up in a repository with components that explain themselves and documentation where the behavior is custom. Ongoing work is available monthly at published rates, and it should be something you keep because it is useful.

Building something else?

Reach out and see if we are a good fit.

Get in touch

Currently booking two to four weeks out.