Switching tools without losing everything you built
You want to switch tools. Your files are somewhere, you do not know exactly where, or in what form, or whether you can get them out. You have been putting off the decision for weeks because the one thing you are sure of is that you will not rebuild from scratch.
Content and code almost always come back. What does not is the assembly specific to the platform: its settings, its forms, its databases. Get a complete copy out first, check it opens somewhere else, and only then close anything down.
What belongs to you, and what does not
The question rarely comes up at a good moment. You discover it when prices go up, when a need outgrows what the tool can do, or when you simply want the wheel back.
Three categories, and they do not share the same fate.
What you wrote is yours: your text, your images, your prices, your pages. No platform claims otherwise, and there is never any legal difficulty here.
Code almost always comes back, but how varies enormously. Some platforms offer continuous syncing to a code repository you control — Lovable’s documentation, for instance, describes exactly that. Others require a manual export. Others offer nothing at all.
The assembly, though, does not come back. The platform’s settings, its built-in forms, its databases, its automations: all of that is written in its own language. This is not bad faith, it is structural. It is also the part that costs the most to rebuild.
The order that avoids disaster
The classic mistake is cancelling first and recovering afterwards. The right order is the reverse, and each step gets checked before the next.
Export a complete copy while the account is active. This is the only step with a deadline. As long as you are paying, you have access; the day you stop, access can vanish overnight.
Check the copy opens somewhere else. An archive nobody has ever reopened is not a backup, it is a hypothesis. Open it in another tool, or have your AI run it locally, and look at what is missing.
Note what did not follow. There will always be something: the form, a particular display, an integration. That list is your real migration cost, and it is better known before deciding.
Build the new site alongside, unpublished. Compare page by page against the old one, still live. That is the luxury rushing takes away.
Switch the address last, and only when the new site fully satisfies you.
The one technical point that really matters
If your site has any search ranking, keep exactly the same page addresses.
To a search engine, a changed address is one page disappearing and another appearing with no history. You lose whatever the first had built up. Conversely, an entirely rebuilt site that keeps its addresses passes almost unnoticed.
When an address change is unavoidable, every old one has to send visitors automatically to the new one. Not an error page, not a redirect to the home page: to the equivalent page, one by one.
It is the only part of a migration you cannot fix later. Everything else can be corrected; a broken address for two months cannot.
What to ask your AI
Three requests, in this order:
Export everything that can be exported from this platform into a folder on my computer. List what you could not retrieve.
Run this copy locally and show me what displays wrongly or does not work.
List every page address my current site has. We are keeping them identical.
The first gets you the material, the second reveals the real cost, the third protects what you built up with search engines.
What this question tells you about your next choice
Asking how to leave before you arrive is the best filter there is. A tool that makes leaving simple does not need to hold on to you. A tool that makes it hard is telling you in advance how the day you want out will go.
Ask before you settle in, not on the day you want to leave.