Key takeaways

What you get on the way out falls into four buckets: the code, the data, the configuration, and the things that were never files at all. Code and data usually transfer. The other two usually do not.
The forgotten bucket is configuration: environment variables, redirects, build settings, scheduled work. None of it is visible in the app and all of it has to exist on the other side.
The bucket nobody plans for is the tool’s own services. End-user accounts it managed, URLs on its domain, and anything built on a feature with no equivalent elsewhere.
Run both systems in parallel before cutting over. The migration is not the risky part; the cutover is.
If you have a real repository, this is an afternoon. If the app only ever existed inside the tool, there is often nothing to move and the honest answer is a rebuild.

You have decided to move, or somebody has asked what moving would cost. Either way the question is the same: if you leave, what actually comes with you?

The marketing answer is “your code is yours.” That is usually true and it is less than half the story, because an application is not only code. Here is what transfers, what does not, and the order to do this in so the day you switch over is boring.

Four buckets

Everything you need to move falls into one of four categories, and they get progressively harder.

The code is the files that define what the app does. The data is the records it has accumulated. The configuration is everything that tells the app how to run but is not part of what it does. And the fourth bucket is services the tool provided that were never files in the first place.

Most migration guides cover the first bucket thoroughly and stop. The second is usually fine. The third and fourth are where a migration actually goes wrong, and they are the two nobody estimates.

Bucket one: the code

Start here because it determines whether the rest of this article applies to you at all.

Ask the tool for your code and look at what arrives. You want a project with recognizable structure: a dependency manifest, source files organized into folders, something that declares how to build it. If you cannot read code, you can still recognize this shape, and anyone who can read code can tell you in thirty seconds whether it is real.

What you do not want is a single configuration file describing an app the tool assembles at runtime, or an export that comes with a note about not being meant to run elsewhere. That is not code in the sense you need. It is a description of an app inside a system that knows how to interpret it, and outside that system it is inert.

The honest version: if your builder connected to a repository you own and every change landed there as a commit, this bucket is already done and you can move on. If export is something you are about to try for the first time, try it before reading further, because the answer changes what the rest of this costs.

Bucket two: the data

Usually the most straightforward bucket, with one trap.

You want a copy of your records in a format something else can read. A standard database dump is ideal. A CSV export is workable. A proprietary format is a problem, and an export that only some tables support is a worse problem, because you will not notice the gap until the new version is missing something.

This is where boring technology choices pay. If the data is in Postgres, moving it is close to mechanical, because every platform speaks Postgres and the tooling has existed for decades. Netlify Database is managed Postgres for exactly this kind of reason: it is the standard thing, so your data stays portable on the way in and on the way out.

The trap is uploaded files. Images, attachments, documents: these frequently live separately from the database, get referenced by a URL pointing at the tool’s storage, and do not appear in any database export. Check specifically for these, because an app that looks migrated until every image 404s is a bad afternoon.

Bucket three: the configuration nobody remembers

Here is where migrations overrun, and the reason is that none of this is visible in the app.

Environment variables. Your app references secrets and settings by name, and those names have to exist with the right values on the other side. Nobody has a list. Go and find one, because the app will start and then fail in a way that is hard to diagnose.

Build settings. Which command produces the deployable output, which directory it lands in, which runtime version. The old tool knew this implicitly. The new one has to be told.

Redirects and routing rules. Anything mapping one URL to another, including the rules that make a single-page app work at all.

Scheduled work. Anything that runs on a timer rather than because someone clicked. These are invisible by definition and the failure mode is silence: nothing errors, the weekly thing just stops happening, and you find out in a month.

Webhooks and integrations. Anything external that calls into your app, or that your app calls out to, with a URL registered somewhere else.

Make this list before you start. It is tedious and it is the single highest-value hour of the migration.

Bucket four: the things that were never yours

The last bucket cannot be migrated at all, only replaced, which is why it needs to be identified early.

End-user accounts. If the tool managed logins, those accounts live in its system. You may be able to export a user list; you will almost certainly not be able to export usable passwords, because they are stored hashed and tool-specific. Plan for a reset flow on the other side rather than discovering this at cutover.

