Wix Headless Migration: What It Is, How It Works, and What to Watch For

Wix has introduced a new Headless Migration flow that brings a once developer-heavy process much closer to everyday site owners. Instead of manually piecing together a custom frontend and connecting it to Wix on your own, you can now start the migration directly from your Wix dashboard, generate a new frontend with an AI coding tool, and keep your existing Wix business data in place while you build.

What Wix headless means

At its core, headless means your backend and frontend are separated. Wix provides the backend layer, including CMS collections, business data, and app-connected functionality, while you decide how the frontend should be built and displayed.

This is part of the broader headless CMS model. Unlike the standard Wix Editor or Wix Studio experience, where the visual builder guides how your site is structured, headless gives you the freedom to build the frontend in code and connect it to Wix through APIs.

What makes Wix headless especially interesting is that it goes beyond content. Wix also brings business solutions like bookings, payments, stores, members, and forms into the picture. That means you can keep a backend you already know while using a completely custom frontend.

Why this release matters now

Wix Headless itself is not brand new, but the migration flow is important because it reflects a shift in accessibility. In the past, headless projects were mostly for developers who were comfortable setting up hosting, connecting APIs, and debugging custom builds. With modern AI coding tools, more of that work can now be scaffolded for you.

That does not make headless a one-click no-code feature. It does, however, make the process more approachable for users who want a custom frontend without abandoning the Wix backend and dashboard.

Wix-managed headless vs self-managed headless

• Self-managed headless means Wix powers the backend, but you host the frontend yourself on a platform such as Netlify, Render, Hostinger, or another hosting provider.

• Wix-managed headless means Wix hosts the frontend for you, while you still build it in code.

• The new migration flow is tied to the Wix-managed direction, which is why it can start directly inside your existing dashboard.

That distinction matters because the new experience is really about reducing setup friction. Instead of stitching together a project from scratch, Wix now prepares the migration from inside the same dashboard you already use.

Where to find Wix Headless Migration

In the demo, the migration option appeared inside the site dashboard under Settings, then in the Development & Integrations area, inside Headless Settings. Scrolling down revealed a Headless Migration section with a Start migration button.

This same area was previously used for more custom headless connections, so the new addition is effectively Wix streamlining a process that used to require more manual setup.

Who can use it right now

Before you expect to see the migration tool, there are several current requirements and limitations mentioned in the documentation and observed in the demo.

• Your Wix account language must be set to English. This applies to the account, not just the site content.

• You must be the site owner. Collaborators and co-owners may not be able to run the migration.

• Your site must have a custom domain, which also implies an eligible paid plan and an attached domain.

• If your site uses Wix Stores, it must be on the new store catalog. Older store setups can block migration.

• Sites using certain custom components from an app project may not be able to migrate yet.

That Wix Stores limitation is one of the biggest practical blockers. In the walkthrough, older catalog setups were described as especially problematic because there currently is not a simple path to move between the older and newer catalog systems.

App compatibility is a real consideration

The demo also surfaced another important detail: not every app or frontend feature will carry over cleanly to a headless build. Wix shows connected business data and apps during setup, and it may also flag apps that will not work in the headless version.

• Examples mentioned as not working included Referral Program, Pro Gallery, Wix Donations, Wix Comments, Wix Loyalty Program, and Wix Forum.

• Some of these are more obviously frontend-dependent than others, so compatibility will vary by feature.

• In some cases, a missing app is not necessarily a deal-breaker if you are comfortable rebuilding the experience in a custom way.

The key takeaway is simple: do not treat migration as a pure design conversion. It is a functional migration, and app support needs to be checked before you commit.

What happens when you start migration

Once the migration starts, Wix creates the headless business setup and connects supported data and apps. In the demo, that setup completed quickly, after which the next step was to build the new frontend.

Wix also makes a few reassuring promises during this flow. Your current site stays live while you build, your dashboard remains the same for both frontends, and your business data continues to live inside Wix. That makes the experience feel similar to a branch or staging workflow rather than an immediate replacement.

