What "migrating" can mean
When someone tells us they want to migrate off Zite, the question we ask elsewhere, which of four kinds of migration they mean, has a shorter answer here. Moving the hosting, moving the backend on its own, and owning the process through a repository all depend on the app's code running somewhere other than the builder. Zite's help centre describes export as moving an app or a workspace between Zite accounts; its FAQ said in May 2026 that the code "currently will not run out-of-the-box in an external environment", and that an export for other platforms might come in future. At the time of checking it had not, and we would plan on the current position.
So a Zite migration is the fourth kind, a rebuild, with the data moved and the running app as a very precise specification. That is a different project from the move most of this site describes, and it is worth being clear about before reading on: the cost sits in the screens, roles and workflows that have to be made again, and the monthly running cost in the table further down is the smaller half of the decision.
Why building on Zite was a reasonable call
A year or two ago the choice was between a builder that could produce a working app in a weekend and a development quote that started at five figures and ended months later. Picking the weekend was sensible. The app exists, it has users, and those users have taught you things about the business that no specification would have. That knowledge is worth more than the code, which can be rebuilt.
The feeling that comes with outgrowing a builder tends to be a kind of embarrassment, as if the right move had been obvious all along. From where we sit it looks like a good decision that has done its job, which is what early decisions tend to do.
What usually moves cleanly
The data is the part that moves, and Zite documents the route. Each table exports as a CSV from its menu, following whichever view you choose, and a view built for the export, with every field visible and no filter, gives the fullest file. Import on the new side is ordinary work: the columns become tables in Postgres, and the record IDs that other tables refer to become the keys that link them. Static assets you still hold the originals of, and the domain name if the registrar account is yours, move as they would from anywhere.
The design moves as knowledge. A running Zite app is a precise specification: every screen, role and workflow can be opened and compared while the new app is built, which is far quicker than building from a document. The people who made the screens know things about the business no document holds, and a rebuild is a chance to keep what worked and drop what the app has grown around.
What needs its own plan
The code comes first, because on the other pages of this site it is the easy part and here it stays behind. The app is rebuilt, and the size of that job depends on how many screens, roles, workflows and automations the app has grown. For a small internal tool it can be a few weeks; for an app with many roles and automations it can be longer.
Then the state that the CSV does not carry. User accounts: Zite signs people in with an emailed code, Google or SSO, so there are no passwords to move and everyone enrols again on the new app. Uploaded files: attachments export as links that expire, so the files are downloaded separately, before the export is relied on. Table relationships and formulas: the CSV is a spreadsheet of values, so they are made again on the new side. Workflows: Zite's automations become scheduled jobs or handlers on the new stack. Secrets, and the connections to Airtable, Google Sheets or other tools, which Zite asks you to re-enter even when importing into another Zite workspace, have to be collected. We keep a one-page list for every migration, and on a Zite app most of the lines are things to make again, with the data lines at the top. It is still usually shorter than people fear.
The questions worth asking before launch day
Security is the part that generated apps tend to get wrong in the same few ways. An automated scan of about a thousand AI-generated apps across Lovable, Bolt, Replit, Vercel and others, published by Stefan Lederer of securityscanner.dev in April 2026, reported that 183 of its 190 critical findings were misconfigured row-level security on Supabase databases, which in practice means any signed-in user can read other users' rows. The same scan flagged 38 apps with API keys sitting in the JavaScript bundle, and a few API endpoints with no authentication at all. One scan is one scan, and the figures will have moved since it ran. The pattern, though, matches what we find when we open a generated codebase for the first time.
Three checks cover most of it, and none of them needs a migration to run: searching the loaded JavaScript for the word "key" in the browser's developer tools on the live app, signing in as one user and trying to fetch another user's record by changing an ID in the address bar, and listing every API route the app has and asking, for each one, who is allowed to call it. If those three come back clean, the app is in better shape than most. If they come back with findings, it is better to know while the app is still on Zite than on the first morning it is on infrastructure you are responsible for.
Where Zite stands on this
Zite, built by the team behind the Fillout forms product, is the one builder on this page where the code stays behind. In May 2026 its FAQ put it plainly: "You can export apps between Zite accounts, but the code currently will not run out-of-the-box in an external environment", with a note that an export for other platforms might come in future. By November 2026 that question had left the FAQ, and the help centre describes export as moving an app or a workspace to another Zite organisation, with database records exported separately as CSV. We read that as the same position, and we would plan on it until Zite says otherwise.
There is a fair amount on the other side of the ledger. Zite's hosting runs on AWS through Render, in the United States with EU servers on request; its security page describes SOC 2 Type 2 compliance; and at US$20 a month on Pro it is one of the cheaper ways on this page to keep a small app running. For a team whose customers do not ask where the data sits, staying is a reasonable choice. Its lack of a runnable export is the main thing to weigh if you think you might one day leave, and a trial CSV export of your largest table, done this week, is a cheap way to see how the leaving would go.
How we tend to approach it
Our default, when a client wants to own the result, is a Go backend on PostgreSQL, deployed to a cloud region in Singapore, with a mainstream front end that most developers you hire later will know. On a Zite rebuild the order we use is data first: the CSV exports go into Postgres early, with the relationships restored, so that every screen built afterwards is tested against real records. Then the screens, built with Claude against the running Zite app, one at a time, and compared side by side. Then the workflows, which are usually the part people forgot they had. Go and Postgres are boring in the best sense, and both are easy for an AI assistant to read and change, which matters more now than it did two years ago. The cutover happens once the rebuilt app has run alongside Zite, with a fresh export, for long enough that nobody is nervous, and the Zite subscription stays one more month as the rollback.
We still get the timing wrong on one part more than any other: user sign-in. On a Zite app nobody has a password to move, which sounds simpler, and it is still the step that produces the support emails. We now plan for a week of those where we used to plan for a day.
A scene, to make it concrete
Picture a nine-person logistics firm in Jurong. The operations lead built a delivery-tracking app on Zite over two weekends, and the drivers have used it every day for eight months. The trigger for the conversation is a tender: a prospective customer's security questionnaire asks where the data is stored and who has access to it. The honest answer involves a vendor's servers in the United States and an admin login shared by three people. The app is doing its job, and the questionnaire now needs an answer the current setup cannot give.
On Zite that conversation leads to a rebuild, and the shape of it is this: export every table as CSV, restore them into a database in Singapore, rebuild the handful of screens the drivers use against the running Zite app, put the API behind a login with roles, and run the two side by side for a fortnight before the drivers are moved over. The questionnaire would get a different answer. The firm is hypothetical; the shape of the situation is one we have met more than once.
Questions to take into your next conversation
- What changed, specifically, that made leaving Zite feel necessary this month and not six months ago?
- Which part of the app do you change most often, and who changes it?
- Where does the data live right now, and who could answer that without checking?
- If Zite's editor disappeared tomorrow, what would you miss most?
- Who will get the alert when the app is down at two in the morning?
If it would help to think these through with someone outside the team, we offer a short discovery call for exactly this, and we are glad to say if staying put is the better answer.
Leaving a different builder? Bolt · Emergent · Lovable · Replit · Riff