What "migrating" can mean
When someone tells us they want to migrate off Riff, the four meanings we usually sort through narrow to two, because the documentation offers one way out. The first is moving the whole app: the code leaves as a zip from the Export Code setting, the security features it relied on are rebuilt, the data is extracted by whatever route Riff can provide, and the result runs on infrastructure you choose. The second is a rebuild, with the running app as a very precise specification. Which of these applies tends to depend on what the zip contains and whether the data can be got out in a standard form, and both are things to find out before anyone quotes you.
The option of owning the process while the app still runs on Riff, through a repository and a review, is one we would not plan on here. The documentation describes no repository sync, and the workspace the app lives in is sold to a different customer now.
Which of the two is yours? It is worth answering before reading on, because the cost and the timeline differ by a wide margin between a move and a rebuild.
Why building on Riff was a reasonable call
This applies as much to an app built on Databutton or on early Riff as to any other. 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 a vendor moving on 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 code can leave, and that is the one documented fact to build a plan on. Riff's App Settings include an Export Code setting that, in its words, "downloads a zip file with your app's code. The exported app doesn't have the security features of the Riff workspace." Riff's documentation describes its apps as a React and TypeScript front end, a Python back end on FastAPI and a PostgreSQL database, and if your zip matches that shape a developer can usually have the front end running on a laptop within the hour, and the back end soon after, once the sign-in and permissions it leaned on have been replaced.
The documentation does not list what the zip contains, so a trial export is the first thing we would do. Whether the database migrations the Riff agent wrote are in it is worth checking early, because they are the recipe for recreating the tables. Static assets and the domain name move as they would from anywhere.
The design does not stay where it is, in the sense the other pages on this site mean. There is no builder to keep as the design surface, and the running app is the design record.
What needs its own plan
State is the hard part, and on Riff it is harder than on most builders because the documentation is silent on it. The records live in Riff's built-in PostgreSQL database, which the documentation lets you browse and query and gives no export for. User accounts come with the same silence: sign-in belongs to the security features the export leaves out, so plan for everyone to set up their account again on the new app. Uploaded files sit in Riff's Storage, and no code export touches them. Secrets are kept in an encrypted vault, which is correct, and which means someone has to collect them.
Then there is everything Riff connected for you. Deployed apps live at a riff.works address unless a custom domain was configured, so a webhook from a payment provider points there. A scheduled job runs on Riff's scheduler. Any ERP or SaaS connector is configuration on Riff's side. Each of these is small on its own and easy to miss as a group. We keep a one-page list for every migration, and for a Riff app the first line on it is a dated email to Riff asking, in writing, whether the database can be exported with its user accounts and in what form. If the data comes out, this is an ordinary migration with some security work on top. If it does not, the app itself can usually be made to write its data out through a page or an endpoint added before access ends, and that is the part worth doing first.
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 Riff than on the first morning it is on infrastructure you are responsible for.
Why the question is bigger on Riff
Riff is the Oslo company that was Databutton, a general-purpose AI app builder in the same family as Lovable and Bolt. On 23 October 2025 it relaunched under the Riff name, with a founder's note that "yesterday we were Databutton, today we're Riff", took a US$16 million Series A led by Northzone that same month, and over the following year narrowed its market. Its documentation now opens with the new position in one sentence: "Riff is built for procurement and operations teams in manufacturing — connecting directly to your ERP to take action, not just report on it." The features that follow are native connectors for Infor LN, Infor M3, SAP, Oracle and Microsoft Dynamics, and agents for supplier confirmation chasing, invoice matching, RFQ automation and exception management. By June 2026 the documentation for the old builder sat in an archive section titled "Features (legacy Databutton web-app-builder)". By November that archive returned a 404, riff.ai offered a demo request where the sign-up had been, and databutton.com redirected to riff.ai.
If you are a procurement or operations team in manufacturing, the new focus may suit you better than the old product did, and staying could be the right call. If you built something else on Databutton, a customer portal, an internal tool, a small SaaS, you are on a platform whose owner has moved to a different customer, and the roadmap, the support and the pricing are likely to follow that customer. That is a reasonable thing for a company to do, and it leaves an app built under the old positioning without a stated future.
This is worth saying plainly because it is the clearest current example of a risk every builder on this page carries. Lovable, Bolt, Replit, Zite and Emergent are mostly young, venture-funded companies, and a pivot, an acquisition, a pricing change or a shutdown is an ordinary event in that category. The question Riff makes concrete is one to ask of any builder, including the one you are happy with today: if the vendor's strategy changed next quarter, what would you still have?
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 Riff export the first question is whether to keep the FastAPI back end the zip contains or replace it, and the answer tends to depend on how much of it leaned on the workspace's security features. A backend that assumed the platform would handle sign-in and permissions usually needs more rework than its size suggests, and at that point a rewrite in something the next developer will know can cost about the same. The front end is usually worth keeping. Go and Postgres are boring in the best sense: most developers you hire later will know them, 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 new stack has run alongside the old app, with a copy of the data, for long enough that nobody is nervous.
We still get the timing wrong on one part more than any other: user authentication. On a Riff app it is a rebuild, and it is almost always 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 Databutton over two weekends in 2025, and the drivers have used it every day since. Nothing in the app has broken. The trigger for the conversation is smaller than a tender: the lead went to the vendor's site to add a seat and found a demo request where the sign-up used to be, and a product description about ERP connectors for manufacturers. The app is doing its job, and the open question is what would still be there if it stopped.
In that situation the migration starts with two cheap steps: a trial export, to see what the zip contains, and a written question to Riff about the data. The screens are kept or rebuilt, the records go to a database in Singapore, the drivers set up their sign-in again once, and the firm ends up with a stack it can name. The firm is hypothetical; the shape of the situation is one we expect to meet more often, and Riff is simply the clearest current example of it.
Questions to take into your next conversation
- Do you still have access to the Riff workspace, and has anyone tried the Export Code setting to see what the zip contains?
- Which part of the app do you change most often, and who changes it, now that the builder it was made with is no longer sold?
- Where does the data live right now, and who could answer that without checking?
- If the app stopped tomorrow, what would you have on hand to rebuild it from?
- 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 leaving the app where it is for now is the better answer.
Leaving a different builder? Bolt · Emergent · Lovable · Replit · Zite