The roadmap you are on is not yours
On December 11, 2024, Webflow announced it was deprecating two features. Logic, the native automation builder, went dark on June 27, 2025. User Accounts, the built-in membership system, went dark on January 29, 2026. Both announcements came with partner discounts and a list of certified agencies, which is more grace than most vendors offer. It still meant that anyone who had built a signup flow on Webflow's own primitives had a deadline they did not set.
A deprecation is a repricing you cannot decline
Webflow's help center is blunt about what happened to Logic. As of June 27, 2025, you cannot add new flows, existing flows are disabled, and forms that were wired to a flow reverted to plain Webflow forms. The recommended replacements were Zapier and Make, both third party, both metered. Make's migration offer was two free months on a Pro plan with 20,000 monthly operations. After the free months, that automation is a line item you did not have before.
I want to be careful here, because building on Logic was a reasonable call. It was native, it was included in what you already paid, and it did not require a second vendor account. The cost only shows up later, when the feature's lifespan turns out to be shorter than the product's. Webflow's own framing was that it wanted to focus on the website experience platform and hand automation to its app partners. That is a coherent strategy. It just is not a commitment to you.
Airtable ran the same play on a longer clock. It began deprecating user API keys on January 18, 2023 and finished on February 1, 2024. Keys stopped working against the API, and every integration had to move to personal access tokens or OAuth. Thirteen months is generous notice. It is also thirteen months of work you scheduled for reasons that had nothing to do with your customers.
The thing you own is the thing you can freeze
Custom code deprecates too. Next.js ships breaking changes, Postgres drops functions, Node retires versions. The difference is who holds the clock. When a library you depend on goes stale, you can pin the version and upgrade next quarter, or fork it, or leave it alone for three years while it keeps working. None of those options exist when the runtime belongs to somebody else.
That is most of what Stay World Class bought when we moved them off Webflow and Xano onto Next.js, NestJS and Supabase. The performance numbers were the visible part: Lighthouse went from 55.91 to 91 out of 100, and LCP came down 77 percent. The quieter part was the four stage ETL that preserved their legacy record IDs as PostgreSQL UUIDs, so the data kept its history instead of starting over. Nobody can now disable their auth on a date of their choosing.
The honest accounting is that you trade one risk for another. Owning the stack means owning the upgrades, the security patches, and the on call rotation. A deprecation notice at least arrives with a date and a migration guide. What you get back is the right to ignore it.
When staying put is the right answer
If the features you depend on are the platform's core business, deprecation risk is close to zero. Webflow is not going to sunset the CMS or hosting. Those are what it sells. The features that died were sitting at the edge of the roadmap, and you can usually tell which ones those are by checking whether the vendor's pricing page leads with them.
If your automation is one Zapier flow and your auth is a Google login, rebuilding that on your own stack costs more than it saves. A rewrite earns its keep when the platform constrains something you are actively trying to change, not when a feature you barely use gets retired. Most teams should do nothing until the second deprecation notice arrives, because that is the point where the pattern stops being bad luck.
The question worth asking once a year is short. Which parts of the product would stop working if the vendor sent an email tomorrow, and how long would it take to rebuild them? If the answer is a weekend, stay. If the answer is a quarter and you cannot name who would do the work, you already have a migration project. You just have not scheduled it.