URLs on the tool’s domain. Every preview link, every share link, anything anyone bookmarked or pasted into a document. These stop working and there is nothing to redirect them to unless you controlled the domain.

Anything built on a feature with no equivalent. If your app leans on something specific the tool offered, that part gets rebuilt rather than moved. Identify these first, because they are the only part of a migration with genuinely unpredictable effort.

What the receiving side has to supply

Moving is only half a decision. The other half is whether the destination covers what the old tool was quietly doing for you.

The checklist is the same as the four buckets inverted: somewhere to build and deploy from your repository, a real database, file and object storage, a way to handle user accounts, somewhere for scheduled and background work to run, and somewhere to see what the app is doing once it is live.

On Netlify those arrive as first-party primitives rather than services you assemble: Functions and Edge Functions for compute, Netlify Database for Postgres, Blobs for files, Identity for end-user login, Async Workloads for scheduled and background jobs, and observability tied to each deploy. The reason that matters during a migration specifically is that each additional vendor is another account, another set of credentials, and another thing to configure in bucket three.

The order of operations

Do not cut over and then fix things. Run both and switch when the new one is boring.

Stand up the new environment first, with the configuration list from bucket three already applied. Deploy the code there and let it fail, because it will, and the failures are informative while nobody depends on them.

Load a copy of the data, not the only copy. Work against a copy until the new version produces the same answers as the old one for real cases you can check.

Run both in parallel. For a window, the old system stays authoritative and the new one shadows it. Compare outputs. This is the step people skip and the one that makes the cutover uneventful.

Then cut over, with the old system still standing. Keep it for a couple of weeks. The point is not that you will go back; it is that having the option removes the pressure that makes people rush the verification.

Only then decommission.

A Deploy Preview is useful through most of this, because it gives you a complete running copy at its own URL with its own database branch, so the parallel-running stage happens against realistic data without touching anything real.

What it actually costs

Two very different numbers depending on bucket one.

With a real repository and data in a standard format, a small app is an afternoon and a medium one is a few days, most of which is bucket three rather than anything technical.

Without a repository, you are not migrating, you are rebuilding from a specification you will have to reconstruct by looking at the old app. That is a quarter for anything substantial, and the only consolation is that you will rebuild it better, because you now know exactly what it needs to do.

That gap is the entire argument for checking the export question on day one rather than at the point you want to leave. It is the cheapest insurance in software and it takes ten minutes.

FAQs

What happens to your code when you leave an AI app builder? It depends entirely on whether the builder gave you a real repository. If it did, you take ordinary code that runs anywhere and the move is mechanical. If the app only ever existed as a configuration inside the tool, there is frequently nothing portable to take, and leaving means rebuilding from a specification you reconstruct by examining the old app.

Can I export my app from an AI app builder? Most offer some form of export, and the quality varies enormously. Check what actually arrives rather than trusting that the feature exists: you want a project with a dependency manifest and organized source files, not a single file describing an app the tool assembles at runtime.

What usually gets missed in a migration? Configuration and services. Environment variables, build settings, redirects, and scheduled jobs are invisible in the app but required to run it. Beyond those, anything the tool provided as a service, such as end-user accounts and URLs on its domain, cannot be moved at all and has to be replaced.

Will my data come with me? Usually, and more easily if it is in a standard database like Postgres. Two things to check specifically: whether every table exports or only some, and where uploaded files live, because images and attachments often sit outside the database and do not appear in a database export.

What about my users’ logins? Those typically stay with the tool. You can often export a list of accounts, but passwords are stored hashed in a tool-specific way and will not transfer, so plan a password reset flow on the new side rather than discovering this during cutover.

How long does it take to move off an AI app builder? With a real repository and standard data, an afternoon for a small app and a few days for a medium one, with most of the time going to configuration rather than code. Without a repository, treat it as a rebuild and budget accordingly.

Not leaving yet? Run the export now anyway, while it costs ten minutes. If you want somewhere to land it, netlify.new takes a repository and supplies the rest.