How to migrate from Base44, step by step, without downtime

The short version

Moving a live app off Base44 safely is mostly about order. The new copy comes up next to the old one, gets checked, and only then takes over your users:

1. Take stock of everything the app uses: tables, users, functions, automations, files, secrets, integrations, the domain, and every outside service that calls it.
2. Move a copy that runs in test mode, on accounts you own, while Base44 keeps serving your users.
3. Check the copy: sign-ins, access rules, records, files, functions, and anything that sends messages.
4. Connect your domain to the new app. This is the moment your users move.
5. Let users sign in once. Done right, their passwords carry over.
6. Move webhooks from Stripe, PayPal, Twilio and other services to the new address.
7. Cancel Base44, and keep the old app published until your active users have signed in on the new one.

There are two ways to do the moving itself. You can rebuild the backend on another stack, such as Supabase, which means rewriting how the app reads and writes data and asking every user to set a new password. Or you can move the same app onto a Base44-compatible backend you own, which is what a migration tool like Unbase44 does. The order holds either way. Below, each step says what you do yourself and what a tool does for you.

Free tool: the Base44 export checker reads your export in the browser and lists everything that still runs on Base44’s servers. Nothing is uploaded.

What a migration has to cover

Base44’s own exports give you your code (a ZIP or GitHub sync) and your records (CSV files, one table at a time). Our guide to exporting from Base44 covers each option. Exports are a backup, not a migration, because the app your users open every day also depends on services only Base44’s servers provide:

• the API your frontend calls for every record, sign-in and function
• user accounts and their passwords
• the access rules on each table
• the runtime for backend functions, and the scheduler behind automations and workflows
• file storage, including private files
• built-in email, AI and upload integrations, and connectors such as Gmail or Slack
• AI agents and their conversations
• the values of your secrets (the API keys your functions use)
• your custom domain and its certificate

A migration is finished when each of these has a new home that you control, and your users can’t tell anything changed.

Two routes: rebuild it, or move the same app

Rebuilding makes sense when you want a different stack anyway, for instance because your team already runs Postgres, or when the app is small and you were planning a rewrite. It is real work: Base44 stores data in a MongoDB-compatible document database, and Supabase gives every project a Postgres database, so queries, security rules and functions all change shape. Our guide to moving a Base44 app to Supabase maps it piece by piece. Expect a project measured in weeks, and plan for every user resetting their password at the end.

Moving the same app keeps your frontend (apart from a few small, documented patches) and your app’s logic, and replaces what sits behind them. That is what Unbase44 does: your code goes into your own private GitHub repository, your data into your own database, and a documented Base44-compatible server runs it on hosting you choose. Unbase44 is made by Codama and is independent of Base44 and Wix. It isn’t the only tool of this kind; our comparison with EscapeBase44 sets out what each one says it does.

Step 1: take stock of what the app uses

Write down what the app depends on. This list becomes your test plan in step 3 and your switch-over plan in steps 4 to 6.

• Tables and records. In the dashboard’s Data section, note each table and roughly how many records it holds.
• Users. How many, which roles, and how people sign in: email and password, Google, or another provider.
• Backend functions. Which ones your pages call, and which ones outside services call (payment webhooks, for example).
• Automations and workflows. What runs on a schedule, what runs when data changes, and what sends email, texts or notifications.
• Integrations and connectors. AI calls, email sending, file uploads, and connected services such as Gmail, Slack or Google Sheets.
• Agents. Each AI agent and what it can do.
• Secrets. The names of the keys your functions use. Base44 masks their values when it lists them.
• Files. Uploads, and whether any are private.
• Your domain. Where it’s registered and who manages its DNS: a registrar such as GoDaddy, Namecheap or Cloudflare, or a domain you bought through Base44.
• Outside callers. Every service that has your app’s address saved: Stripe, PayPal, Twilio, Telegram, Zapier and so on.

Don’t cancel your Base44 plan yet. Several of the tools you need are paid features: Base44’s ZIP download and GitHub sync need the Builder plan or higher, and so do backend functions. Cancelling comes last, in step 7.

With Unbase44, this step is the free analysis. You sign in with your Base44 account through Base44’s own device sign-in, so Unbase44 never sees your Base44 password. It lists your apps, you pick one, and the analysis shows what’s in it (pages, tables, records, users, functions, automations, workflows, agents and files) and a one-time price, before you connect any account or pay anything. During the beta, migrations are free; the regular price starts at $99, one-time, per app, and your hosting and other providers bill you directly. You can run the analysis here.

Step 2: move a copy that runs in test mode

The safe way to move a live app is to build the new one beside the old one. Your users stay on Base44 the whole time, so there is no downtime while you work.

A copy of a live app has one specific danger: it holds your real data, so it can do real things. If its automations run, your customers get every reminder twice. If a function charges a card, sends a text or updates another service, that happens twice too. A copy needs to stay quiet until it takes over.

If you’re rebuilding, run the new app on a separate address, leave its schedules switched off, and use your providers’ test keys where they offer them until you’re ready to switch.

With Unbase44, the copy goes onto accounts you own:

• Code: a private repository in your GitHub account, with the app’s React frontend (its own code, with a few small patches listed in the repo’s docs/MIGRATION.md), the server, Docker files, and documentation for people and for coding agents (README, AGENTS.md, CLAUDE.md, and architecture, deployment and local development guides).
• Hosting: your own Railway account, with the app, a MongoDB database and a storage bucket in one place, or any Linux server you can reach over SSH, run with Docker and with HTTPS set up automatically. Railway’s Hobby plan costs $5 a month including $5 of usage (Railway’s pricing, as of October 2026), billed by Railway to you. Hetzner, MongoDB Atlas and AWS are coming soon.
• Email and AI: sign-in codes and the app’s own emails go through your own Resend account or any SMTP server; AI features use your own key from OpenRouter, OpenAI, Anthropic or Gemini.
• Secrets: their values are read by a small temporary helper function that Unbase44 adds to your Base44 app and removes right away. You’re told before it happens, and you can untick it and type the values in yourself.
• Google sign-in: comes across using your own Google sign-in client. The app’s page walks you through creating one in a few minutes.

