Where your website’s data lives

The repository is not the whole site

The code in your repository describes how the site looks and behaves. It does not contain the customers who signed up, the orders they placed, the photos they uploaded, the messages they sent through the contact form, or the articles someone wrote in a content editor. All of that is data, and it lives in services the code talks to: a database, a storage bucket, an authentication provider, a form handler, a CMS. Each is a separate account with its own owner and its own rules about getting data out.

For a brochure site with a contact form, this is a short list. For anything with sign-in or sales, it’s the bulk of what the business would lose if the wrong account closed. Owning the code and the domain and not the data is like owning the shop fittings and not the stock.

This guide is the inventory. If you haven’t yet found the host and repository, start there; the host’s environment variables are the fastest route to the list of services, as the secrets guide explains.

The process, for each kind of data

For every item below, answer the same five questions and write the answers down:

1. Does the site have this? If you’re not sure, ask your coding agent or developer: “Which services does this site store data in?” It can read the code and the environment variable names and tell you.
2. Which service holds it? The provider’s name and the project or database name inside it.
3. Whose account is it in? The login, the email on the account, the card that pays for it, and whether you’re an owner, a member, or not on it at all.
4. Can it be exported, and what does an export contain? Find the provider’s export or backup documentation and read what’s included and what isn’t. Then do a test export, now, while nothing is urgent.
5. What would have to move if you left? The data, the account, or both; and what the site would lose in the move.

The database

If the site stores anything at all, such as accounts, orders, bookings, posts or settings, it’s in a database. AI builders commonly use Supabase; other sites use Neon, PlanetScale, Firebase, MongoDB Atlas, a database bundled by the host, or one inside the builder’s own platform.

• Find it: the environment variables will include something like DATABASE_URL or SUPABASE_URL, whose value names the provider.
• Ownership: the database belongs to a project, which belongs to an organization or account. Check who owns the organization, not just who can open the project. Supabase and Neon can both move a project between organizations, which is how you take one over.
• Export: for a Postgres database, a full export is a standard operation (a “dump”) that any developer can run and that Supabase and Neon both document. Providers also keep automatic backups on their paid plans, but those aren’t always downloadable, and Supabase says its physical backups aren’t; the dump is the portable copy. The export is the tables and their contents; it doesn’t include the provider’s dashboard settings, access rules or scheduled jobs unless those are stored in the database too. Ask.
• Leaving: a Postgres export restores into any other Postgres provider. A database inside a builder’s platform may export only to a file format the builder chooses; find out which before you need to.

Uploaded files and images

Images, documents and media that users or staff uploaded are usually in a storage service: Supabase Storage, Cloudflare R2, Amazon S3, Vercel Blob, or the builder’s own. The database holds only their addresses. If the storage account closes, every one of those addresses breaks at once, and the site looks like it was vandalised.

• Find it: open the site, right-click an uploaded image, copy its address, and read the domain. Or look for storage-related environment variables.
• Ownership: the bucket’s account, as above.
• Export: most storage services are compatible with the S3 standard, so a developer can copy the whole bucket with a standard tool. A builder’s storage may need a download from its dashboard.
• Leaving: the files copy easily. The catch is the addresses stored in the database, which point at the old bucket; a move needs those rewritten or the old addresses redirected.

User accounts and sign-in

If people can sign in, a service manages their accounts. It may be part of the database provider (Supabase Auth, Firebase Auth) or a separate one (Clerk, Auth0, or a sign-in library in the code using the database). This is the data that’s hardest to move cleanly.

• Find it: environment variables named for the provider, or the sign-in page itself, which often shows the provider’s branding.
• Ownership: as above, and note that “sign in with Google” or similar depends on a developer-console project at Google, which also has an owner.
• Export: the list of users and their emails can almost always be exported. Passwords are stored as hashes, and whether those can be exported varies: Clerk includes them in a CSV you download yourself, Firebase exports them with the command-line tool, Auth0 provides them only through a support case and not for every account, and for others you have to ask. Without the hashes, every user has to reset their password after a move.
• Leaving: plan for the password question first. If hashes can’t come with you, the move is still possible; it’s just visible to your users.

Form submissions

Contact forms, quote requests and sign-ups go somewhere: the host’s built-in form handling, a form service such as Formspree or Tally, a spreadsheet, the database, or straight to an email address.

• Find it: submit the form yourself and see where it arrives. Then check the code or ask what the form posts to.
• Ownership: the form service account, or the host project.
• Export: form services and hosts generally offer a download of past submissions as a spreadsheet. Submissions that went only to an inbox live in that inbox.
• Leaving: past submissions are an export. Future ones need the form pointed at a new destination, which is a code or host change.

CMS content

Some sites keep their editable text and articles in a content service rather than in the code: Sanity, Contentful, a headless WordPress, or a builder’s own content editor. Then the words on the site are data too.

• Find it: if editing the site means logging in somewhere that isn’t GitHub or the host, that’s the CMS.
• Ownership: the CMS project’s account.
• Export: the established services document a full export of a project’s content. What it looks like varies, and images referenced by the content may be stored by the CMS, so check whether the export includes them.
• Leaving: moving between content services is a real job because each structures content differently. The text survives; the structure has to be rebuilt.

If the site’s text lives in the repository instead, in the code or in a content file, then it’s already yours and moves with the code. That’s the arrangement Refino works with: the words stay in a file in your repository and you edit them in place, so there’s no content service to inventory.

Analytics

Visitor statistics from Google Analytics, Plausible, Fathom, the host’s analytics or the builder’s dashboard. Low stakes compared with the rest, but it’s the one account most often left under a contractor’s login.

• Find it: a public variable such as an analytics ID, or the tag in the page source.
• Ownership: Google Analytics properties have administrators; make sure one of them is you. Others have team or account owners.
• Export: history often can’t be moved between products, only reported on and downloaded. Some services can export and import their own data.
• Leaving: accept that history usually stays behind. Keep the account, and point the new site at the same property.

Payments, email and other services

• Payments. Stripe, Lemon Squeezy, Paddle or similar hold customers, subscriptions, payout details and the bank account. The account must be in the business’s name, with you as owner; Stripe, for instance, allows exactly one owner per account, and only the owner can hand that role to someone else. Customer and payment records can be exported as spreadsheets; stored card details can move between accounts only through the provider, on request, and subscriptions need recreating. If a builder or developer set this up under their own account, start that conversation now.
• Email sending. Resend, SendGrid, Postmark or Mailgun send the site’s transactional email. The service verifies your domain with DNS records tied to its account. There’s little data to export; what matters is that the account, and therefore the sending reputation and the verified domain, is yours.
• Everything else. Maps, search, chat widgets, booking, a CRM the site writes to, an AI model the site calls. Each has an account and a key. The builder exit guide has the full fourteen-item list, and the access guide covers making each account yours.

The test

If yes for every item, you own the data. If any answer is “it’s in their account” or “I don’t know if it exports”, you’ve found the next thing to fix, and it’s usually a short conversation followed by a test export.

What to record

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.

• Backups · Supabase
• Transferring a project to another organization · Supabase
• Migrate from Postgres · Neon
• Export and import data · Firebase (Firestore)
• Firebase CLI reference: auth export · Firebase
• Exporting users · Clerk
• Bulk user exports · Auth0
• Import and export data · Cloudflare D1
• Data migrations · Stripe
• Roles and permissions · Google Analytics Help
• Roles · Stripe
• Form submissions · Netlify
• Exporting submissions · Formspree
• CLI reference: datasets · Sanity
• contentful-export · Contentful
• Use rclone with R2 · Cloudflare
• Add a domain · Resend