♥︎★♣︎♦︎
Who, what, why
Webflow got us a long way. Anyone could push updates to staging and share a link for a quick thumbs-up from marketing.
But we'd outgrown it. Edits waited on whoever had a Webflow seat, and we wanted to build interactive moments, like a live Deep Search demo, with Amp and other AI coding tools. We needed a setup we fully controlled.
As the only Brand Designer and the owner of sourcegraph.com, I led the marketing side of the move: gathering the team's requirements, auditing every page, and mapping the tracking and integrations hiding under the hood.
Engineers Taras Yemets and Fede Rubinstein did the heavy lifting of moving pages into SvelteKit. Early on, I set the ground rule we'd hold the whole way:
Move it 1:1 → prove nothing broke → then improve it on purpose
I called it "separating correctness from improvement". If we redesigned while moving and traffic dropped, we'd never know which change caused it.
Constraints
–– Time ––––
We kicked off in January 2026, right as engineering was heads-down on the 7.0 launch. Their call: start with the blog as a smaller test run, then move the main site after 7.0 shipped. That set our target at early April.

–– Hidden plumbing ––––
A marketing site is more than pages. Ours had analytics and campaign tracking, HubSpot forms, and old "SEO zombie" URLs that still needed redirects. Our marketing ops lead had also just left, so a lot of that know-how walked out the door.
Success looks like...
–– Nothing broke ––––
Visitors shouldn't notice the move at all. Same pages, same forms, same tracking, same search rankings. Any redesign could wait.

–– Built to grow ––––
Once moved, the team should be able to make changes with Amp instead of waiting on a seat or a specialist. And we'd finally have room for the interactive ideas Webflow made hard.
Six phases, one outcome each
We broke the move into six phases, and each one had a single job. I wrote this plan, informed by requirements from engineering.
Alignment & audit: everyone agrees on scope, ownership, and what's off-limits.
Blog first: the blog moves early, so publishing never stops.
Scaffolding: a bare-bones site we can deploy and preview.
Integration porting: no silent drops in analytics or conversions.
1:1 migration: every page matches the original, no redesign. Consolidating components still brought a few design changes along for the ride.
QA, cutover, launch: a clean switch with a way to roll back.
Taking inventory
Before moving anything, I wanted to know what we actually had. I built a page audit spreadsheet and pulled in our SEO partner and ads lead to flag anything earning traffic or tied to a campaign. The blog alone went from about 400 posts to 180, cutting posts centered on a retired product and anything over a year old with no traffic.
I also inventoried every third-party script on the old site, from analytics and product telemetry to sales tools, and sorted what we'd need to port from what we could drop. Anything that needed a redesign got logged for later, not fixed on the spot.

What we kept, cut, and merged.

From Figma to code
In Webflow, the brand lived in a visual editor. In SvelteKit, it had to live in code. I pushed for the marketing site to keep its own design system, separate from the product's UI tokens, mostly for type scale and color. Marketing needs room to play in a way product UI doesn't.
The palette stayed simple on purpose: black, cream, and pops of vermilion.
The rebuild
Engineering moved the pages over, leaning heavily on Amp. I was the bridge to everything marketing-shaped: tracking down how our HubSpot forms were wired, handing tracking code to our marketing ops contractor, and answering "where did this come from?" as questions surfaced.

The tradeoff I fought for: keeping the first move 1:1, even when "cleaning up while we're in there" was tempting. The one place I let it slide was consolidating components. Merging them into one shared set was cleanup worth doing, even though it nudged the design along the way.
Moving day
The blog went first. By April 1, every migrated page was live except the homepage, which waited until Webflow was fully switched off to avoid conflicts. On April 8, the new homepage went live, and not a single page was served from Webflow anymore.
The groundwork paid off. Once pages started moving, 25 migration tickets, some covering whole groups of pages, closed in about three and a half weeks.
We didn't even wait for the move to finish. In early March, I flagged our use cases campaign page as the true P0 to build on the new platform, and started building it with Amp as soon as engineering had the basic layout ready. It went live at the end of March alongside two ebook landing pages, launching marketing's first fully integrated campaign, all before the homepage had even cut over.
From renting to owning
Webflow was like renting: easy to move in, but you live by the landlord's rules. Moving into our own codebase meant owning the place, leaky faucets and all.
Owning it also meant owning its rough edges. The biggest one: in Webflow, I could share a preview link for approval in seconds. In a shared codebase, every round of feedback meant another pull request. One work-in-progress pricing page even slipped into production by accident.
My lesson: a marketing team isn't in the code all day, and shouldn't have to be. Live preview links aren't a nice-to-have for a marketing site. They're table stakes. We launched without them, and not by accident. Per-branch previews were left out of the migration on purpose: our hosting platform is built for security compliance and doesn't support them, and engineering judged the cost and upkeep weren't worth it for most changes. That tradeoff made sense on paper, but it landed hardest on marketing, since our reviewers aren't in the code. For months, every review went through a single shared preview environment. It worked, barely. The fix finally came from our own tools: we now use Amp Orbs to spin up "portals," live preview links for any work in progress.

You may also like

↑Back to Top