The copy starts in test mode. While your Base44 app keeps serving users, the copy runs no automations or workflows, and holds anything it would send out (emails, texts, notifications, payments, changes to other services), logging each one instead.

Step 3: check the copy

Go through the copy as your users would, using the list from step 1. Fix anything that looks wrong before you go on.

• Counts. Compare records per table, users and files with what Base44 shows.
• Sign-in. Sign in as yourself, and as an ordinary user if you have a test account.
• Access rules. As an ordinary user, try to open records that belong to someone else. You should get nothing back. This is the check that matters most.
• Main flows. Create, edit and delete the things your users create, edit and delete.
• Files. Open an uploaded file, including a private one.
• Functions. Trigger the functions your pages call.
• Outgoing messages. In test mode nothing goes out, so look at what the copy held: which email it would have sent, to whom, and when. That shows you the automations and emails are wired up correctly without anyone receiving a duplicate.
• AI features and agents. Ask an agent something and check the answer uses the right data.
• SEO. Check page titles and descriptions on a few key pages.

Step 4: connect your domain

Pointing your domain at the new app is the moment your users move. Prepare three things first.

1. Stop scheduled work on Base44 that the new app will take over. Base44 lets you deactivate a workflow, which stops new runs while keeping its history; automations have an on/off setting too. Otherwise a job could run on both apps.
2. Take the copy out of test mode, so it starts sending email and running automations.
3. Make sure the copy’s data is current. A copy holds what Base44 had when it was made. Anything users added on Base44 since then, and anything they add while DNS changes spread, has to reach the new app too. Whichever route you take, settle how that happens before you switch.

With Unbase44, a guided switch-over on the app’s page turns test mode off, points the domain and helps you move webhooks. You can connect a custom domain from the same page, which shows the exact DNS records to add.

Then change the DNS records. Where you do that depends on where the domain lives:

• Registered elsewhere (GoDaddy, Namecheap, Cloudflare and others): change the records at your DNS provider. Base44’s documentation notes that a domain you connect stays registered with your provider, so nothing needs to move but the records.
• Bought through Base44: Base44’s documentation says almost every domain bought in Base44 now comes from Wix and is managed from your app’s domains dashboard, where you can edit A and CNAME records. You can also transfer it to another provider, but only 60 days after it was registered (or after a change to its contact details), and a transfer can take up to 7 days. If you transfer, add your app’s records at the new provider, or the domain stops answering.

DNS changes take time to reach everyone, so for a while some visitors reach the old app and some the new one. Because the Base44 app is still running, both work during that window.

Step 5: let users sign in once

Base44 doesn’t hand out password hashes, and its documentation states that app users can’t be exported. That shapes this step more than any other.

If you rebuilt the backend, import your users’ emails and roles, then ask everyone to set a new password or sign in with an email link. Tell them first: an unexpected password-reset email looks like phishing.

With Unbase44, users keep their passwords. Each user’s first sign-in on the new app is checked against Base44 once, and then the new app stores its own hash of that password. From then on, Base44 isn’t involved for that user. This only works while the Base44 app stays published, so keep it published until your active users have signed in once. Google sign-in carries on working through your own Google sign-in client.

Step 6: move webhooks and other services that call your app

Outside services reach your app through addresses saved on their side. Base44’s documentation says each backend function gets an HTTP address on your app’s domain, used for things like Stripe or GitHub callbacks. Go through your list from step 1:

• Payments and messaging. Stripe, PayPal, Twilio and Telegram each hold a webhook address. Any that use your app’s base44.app address keep calling Base44 until you change them. Unbase44’s guided switch-over helps move these four to the new address. The exception is Stripe set up through Base44’s built-in payments: Base44 registers those webhooks itself and its docs say you can’t repoint them, so plan that payment setup separately (agents and integrations).
• Automation tools. Zaps and similar tools that call your app, or that your app calls.

After each change, trigger a test event (a test payment notification, for example) and check that the new app received it.

Step 7: cancel Base44, then retire the app

Once the new app is serving your users, you can cancel your plan. Base44’s billing documentation says you keep full access until the end of the billing period, and then your workspace moves to the Free plan. Your apps stay live, with fewer features. Our guide to cancelling Base44 has the exact clicks, and what Base44’s terms say about yearly plans and refunds.

Don’t delete the Base44 app yet. If your users are keeping their passwords through a first-sign-in check, it needs the Base44 app to stay published. Retire it once your active users have signed in on the new app.

With Unbase44, the moved app depends on nothing of Unbase44’s. The server code in your repository is MIT-licensed, and “Revoke access” on the app’s page deletes every key Unbase44 held. On Railway, pushing to the repository’s main branch deploys the app, so you, a developer or a coding agent can keep working on it.

When you shouldn’t migrate

Leaving isn’t always the right call.

• The idea is brand new and still changing daily. An AI builder is a good place to find out what the app should be. Move once it has users who depend on it.
• The app is really a website. If it’s a landing page with a contact form, a website builder will serve you better than a self-hosted app.
• It’s small, it works and it costs little. Keep it on Base44 and take regular exports, so you have copies of your code and data if that changes.