Every WordPress migration starts with a plugin list, so start there: export yours and mark each plugin as decoration or load-bearing. A site where the plugins are decoration can move in a couple of weeks. A site where one plugin quietly runs bookings, invoicing or a members area is not a migration at all. It is a rebuild that gets priced as a migration, and that gap is where projects stall.
Should you leave WordPress in 2026?
Leave WordPress when the plugin surface costs you more to maintain than the platform saves you, not because someone told you the project is fading.
It isn't. W3Techs reports WordPress on 58.7% of websites whose content management system is known, and 40.2% of all websites (as of 30 September 2026). WordPress.org's release archive shows 7.0 on 20 May 2026 and 7.1 on 19 August 2026, and the roadmap lists 7.2 as planned for 10 December 2026, with a note that projected dates are for rough planning. So two major versions have shipped this year and a third is scheduled. The WordPress developer blog's August 2026 roundup covers the Tabs and Playlist blocks becoming stable and :hover and :focus styling from theme.json, currently limited to the Button and Navigation Link blocks.
The reasons to leave that hold up are duller and more specific. Updates have turned into risk events instead of routine chores. Nobody on the team can safely touch the theme because its author left. Your hosting bill carries a security add-on that exists to compensate for the plugin surface. If you recognise two of those, the maintenance argument is already made.
How many of your active plugins could you name from memory? If the answer is under half, start by deleting before you migrate.
Webflow, headless code or a trimmed WordPress: which exit fits?
Webflow fits content sites where marketers publish without a developer, custom code fits sites where the page is a product surface, and trimming WordPress fits when the plugin count is the real problem.
Webflow's pricing changed this year, and many migration tutorials still quote the old plans. According to Webflow's May 2026 pricing notice, the CMS and Business plans were combined into Premium, which includes 20,000 CMS items and 40 Collections. On the pricing page, Basic costs $15 a month billed yearly and includes 300 static pages but no CMS, Premium costs $25 a month billed yearly, and the Team plan costs $2,500 a month on an annual contract. A blog therefore needs Premium at least.
| Exit path | Recurring cost | Who publishes content | Fits when |
|---|---|---|---|
| Webflow Premium | $25/mo billed yearly (Webflow pricing page) | Marketers, in the Webflow Editor | Content and marketing site with no server-side logic |
| Webflow Team | $2,500/mo, annual contract | Marketers, with workspace and publishing controls | Larger teams that have outgrown self-serve |
| Next.js plus Payload or Sanity | Build cost, then hosting | Marketers, in a headless studio | Programmatic pages, app-adjacent features, data you own |
| WordPress as headless backend | Existing hosting plus a new front end | Editors, in the WordPress admin they know | Large editorial teams that resist tooling changes |
| Trim WordPress instead | Existing hosting | Same as today | The plugin count is the problem, not the platform |
The last row is a real option that nobody sells. If your site is a hundred pages and thirty plugins, deleting twenty plugins is cheaper than any migration in this table and fixes the maintenance pain. It does nothing for the editing experience, though. If your marketing team waits weeks for a landing page, pruning plugins won't shorten that queue.
How do you decide between the paths?
Ask three questions in order. First, who is blocked today: if the answer is marketers waiting on a developer, Webflow removes that queue, while a headless build keeps a developer in the loop for every layout change. Second, is the page a document or a product surface: flat collections of posts and case studies fit Webflow's CMS, but pages generated from data, such as hundreds of location and service combinations, or a front end that shares components and login with an application, point to Next.js. Third, how much of the business lives in plugins: if the honest answer is a lot, price the state-holding parts as a build before you choose a platform for the brochure pages. A common middle path is launching the marketing site on Webflow and moving the parts that outgrow it later. Running WordPress headless behind a Next.js front end suits large editorial teams that won't give up the admin they know, but you keep the WordPress instance, its updates and its security surface, so the maintenance reason for leaving does not go away.
For the fork between a hosted editor and a bespoke build, WordPress versus a custom website goes deeper than a table row can, and the best CMS for marketing sites shows where each content model wins. The WordPress alternatives list is the wider field, and the WordPress to Next.js migration guide covers the code-first route. If the term is new, a headless CMS is simply a content store that delivers to any front end through an API.
How do you migrate from WordPress to Webflow without losing rankings?
Export the full URL inventory first, map every live URL to a destination, and launch the redirects in the same deploy as the site.
Google's site move documentation says 301 and other permanent redirects don't cause a loss in PageRank, and that the move's duration depends on the number of URLs and your server speed. Its redirect guide recommends permanent server-side redirects and warns against long chains. So redirects done properly are not where rankings are lost. Gaps are. Work in this order:
- Pull the URL inventory from Search Console, your sitemap and a crawl of the live site. Each source misses different pages, and archives, tag pages, paginated series and author pages are where the gaps hide.
- Record the title tag, meta description and canonical for every URL that earns traffic. None of it migrates by itself.
- Build the content in the new platform with those fields filled as you go, not as a cleanup pass.
- Rewrite internal links inside post bodies to the new paths. Search the exported bodies for your own domain and for href="/.
- Re-add JSON-LD per template as custom code. Google's structured data policies name JSON-LD as the recommended format.
- Ship the redirects with the launch, not after it, and test each rule against the staging domain first.
- Check Search Console coverage weekly for the first two months, because a missed redirect shows up as a crawl error before it shows up as lost traffic.
What breaks quietly during the move?
Three things arrive broken and unnoticed. The first is URL structure. WordPress permalinks are arbitrary, so a site may serve /category/post-name/ or /2019/06/post-name/, while Webflow Collections generate a pattern keyed to the collection slug. You can't reproduce the old shape, only redirect to the new one, so the redirect map is the migration rather than a tidy-up at the end. The second is links written into post bodies. In an export they are plain text, so nothing updates them unless you do, and they will look fine in the Designer while pointing at old paths. The third is structured data. Whatever JSON-LD your SEO plugin emitted disappears with the plugin, and each template needs the markup added back by hand. Rich results then vanish without any warning.
I have worked on the publishing side of a Webflow site I didn't build. On IronLife, a collaborator built the site and I owned the articles and editorial. Publishing inside someone else's collection schema meant respecting their SEO fields and layout constraints rather than redesigning mid-stream. Recommendation: settle those fields in the new template before you import, because they are hardest to change once hundreds of items exist.
How long should you keep the old site?
Keep the WordPress hosting alive, unpublished but reachable, for at least ninety days. That number is my recommendation rather than a Google requirement. You will want it to compare a page that renders wrongly, recover an image nobody exported, or read a meta description that never crossed over. It is cheap insurance next to a missed page.
What replaces the plugins?
Nothing replaces them one for one, and pricing that in early makes the migration go better. Contact forms and basic marketing automation port easily, since Webflow and a Next.js build both handle them natively or through a service you probably already pay for. The trouble sits in plugins that hold state: bookings, membership tiers, order history, invoices, anything with its own database table. Those become one of three things: a SaaS subscription, an integrated service, or code you own.
The Pizzeria Bestek case study shows the third answer taken to its end. The restaurant had been renting its ordering flow from a third-party platform, and the rebuild on React and Supabase gave it ownership of every credential; the case study puts each order at 100% revenue instead of roughly 70% after commission, and reports the system running since September 2025. The real question under a WordPress migration is which parts of your business you are willing to keep renting.
Open Search Console, sort your pages by clicks and export the top fifty URLs. If more than a handful sit at permalinks Webflow can't reproduce, you have found the first line item of your quote. For budgeting the rest, what a website costs and practical advice for a successful website project are the two longer reads, both in Bosnian.