Move your AI-built app off the platform and onto code you actually own

The moment usually arrives as an email rather than an outage. An enterprise customer wants a security questionnaire filled in. An investor asks who owns the code. A developer you want to hire asks for repository access and there is not really one to give. Nothing is broken. You have simply built something valuable inside a box you do not hold the key to.

That is a migration, not a rescue, and it is a different job. Nobody needs convincing that the app works, because it demonstrably does. What has to happen is unglamorous and exact: get the code into a repository you control, get the data out without losing a row, put it on infrastructure you can point a domain and an auditor at, and cut over without your users noticing a thing.

None of these platforms set out to trap anyone, and most will hand you an export. The catch is what the export contains. You get the application code, which was never the difficult part, and you do not get the hosted database, the auth service, the file storage, or the deploy configuration, because those were the platform. What lands in your repository is a project that compiles and cannot run.

So the work is not the download. It is standing up real equivalents for everything the platform was quietly providing, pointing the code at them, and proving the result behaves identically before anything switches over. Done properly it is undramatic. Done as a weekend export it is the outage that teaches you which services you were depending on.

Code can be rewritten from the screens. Your users, their history, and everything they have entered cannot, and a migration that loses a percent of it has failed no matter how clean the repository looks afterwards. This is why we migrate against a copy first, count what arrives, and reconcile the difference before anyone commits to a cutover date.

It is also why the assessment starts with where your data actually is rather than what your code looks like. Plenty of builder apps keep more than the owner expects inside the platform: uploaded files, auth records, webhook logs, a table someone added through the UI and never referenced in code. Finding those after the switch is how migrations become incidents.

We run both systems side by side rather than picking a Saturday night. The new stack goes up on a subdomain first, gets the real data, and gets used by you until it is boring. Then the domain moves, and the old platform stays paid for and running for a fortnight afterwards, because the cheapest possible insurance is the ability to point the DNS back.

It is the same strangler-fig approach we use moving companies off Rails, WordPress, and Firebase. The technology is different and the discipline is identical: move in slices that can be reversed, and never create a moment where the only way forward is forward.

If nobody is using the product, moving it is premature. The platform is a faster place to keep changing your mind, and paying engineering rates to relocate a guess is the most expensive way to learn it was a guess. Stay where you are until there is a reason to leave that you can name.

The reasons that count are concrete: a customer whose procurement will not clear a platform you cannot describe, a bill that now exceeds what real hosting costs, an engineer you want to hire who needs a repository, or data you are legally responsible for that currently lives somewhere you cannot audit. If none of those are true yet, we will say so, and you can come back when one is.