MigrationsCustom codeWebflowRoute 04 of 4
Custom code to Webflow: the presentation layer can move, the application cannot
This is the one route where the first question is not how, but how much of it. Marketing pages move and stop needing a developer. Server-rendered logic, authentication, scheduled work and anything behind a login stay exactly where they are. The interesting part of the project is deciding where that line falls, and making one domain serve both sides of it without breaking either.
Four layers, one of them on the table
Edge and DNS
Stays yoursYours either way. It is what decides which system answers which path, and on this route it becomes a design decision rather than a detail.
Presentation
This is what movesMarketing pages, content, campaign work, documentation. Templates, copy and everything a non-developer should be able to change without a deploy.
Application
Stays on your infrastructureAuthentication, sessions, business logic, background jobs, webhook receivers, anything transactional and anything rendered per visitor.
Data
Stays, without exceptionYour database, your search index, your object storage. Webflow’s CMS is a publishing store for content, not a replacement for a database you run queries against.
One brand, two systems: three ways to serve it
Whichever of these you choose decides your URL structure, and the URL structure decides the redirect map, so it is decided before anything is designed rather than negotiated during launch week. There is no universally right answer; there is a right answer for how your application is used.
Subdomain
www on Webflow, app on your own host- What it buys
- Simplest to run, nothing sits between a visitor and either system, and each side keeps its own deploy process, its own certificates and its own incident surface.
- What it costs
- The application lives on a different host name, so cookies, analytics and any shared session need thinking about. Fine when the app is used by people who are already logged in and never needs to rank.
Subdirectory behind an edge proxy
One host name, routed by path at the CDN- What it buys
- Everything consolidates on one domain, which is the strongest position for search and the least confusing for a visitor. Content and product live under one roof.
- What it costs
- A reverse proxy in front of both systems is real infrastructure with an owner, a monitor and a failure mode of its own. Set up carelessly it can fight the certificate and caching behaviour of whichever host sits behind it, so it is planned rather than improvised.
Separate domains
The product on its own name entirely- What it buys
- The cleanest boundary there is. Two systems, two teams, no shared surface, and no argument about who broke what.
- What it costs
- No consolidation at all. Correct when the application is a product used by customers who arrive with a bookmark, and wrong when the pages behind the login are also pages you want found.
If the application is a storefront rather than a product, the same decision appears on the Shopify route under a different name. There it is called a split, and it is the answer most of the time.
What stays on your infrastructure, whatever the demo showed
These are behaviours rather than technologies, so the list holds whichever framework the current site happens to be built on. If any of them is load-bearing, it is not a reason to abandon the move. It is a reason to draw the line above it and keep going.
Pages rendered per visitor
Anything whose HTML depends on who is asking, account state, entitlement, personalised pricing, a dashboard.
Authentication and sessions
Password storage, token issue and refresh, single sign-on, and the session cookie everything else depends on.
Business logic
Anything transactional: quotes, bookings that touch stock, provisioning, calculations you would not want a marketer to edit.
Background work
Cron, queues, retries, scheduled exports, nightly syncs and every job nobody thinks about until it stops running.
Webhook receivers
Payment callbacks, CRM syncs, telemetry endpoints. Something has to be listening at a stable address that never sleeps.
Your database
And any query you run against it. A CMS collection is a publishing store, not a relational database with your constraints in it.
A real search index
Wiring a hosted search product into a Webflow front end is straightforward. The index itself remains its own service with its own bill.
File processing
PDF generation, image pipelines, exports, imports, anything that reads a file and produces another one.
Fine-grained response control
Per-route cache policy, custom headers, IP allowlists and the security headers your auditors asked for by name.
Compliance commitments
Data residency, retention guarantees and processing terms your current hosting contract already satisfies and a new one would have to match.
Two honest qualifications
The boundary moves. Webflow has been extending what it can host beyond static pages. Whatever the position is on the day you read this, treat it as something to verify against your own stack rather than something to assume, and verify it with the parts of the stack that would be expensive to be wrong about.
And what it does do, it does well. Publishing without a deploy, a component model designers work in directly, a CMS a marketing team will actually open, and a hosting layer nobody on your team has to patch on a Friday. That is a real trade, and for the pages above the line it is usually a good one.
The redirect map, in the shapes a hand-built site produces
Custom URLs are usually the best of the four routes, somebody chose them, and often chose them well. What they also carry is a decade of accumulated inconsistency: extensions, case variants, both trailing-slash forms, and meaning hidden in query strings that no path rule can read.
| Current URL | Destination | Rule | Why |
|---|---|---|---|
/about.html | /about | 301 · one-to-one | The extension goes, and every page carrying one needs a rule. |
/About-Us | /about-us | 301 · one-to-one | Your server may have been case-insensitive. Slugs are lowercase from here on. |
/blog/post?id=482 | /blog/post-title | Edge or client | Redirect rules match paths, not query strings. Meaning that lives after the ? is handled elsewhere. |
/docs/v1/getting-started | /docs/getting-started | 301 · wildcard | A version prefix nobody maintains any more. One rule retires the whole tree. |
/api/… · /login · /app/… | Left alone | Do not touch | The application still answers here. A greedy rule takes the product down while the website looks fine. |
/en/pricing | /pricing | 301 · wildcard | Locale prefixes survive only if the new site is genuinely localised. Otherwise they collapse. |
/pricing/ | /pricing | Normalise | Pick one trailing-slash form and enforce it. Two forms of one page is two rows in an index. |
/sitemap.xml | Regenerated | Rebuilt | The new host generates its own. If the application owns paths on the same domain, the sitemap has to describe both. |
Scroll the table sideways to read every column.
Query strings are invisible to path rules
A platform redirect table matches on the path. If your old URLs carried their meaning after the ? (an article id, a locale, a filter that got indexed) no amount of rules on the new host will see it. Those are handled at the edge, where the full URL is available, or caught in the browser on landing. Either way it is named in the plan rather than discovered from a 404 report.
The application’s paths are excluded, and proved excluded
/api, /login, /app, the webhook endpoints and anything else your product answers on are written into the map as exclusions and then tested as exclusions. This is the single failure on this route that takes a product offline while every marketing page looks perfect.
Cookies, headers and the boundary
Moving part of a domain to a new host changes the surface that cookies are scoped to and the headers each side sends. Session cookie domain, CORS, and any content security policy that now has to allow the scripts the new front end loads: all three are verified on staging by your engineers, not discovered by a customer.
Six phases, and the second one is an engineering decision
Most projects run four to eight weeks end to end, across discovery, design, build, QA and launch. Timelines hold because the sequence is the same every time. This route front-loads two phases before any design exists: what the system actually answers, and where the boundary is going to sit.
Map the surface
Every route the current system answers, sorted into content and application. Taken from the router or the reverse-proxy config, then reconciled against the sitemap, Search Console, analytics and the access logs, because the config describes what is intended and the logs describe what is actually requested.
YoursRead access to the route table or the repo, and a window of production access logs.
Draw the line, pick the arrangement
Subdomain, subdirectory behind an edge proxy, or a separate domain, decided here, in writing, with the person who owns the infrastructure in the room. Every URL decision downstream depends on this one.
YoursA decision from engineering, not only from marketing. This is the phase that goes wrong silently.
Model the content
Which content belongs in a CMS a marketer can edit, which was only ever hard-coded in a template, and which is generated from your database and therefore is not moving anywhere.
YoursHalf an hour with whoever writes the pages, and whoever owns the data behind them.
Build with the boundary in place
The Webflow build on a staging domain with the split rehearsed on staging host names, proxy rules, certificates, cookie scope and headers exercised rather than assumed to be a launch-day formality.
YoursA staging environment for the application side, and someone who can change DNS quickly.
Parity, map and headers
Page-by-page parity against the live site, every redirect rule fired against the real URL list, the application’s paths explicitly excluded and proven excluded, and cookies, analytics and security headers verified across the boundary.
YoursYour engineers testing the application through the new arrangement, on the real staging host.
Cut over, watch both systems
TTL dropped ahead of the switch, DNS changed, sitemap submitted. Then two things are watched rather than one: Search Console and the 404 log for the site, and the application’s own error rate for everything behind the line.
YoursNothing on the day, other than keeping your usual alerting where you can see it.
The standard the front end is held to afterwards
None of our case studies is a custom-code migration, and we are not going to dress one up as one. If your team already builds fast pages, that is the bar a rebuild has to clear rather than a benefit it can claim, so here is the bar, in the numbers we hold ourselves to, and one build to look at.
- 99Lighthouseperformance, a11y, best practices
- 0.9LCPtarget is under 2.5s
- 0.00CLSzero layout shift
- 99.9Uptimemonitored, alerted, resolved
If your current site already clears that bar, say so on the first call. It removes performance from the list of reasons to move and leaves the real one, whether your team can publish a page without a deploy, which is a much better argument to have.
When you should not migrate at all
The person reading this page is often the person who built the thing, so the argument for keeping it deserves to be made properly rather than waved at. Any one of these six is enough on its own.
The site is the product
If what a visitor uses and what you sell are the same artefact, this is not a website project. Moving the marketing shell may still make sense; moving the thing itself does not.
You ship it every week
A team with code review, tests and a deploy pipeline already has a safety net Webflow does not offer. Trading branches and pull requests for a visual editor is a real loss, and it should be a deliberate one.
It renders on the server, per visitor
Personalised pricing, entitlement-aware pages, anything assembled from a session. There is no version of that which becomes a static publish, and pretending otherwise ends in an iframe.
Compliance is written into your hosting
Data residency, retention, processing terms, a certification your customers ask about in procurement. Those commitments are contractual, and a platform change has to match them before it is even discussed.
The complaint is the CMS, not the code
If the real problem is that marketing cannot publish without a developer, a headless CMS behind the front end you already have may fix it in a fortnight for a fraction of the cost. We will say so.
Nobody has agreed where the line falls
A migration that starts before the boundary is decided turns into an argument in week five, with a half-built site on one side of it. Decide first; build second.
The case for moving is equally specific: your marketing team cannot publish a page without a developer, the front end is the part your engineers least enjoy owning, and nothing on the pages in question needs a server to render. If all three are true, this is a good move. If any of them is not, keep it in the repo and we will tell you so on the call.