Clients
Kevin, Los Angeles · “the flexibility in their expertise was really key to make things work”Dominik, Australia · “a clean, scalable backend that now powers our real estate enquiry responder”Pascal, Austria · “superb knowledge of both Weweb and Xano”Operations lead, Australia · “one of the first holidays EVER where no groups have turned up at the wrong cinema”Kevin, Los Angeles · “the flexibility in their expertise was really key to make things work”Dominik, Australia · “a clean, scalable backend that now powers our real estate enquiry responder”Pascal, Austria · “superb knowledge of both Weweb and Xano”Operations lead, Australia · “one of the first holidays EVER where no groups have turned up at the wrong cinema”
Migrations · WeWeb

To move a WeWeb app to code, you rebuild the front end screen by screen in a framework like Next.js, keep the backend it already uses when that backend is Xano or Supabase, and run both versions on the same data until the team stops noticing the difference.

WeWeb can export your app as a Vue.js app to host yourself, and its MCP server lets AI tools like Claude Code edit the project. What the export doesn't give you is a two-way street: changes made to the exported code don't go back into the editor. If your team wants to work in a codebase from now on, the front end moves to code, and with an external backend it's smaller than it sounds: the data, the rules and the users stay where they are. If the app runs on WeWeb's own backend, launched in 2026, that backend is part of the platform too, so we plan that part first.

When it makes sense

  • Your team would rather work in a codebase, with reviews and tests, than in a visual editor
  • You want to host and change the front end without depending on a platform plan
  • The app has grown into custom code inside the editor, and that's where most changes now happen

When it doesn't

  • The app does its job and changes are rare
  • What hurts is the data model or the backend: a new front end won't fix that
  • You're still finding out what the product should do

01

We list every screen, filter and action, and agree that nothing should feel different on launch day.

02

We rebuild the front end against the same backend, so on Xano or Supabase there's no data to migrate. If the backend is WeWeb's own, we plan that part first.

03

The team uses the new version on real data at a separate address, while the old one stays available.

04

When they've stopped noticing the difference, the main address switches. Then come the changes that were waiting.

Dates and time zones: a library that decides which day it is in the browser's time zone can move a session to the day before, and only for users in one country.

Behaviour nobody wrote down: default sorting, saved filters, what a double click does.

Addresses written into the app (logins, redirects, payment links) that have to point at the new one.

Bulk actions across pages: selecting rows on page three has to work exactly as it did.

From our work

A group bookings platform, from a WeWeb front end to code.

We rewrote a group-outings platform from a WeWeb front end to code, on the same Xano backend. The rule before launch was that nothing should feel different to the people using it. After the first full season, the person who runs operations wrote to say it was one of the first holidays where no group had turned up at the wrong cinema.

Group bookings
bookings
Manage bookingsSummer holidaysImports
Confirm session
OSHC ServiceCinema LocationMovieProposed DateTotal PeopleReceived by CinemaStatus
Sunnyside OSHCNorthgate · Screen 3The Lost KiteTue 14 Jan42✓Confirmed
Harbour Kids ClubBayside · Screen 1Robo Pals 2Tue 14 Jan58✓Confirmed
Wattle Grove CareNorthgate · Screen 5Ocean FriendsWed 15 Jan37✓Confirmed
Riverbend OSHCEastland · Screen 2The Lost KiteWed 15 Jan64✓Received
Maple St KidsBayside · Screen 4Robo Pals 2Thu 16 Jan29✓Confirmed
5 of 1,284 bookingsSummer · 2026

Can't I just export my WeWeb code?

You can. WeWeb exports your app as a Vue.js app you can host yourself on a paid plan, and if the export is what you need, that may be enough. Changes made to the exported code don't go back into the editor, though, so if your team will keep working in code, we look at whether the export is a good base or whether rebuilding from the live app is cleaner. It depends on the app.

Does the backend have to change too?

Not if it's on Xano or Supabase and it works: it stays, the new front end calls the same endpoints, and there's no data migration. If the app uses WeWeb's own backend, that's part of the platform too, so we plan it first.

Will my users notice?

They shouldn't. Same screens, same flows, same data on launch day. The improvements come after the switch, once everyone trusts the new version.

How long does it take?

It depends on how many screens there are. Our last two took between two and four months from the first commit to the team working in the new version. The price is fixed before we start, after a short review of the app.

Who owns the code?

You do. The repository, the hosting and the third-party accounts are in your name from the start or move there before we finish.

Other migrations

Fifteen minutes on a call. If it's not a fit, we'll say so and point you somewhere better if we can.

Book a 15-minute call
SectionHome
Book a call