Webflow Memberships After the Sunset: Moving Gated Content and Member Data

The short answer

Webflow sunset User Accounts on 29 January 2026. Webflow's wording is unambiguous: the functionality "will no longer be available on all Webflow sites in which it's currently in use."

So the question this page used to answer no longer exists. Nobody is migrating off a live Webflow gating product, because there has not been one for six months. If your site still puts content behind a login today, you are already running something else: a hosted gating tool, an auth SDK dropped into custom code, Webflow's page password protection, or a members area that quietly moved off the Webflow site entirely.

That makes the real job narrower and more concrete than the one this page used to describe. It is four things:

1. Port whatever replacement you were forced into.

2. Get the member records out of that tool.

3. Rebuild per-page access logic as explicit route rules.

4. Decide, route by route, how login state coexists with statically rendered pages.

None of that is urgent. The sunset already happened and you already survived it. This is cleanup of a workaround, done on your schedule.

Start by finding out what you are actually running

Six months of workaround tends to leave more than one mechanism in place. Before choosing a destination, write down which of these are live on the site right now:

• A hosted gating tool. Memberstack, Outseta or similar, loaded by a script tag and holding your member table on its side.

• An embedded auth SDK. Someone added a provider's JavaScript to site-wide custom code and wrote conditional show and hide logic around it.

• Webflow page password protection. Still a live Webflow feature and listed on the Ecommerce and Site plan comparison. A shared password is not a member system, but plenty of sites fell back to it.

• An off-site members area. The gated half moved to a subdomain on another stack and the Webflow site became the marketing shell.

Most sites have two of these. The one that gets forgotten is usually the third: a single page that someone protected by hand during the sunset and never revisited.

What comes out, and what does not

Member records come out. Email, signup date, tier or plan, role, and whatever custom fields your rules read. Export through the gating vendor's API rather than the CSV button if one is available, because the CSV usually drops custom fields and always drops the vendor's internal user ID. You want that ID: it is the key that reconciles a member against a billing record.

Password hashes do not come out. No hosted gating tool exposes raw hashes through an export or an API, and without the raw hash and its algorithm there is nothing for a destination provider to import. Providers like Clerk and Auth.js do support importing pre-hashed passwords, which is why the claim gets muddled, but that path needs source material a closed tool will not hand over.

So every member sets a new credential on first login. That is a real friction cost and it is worth designing around rather than announcing on the day.

Nothing comes out of Webflow itself. Webflow's code export excludes User Accounts, and did so even before the sunset. It also excludes CMS content, Ecommerce, password protection, form submission processing and site search. If your plan assumed the export button would hand you the members area, it will not.

The reset window is the part to plan

The technical work here is small. The member-facing work is what determines whether the migration reads as an upgrade or as an outage.

What to build:

• Sign-in by emailed link as the default path on cutover day. It removes the password step entirely for anyone who takes it, which is most people. Keep password sign-in available for the members who want it.

• A soft window with both paths live. Run the old gating and the new auth in parallel for a couple of weeks so a member who arrives late still gets through rather than hitting a wall.

• Sender reputation on the new domain before you need it. Reset and sign-in emails come from a new sending domain the moment you cut over. Configure SPF, DKIM and DMARC, and send real mail from that domain in the weeks before, so the one email that matters is not the first one that domain has ever sent.

• A stated instrument for whether it worked. Track completed first sign-ins against the imported member count, daily. That single number tells you whether to hold the window open longer.

What not to do is fire one email on cutover day and treat the reset as an announcement. Members who hit a failed login on a site that worked yesterday do not file a support ticket, they leave.

Per-page access logic: from a toggle to a rule

In the Designer, gating was a property of a page or a Collection item. In a codebase it is a rule that something has to run, and the something has to cover every path.

The shape that holds up:

• Deny by default in one place. Middleware that protects a path prefix, with public routes listed explicitly, fails safe. The inverse, listing protected routes, fails open the first time someone adds a page.

• Separate authentication from authorization. "Is there a valid session" and "is this member allowed this item" are different checks. Tiers, roles and per-item rules belong in the second one, near the data.

• Protect the API, not only the page. A route guard that renders a redirect while the underlying data endpoint still answers an unauthenticated request has not gated anything. This is the most common real defect.

• Test it as a matrix. Every gated path, hit with no session, a member session, and each tier or role above it, asserting the expected status code. Run it in CI. The route that breaks is always the one added after launch.

Login state on statically rendered pages

This is the part that surprises teams coming from a visual builder, where every page was rendered per request and personalization was free.

A statically rendered page is built once and served from a CDN to everyone. There is no request-time user, so there is nothing to render a name, a tier or a members-only body into. You get three options, and the right answer is per route rather than site-wide:

1. Keep the page static, resolve the session in the browser. The shell ships from the CDN and the gated content arrives from an authenticated API call after load. Fast, cacheable, and the protected content is never in the HTML. The cost is a visible state change after load, which you handle with a skeleton rather than a layout jump.

2. Opt the route out of static rendering. The page renders per request behind a session check, so gated content is in the first byte. The cost is that the route no longer benefits from the CDN, so reserve it for routes where that matters.

3. Check the session at the edge. Middleware reads the session cookie before anything is served and either passes the request through or redirects. This keeps public routes fully cached while gated routes are decided close to the user.

The anti-pattern worth naming: rendering protected content into the static HTML and hiding it with CSS or a script. It is the direct translation of conditional visibility, it looks correct in a browser, and the content is sitting in the page source on a public CDN.

Choosing a destination

Four are worth shortlisting, and the differences are about who holds the session and where the member table lives.

• Clerk. Hosted sign-in UI, session management, MFA and organizations, with first-party SDKs. The least to build, and the member table lives on Clerk's side with your app reading it through their API.

• Supabase Auth. Auth sitting on a Postgres database you also own, so member rows are just rows you can join against your own data. The right pick when access rules depend on application data rather than just a tier.

• Auth.js. The session layer in your own repository, with your own database behind an adapter. No vendor account in the request path. More to build, most control, and the least to unpick later.

• WorkOS. Built for enterprise SSO and SCIM provisioning. If SAML and directory sync are the requirement, this is the one that does that job directly rather than as a plan tier.

All four are ordinary code in your repository once integrated, which is the part that matters after launch: the access rules live in files that can be reviewed, tested and changed.

What this costs

A Webflow migration for a 50 to 100 page site runs $5,000 to $25,000. Gated content and member data push a project up within that band rather than sitting outside it as a separate line. What moves the number is the access model, not the member count: a single logged-in or logged-out state is close to free, while tiers, per-item rules and SSO are where the work is.

For how the band breaks down by site size and scope, see the Webflow migration cost breakdown.

Where this fits in a wider migration

Gating is one workstream inside a larger project, and it is rarely the one that sets the schedule.

For what leaving Webflow involves overall, including what the code export does and does not include, see the complete Webflow to code migration guide.

For the sequence and the pre-launch checks, including the redirect and rendering work that runs alongside this, see the Webflow migration checklist.

What to do next

Send your site link through the free review form below with a note on how you are gating content today and roughly how many members you hold. We will come back with the auth destination we would actually pick, the access model it implies, and a fixed-price scope. If the honest answer is that replacing the gating tool alone is enough and the rest of the site should stay where it is, we will say that.