• Your current live site remains live until you choose to switch.

• Your existing Wix dashboard stays in place for managing data.

• SEO and analytics stay with the current live site until the new frontend goes live.

• After the switch, the new frontend becomes responsible for SEO setup, including metadata and page structure.

• Wix says your current plan remains while you build and preview, but you should still watch for pricing or plan implications later.

How the AI-assisted build works

After setup, Wix provides a prompt that you can paste into an AI coding tool. In the walkthrough, that prompt was tested in both Cursor and ChatGPT Work. The prompt was longer than the short text shown in the dashboard and included instructions plus a downloadable project path.

This step is one of the most important to understand: Wix is not visually recreating your site for you inside the dashboard. It is handing off project context so an AI coding environment can generate and wire up the new frontend.

During the test, ChatGPT required a Wix device login step to continue. After that, it was able to generate a preview. Cursor also generated a project, but needed more hands-on debugging before the preview worked properly.

What the first AI-generated previews looked like

The two AI tools produced noticeably different first results. ChatGPT Work created a functioning preview fairly quickly, but much of the navigation linked back to the original live site. It appeared to understand the backend data, yet it did not fully rebuild the frontend experience around the current domain and flows.

Cursor, by contrast, produced a version that was closer to the original site’s branding and structure. It was rough at first and threw an internal server error, but once the project was debugged and rebuilt correctly, it delivered a more complete experience.

That rebuilt Cursor version handled booking flows, checkout behavior, and blog content more convincingly than the ChatGPT version in the initial test. A real booking request was submitted through the new frontend and appeared in the Wix dashboard, which confirmed the core integration was working.

The biggest practical lesson: expect debugging

One of the most useful parts of the walkthrough was seeing something go wrong. Cursor initially published a broken preview with an internal server error. The issue was not that Wix headless failed entirely, but that the generated project had not been rebuilt properly before release.

After running the build step and then releasing again, the preview worked. That is a valuable reminder for anyone trying this feature: AI-generated does not mean production-ready. You should expect to inspect, test, and refine what gets created.

• A preview can exist even when the generated project still has build issues.

• If an AI tool creates working pages but wrong navigation, you may need to explicitly tell it not to link back to the old site.

• A tool that gives you local file access and debugging visibility may be easier to fix than a tool that only returns a hosted output.

• Initial results can be promising without being ready to publish.

What happens when you complete migration

When you click Complete migration in the dashboard, Wix does not instantly switch everything live without warning. In the demo, that button led to another step and provided a final command to run from the project when you are actually ready to finish the migration.

Wix also notes that when the headless site goes live on your current domain, your previous Wix Studio site becomes unpublished, not deleted. That means you can switch back later if needed. One caution shown in the flow: visitors who are not signed in as members may lose cart contents during migration.

Should you migrate to Wix headless now

If you want a more custom frontend, want to keep Wix as your backend, and are comfortable working with an AI coding tool, this new migration flow is a meaningful step forward. It lowers the barrier, keeps your dashboard familiar, and provides a structured starting point instead of forcing you to build the whole setup from scratch.

If, on the other hand, you expect a perfect one-prompt conversion with zero debugging, you will likely be disappointed. The demo showed real progress, but it also showed the current reality: compatibility checks matter, some apps do not carry over, and the generated frontend still needs review before launch.

Final thoughts

Wix Headless Migration is not a magic button, but it is a strong sign of where Wix is heading. The company is clearly trying to make headless more accessible by combining its managed hosting approach with AI-assisted frontend generation. For the right site owner or developer, that could be a very practical path to a more flexible site architecture.

The safest approach is to treat this as a guided rebuild: check eligibility first, review app compatibility, generate the new frontend, test every key flow, and only then complete the migration. Used that way, the new workflow looks genuinely useful rather than just experimental.