The decision to migrate to Webflow is normally made for good reasons. Maintenance overhead on the old platform, plugin conflicts, a developer dependency for tasks the marketing team should handle themselves and a performance ceiling that takes disproportionate effort to push past are all real problems, and Webflow addresses most of them. The migration itself creates a separate set of problems, and most businesses discover them after launch.
The technical work is the smaller part of the cost. Most of it sits in the decisions the brief never asked anyone to make. Below are the mistakes we see most often in how established NZ businesses decide on, scope and plan a move to Webflow, starting with the ones made before a single page is built.
Mistake one: migrating to fix a problem the platform didn't cause
A business frustrated with its website reaches for the platform as the explanation. The site doesn't generate enquiries, the messaging feels dated and the pages are slow, so the plan becomes a move to Webflow. Some of those problems belong to the platform. Others belong to the positioning, the content and the structure of the site, and they will move to Webflow intact unless someone deals with them.
Separate the two lists before committing. Slow pages, update headaches and a team that can't edit content are platform problems Webflow solves. A homepage that doesn't say who the business is for, service pages that read like every competitor and a contact path with too much friction are commercial problems that need a brief of their own. Our piece on why most website redesigns fail to move the needle covers the second list in detail. A migration scoped only against the first produces a faster version of a site that still doesn't sell.
Mistake two: choosing between a straight move and a redesign by default
A migration can be a faithful rebuild of the existing design in Webflow, or a redesign delivered on the new platform. Both are legitimate, and they carry very different costs, timelines and risks. The mistake is drifting into one without deciding.
A straight move keeps the scope tight and the SEO risk low, because pages, content and structure stay close to what Google already knows. It suits a business whose site works commercially and whose problems are mostly with the platform. A redesign makes sense when the commercial problems are as large as the platform ones, since every page is being rebuilt regardless and changing the design at the same time costs less than doing it again in two years. The middle path causes trouble: a brief that says "migrate" while stakeholders expect a redesign, which surfaces as scope creep halfway through the build. Agree which project you are running in writing, before any design starts.
Mistake three: treating URLs as a launch task
Every page on the current site has a URL, and some of those URLs have been live for years, earned inbound links and hold positions in Google's index that took sustained effort to build. When a migration changes them without mapping old to new, Google treats the old pages as gone and the rankings attached to them fall away within weeks.
This goes wrong when URL structure is treated as a post-launch item instead of an architectural decision made at the start. Webflow organises CMS content under collection paths, so its URL conventions may not line up with the patterns on the old site. Resolving those conflicts means making decisions about content structure that change the scope of the project, and making them late means making them under pressure, which is how redirects get missed. The full sequence of benchmarking, mapping, redirects and post-launch monitoring is set out in our guide to migrating to Webflow without losing SEO. At the decision stage, put the redirect map into the scope and the budget from day one.
Mistake four: carrying every page across
A migration forces a reckoning with content that most businesses would happily defer forever. Every page has to move or be retired, so every page has to be assessed, and the question a migration makes unavoidable is whether each one belongs on the site at all.
Most sites accumulate content for years without any system for retiring it. Blog posts on time-sensitive topics stay live because nobody removed them. Service pages for offerings the business dropped are still indexed and occasionally linked from other pages. Thin category and tag pages exist because the old CMS created them automatically. A migration that carries all of it into Webflow moves the content problem to a faster platform with cleaner design, and the issues that were dragging down search performance before will keep doing it.
The migration is the right time for a content audit. Identify pages with meaningful traffic or ranking positions and protect them. Consolidate or retire thin and outdated content, then build the Webflow CMS around the content that should exist instead of the content that currently does. This adds scope. It also removes a drag on performance that would otherwise follow the business onto the new platform.
Mistake five: copying the old structure into the CMS
Webflow's CMS is built around collections, which are defined content types with consistent fields and templates. Setting them up well means deciding how content is organised, what fields each type needs and how items relate to each other, and those decisions shape how the marketing team can update and expand the site for years.
A collection setup that mirrors the old platform produces a CMS that works technically and frustrates everyone who uses it. Webflow has its own strengths: reference fields between collections, multi-reference fields for many-to-many relationships and conditional visibility based on field values. A case study can reference the services and industries it relates to, and those pages can then list the relevant case studies automatically. Our explainer on Webflow CMS collections shows how this works in practice.
Hold the CMS conversation before the build begins. What content types does the business need, how do they relate, what must the marketing team be able to update on their own and how much complexity can they realistically manage? These are business and workflow questions with technical answers. Getting them wrong is expensive after launch, because fixing a collection means rebuilding it, remigrating its content and updating every template that uses it.
Mistake six: finding the integration gaps after build
On most established sites, a share of the functionality comes from plugins, embedded tools or custom code: forms feeding a CRM, booking tools, popups and lead capture, event listings, gated downloads. Each one needs a home on the new site, and the migration plan should list every dependency with its replacement.
For NZ businesses this often includes forms that write directly into a CRM such as HubSpot or Pipedrive, booking through a scheduling tool and lead capture connected to an email platform. In Webflow these are reconnected through native forms with an automation tool such as Zapier or Make, through the vendor's own embed or through a native Webflow integration where one exists. We scope and manage those connections with the relevant vendor or partner as part of the project. None of these is hard to solve, and every one of them belongs in the brief, because a dependency discovered during build delays launch or forces a workaround nobody planned for.
Mistake seven: assuming the team will pick up the Editor
Giving the marketing team control over content is one of the most cited reasons for moving to Webflow, and it is a real advantage that only shows up with onboarding and workflow design.
The Webflow Editor works differently from the dashboard most teams know. CMS items are edited differently from static page content. Some design elements can only be changed in the Designer, and shared components update across the whole site when edited, which is powerful once the team understands what they are touching. A business that skips this ends up with a team who can't make the updates they expected to make, and the developer dependency the migration was meant to remove carries on in a new form. Include a handover session, written documentation and a clear split between what is editable in the Editor and what needs Designer access in the scope.
Mistake eight: budgeting for the build and nothing after it
A migration budget that covers the project and stops at launch leaves out the costs that arrive straight after it. Webflow charges for the site plan and for Workspace seats, and the right plan depends on CMS item counts, traffic and features such as localisation. Plan for twelve weeks of post-launch SEO monitoring, a round of fixes once real visitors are using the site and an allowance for the improvements the team will want once they see what the platform makes possible. A support arrangement agreed before launch costs less than one negotiated in a hurry when something needs changing.
What a well-scoped migration produces
A well-run Webflow migration produces a site that is faster, easier to maintain, more capable visually and far less dependent on developer time for routine updates. Getting there means scoping URL mapping, a content audit, CMS architecture, integration gaps, team onboarding and post-launch support into the project from the start. A migration that skips them produces the old site on a new platform with the same content problems, an incomplete redirect map and a CMS that doesn't match how the team works. If you are weighing the move, our Webflow website design team can scope it with those decisions made up front.
Common questions
Should I migrate my website to Webflow or redesign it on my current platform?
Migrate when the platform itself is causing the problems: maintenance overhead, plugin conflicts, slow pages or a team that can't edit content. Redesign on the current platform when it works well and the problems are with messaging, structure or conversion. If both apply, a migration combined with a redesign is the more efficient project, because every page is being rebuilt anyway.
What should a Webflow migration brief include?
At a minimum: a benchmark of current search performance, a full URL inventory with a redirect plan, a content audit deciding what moves, merges or retires, the CMS collection structure, a list of every plugin and integration with its replacement and a plan for training the team. Post-launch monitoring and support belong in the brief too, since that is when most migration issues surface.
Is Webflow a good fit for every business website?
Webflow suits service businesses, professional firms and brands whose site exists to win enquiries and build reputation. A business selling products online at volume belongs on Shopify, and very large content libraries or heavy custom functionality need checking against Webflow's CMS limits first. Our comparison of Webflow and Shopify covers where the line falls for businesses that do both.
How much does it cost to migrate a website to Webflow?
Cost depends on the number of pages and CMS items, whether the design changes and how many integrations need reconnecting. A straight move of a small brochure site sits at the lower end, while a large content library combined with a redesign sits well above it. Ask for a quote that itemises URL mapping, content migration and onboarding, since those are the parts most often left out.
Can my team manage a Webflow site after the migration?
Yes, with the right setup and training. The Webflow Editor lets non-technical staff update pages and publish CMS content without touching the design, provided the CMS was structured around how the team works and the handover covered what is editable where. Without that preparation, teams fall back on the developer for routine changes, which defeats one of the main reasons for moving.
