How to take your website with you when you leave an AI builder

“Exporting the site” means more than downloading the code

When people picture leaving a website builder, they picture downloading a folder of files. That folder is necessary. It’s rarely sufficient.

A working website is the code plus everything the code talks to: the domain, the place it’s hosted, the database it reads from, the service that sends its emails, the keys that let it call other services, and the accounts each of those lives in. An AI builder that set all of that up for you may have set it up inside its own platform, under its own accounts. Download the code, cancel the subscription, and the site you deploy elsewhere may load with an empty database, broken sign-in and a contact form that goes nowhere.

So the job isn’t “export”. It’s an inventory: find every piece the site depends on, work out where it lives and who controls it, and move or recreate each one before the old platform is switched off.

Different builders give you different amounts back

AI builders vary a lot in how much of your site you can take with you. Some connect to a GitHub repository under your own account and keep it in sync, so the code is already yours. Some offer a one-time download. Some host the site, the database and the domain inside their own platform, and exporting means reconstructing the parts they don’t hand over.

This guide is deliberately platform-neutral: the inventory below is the same whatever tool you used. For the specifics of a particular builder, check its current documentation for the words “export”, “GitHub”, “download” and “custom domain”, and treat anything it doesn’t mention as something you’ll need to recreate.

The inventory: everything a site can depend on

Go through each item. For every one, answer three questions: Does my site use this? Where does it live? Who controls that account? Not every site uses every item; a brochure site may only have the first five.

1. The domain

The address. If you bought it through the builder, it may be registered in the builder’s account or in yours at a registrar the builder partners with. Find out which. If it isn’t in an account you control, ask for it to be transferred, using the domain transfer guide. Do this early; transfers take days.

2. The source code

The files that make up the site. Get a complete copy: if the builder offers a GitHub connection, use it and confirm the repository is under your account; otherwise download the export and put it in a repository yourself. Open it and check it isn’t empty or missing folders. The GitHub guide explains what you’re looking at.

3. The repository and its history

If the code was already in GitHub, check who owns the repository. A repository in the builder’s organization, or a freelancer’s account, with you as a collaborator, is not yours. Ask for it to be transferred to your account or organization; GitHub supports this directly, and the history comes with it.

4. Hosting

Where the live site runs. If the builder hosts it, you’ll need a new host: Vercel, Netlify and Cloudflare all deploy straight from a GitHub repository. Set the new host up, connect the repository, and get the site working on the host’s temporary address before you touch the domain. The hosting guide covers how the pieces fit.

5. DNS

The records that point the domain at the host. Before changing anything, export or screenshot every record. When the new host is ready, you’ll change the records that point at the old host and leave the rest, especially the ones for email, exactly as they are.

6. The database

If the site stores anything, such as user accounts, orders, bookings, posts or submissions, that data is in a database. It is not in the code. Find out which service holds it (the builder’s own, or a provider like Supabase, Neon, PlanetScale, Firebase or MongoDB Atlas), who owns that account, and how to export the data. If the database is inside the builder’s platform, ask what export format it offers and whether the new host can import it.

7. Authentication

If visitors can sign in, some service manages their accounts and passwords. This is often part of the database provider, or a separate one such as Clerk, Auth0 or Firebase Auth. Moving it means moving the users. Some providers export password hashes, some don’t, and if not, users will have to reset their passwords after the move. Find out before you promise anyone a switch they won’t notice.

8. File and image storage

Uploaded images, documents and media are usually stored in a separate service (the builder’s storage, or something like S3, Cloudflare R2 or Supabase Storage), and the site only holds links to them. If the storage account closes, every image on the site breaks at once. Download everything and note which URLs the site expects.

9. Forms

Contact forms and sign-up forms send their submissions somewhere: the host’s form handling, a service like Formspree or Tally, or straight to the database. Find out where past submissions are, export them if you need them, and make sure the new setup sends new ones somewhere you’ll see.

10. Email

Two separate things. Your own mailbox at the domain, such as you@yourbusiness.com, depends on DNS records that must survive the move. And any email the site sends, such as confirmations or password resets, goes through a sending service (Resend, SendGrid, Postmark, Mailgun) with its own account and its own DNS records. Note both.

11. Analytics

Visitor statistics from Google Analytics, Plausible, Fathom or the builder’s own dashboard. The history usually can’t be moved, but the account can be yours, and the new site can keep reporting to it. Low stakes, but easy to forget.

12. Payments

If the site takes money, there is a Stripe, Lemon Squeezy, Paddle or similar account, with customers, subscriptions and payouts in it. It must be in your business’s name. If the builder set it up under its own account, moving it is a conversation with both the builder and the payment provider, and it should start now.

13. Environment variables and secrets

Environment variables are the settings a site is given by its host rather than by its code: database addresses, API keys, passwords for the services above. They are deliberately kept out of the code, which means an export of the code does not include them. On a new host you will have to enter each one again. List the names now, from the old host’s settings, and find out where each value comes from. Some values can’t be read back once saved, and have to be regenerated at the service that issued them.

14. Third-party APIs

Anything else the site calls: maps, weather, an AI model, a booking system, a CRM. Each has an account, a key and a bill. If the key belongs to the builder, it stops working when you leave.

The test

If the answer is yes, the site is portable: the code is in a repository you own, the services are in accounts you own, and the secrets are written down. If the answer is “only if they rebuild the database” or “only if they can get into the old builder”, you’ve found the item to fix first.

The order to do it in

The safe sequence builds the new setup alongside the old one and switches over only at the end.

1. Run the inventory. Write down every item, where it lives, and who controls it.
2. Start the domain transfer if the domain isn’t already yours. It runs in the background.
3. Get the code into a GitHub repository under your account.
4. Export the database, storage and form submissions, and keep the exports somewhere safe.
5. Create your own accounts for each service the site uses, or take ownership of the existing ones.
6. Set up the new host, connect it to your repository, and enter every environment variable.
7. Test the site on the host’s temporary address: pages, sign-in, forms, payments, images.
8. Export your DNS records, then change only the records that point at the old host.
9. Verify the live site and your email. Leave the old platform running for a while as a fallback.
10. Cancel the old platform only when nothing has depended on it for a couple of weeks.

Exit checklist

After you’ve left

With the site in your own repository, on your own host, under your own domain, you have something the builder couldn’t give you: a site any competent developer or AI coding tool can work on. Point Claude Code, Cursor or Codex at the repository and they can add features the same way the builder did.

The one thing that changes is small edits. Inside the builder, you could type “change the headline” and it would. Outside it, that same request goes through a coding agent, a commit and a deploy, which is a lot of machinery for three words. That’s what Refino is for. It adds click-to-edit text to the site you now own, saves the change back to your repository, and leaves the code, the host and the domain exactly where you put them. It doesn’t move the site back inside another builder. If you never use it, everything above still holds. Here is how it works.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Transferring a repository · GitHub
• Environment variables · Vercel
• Environment variables overview · Netlify
• Transfer policy · ICANN