Migrate From Base44: A Step-by-Step 2026 Guide

To migrate from Base44, export the code and replace every Base44 SDK call that handles data, auth, files, or functions. The export carries neither your data nor the backend that runs it.

From here, this guide walks through a seven-step manual migration to Supabase, based on Base44's developer docs as of October 2026, and shows where a governed platform as Superblocks fits.

What you can export when you migrate from Base44, and what stays behind

Base44 exports code, and the backend behind it stays on Base44. Both the ZIP download and the GitHub connection require a Builder plan or higher, so a Free or Starter app has no code export until you upgrade.

Code. In the editor, open More actions and choose Export project as ZIP. Base44's docs don't itemize what the ZIP contains. Unzip it and check for the base44/ folder, because the table above relies on it.

To use GitHub instead, open the Dashboard and use the GitHub icon at the top right to choose Connect to GitHub. Sync then works in both directions, since Base44 changes reach the repo automatically and local changes go live only after you merge to main and click Publish.

Entities, functions, and authentication settings. A Base44 project keeps its backend definitions in a base44/ folder, with one file per entity, one entry.ts per function, and an auth/config.jsonc for login methods. If the folder is there, it is your rebuild checklist.

The functions listed there execute on Deno with a 5-minute execution cap and are hosted on Base44's infrastructure, so each one has to be deployed again on your side.

Records. Export is a CSV download, one table at a time, from the Data page. Since November 27, 2025, each data request returns a maximum of 5,000 items, and the same page points to the CSV export for a full table.

Eject. base44 eject copies the frontend, entity schemas, and functions into a new local project. That project gets its own app ID and an empty database on a separate backend, which leaves you with a second Base44 app.

Passwords. Base44's docs say it handles all passwords securely behind the scenes and list no password or hash export. Unless that changes, expect every email-and-password user to set a new password after cutover.

Users who sign in through a provider such as Google, or through SSO, authenticate there and need no reset.

Secrets. base44 secrets list shows only names and partially redacted values. Re-create each secret from its original provider and stop using the old values.

Files. base44.integrations.Core.UploadFile returns a URL for each upload. I went looking for a bulk file export in Base44's docs and found none. Script the download from the URLs stored in your records.

In practice, the code and backend definitions are what carries over, and everything else has to be re-created at the destination.

Before you start

Have these four things in place before you open the code.

• A Builder plan or higher on Base44. It's the lowest tier that includes the ZIP and GitHub connection, and Base44's pricing page shows it at $40 per month, billed annually.
• App owner access. Only the app owner can connect or reconnect GitHub.
• A destination. Supabase, your own Postgres, or a governed platform like Superblocks.
• An inventory of secrets and callers. Write down every secret your app uses and every third-party service that calls a Base44 function URL. Secret values can't be exported, and those callers need a different address after cutover.

Time required: Allow two to three days for an app with fewer than 10 entities and no backend functions, and one to two weeks once login, file uploads, and functions are involved.

These are planning estimates, not Base44 figures. Your Step 1 hits by module show which of those pieces your app uses, and that decides the range.

Three ways to migrate from Base44

This guide covers three migration paths. They differ in who does the work and where the app runs afterward.

Done-for-you service. Stacksmesh prices Base44 migrations to Supabase or AWS from $2,999, covering scoping through cutover, with data validated against the source and a rollback plan.

Its page also says it checks whether existing accounts and passwords can move before agreeing the plan. If they can't, users may need a password reset, which matches the limit described in the Passwords note above.

Platform import. Replit imports a Base44 project through GitHub. Once the code is on GitHub, you run the import from replit.com/import by choosing Base44 and your repo.

Replit's docs estimate four minutes for that step, and they say existing database records aren't migrated and secrets are added separately.

Superblocks also supports this kind of import, from a ZIP file instead of GitHub, and adds governance (covered below).

Manual self-host. You replace the SDK calls, rebuild the data and auth layer, transfer records, and cut over the domain, and your team runs every layer afterward. The seven steps below follow this path, and the Superblocks section near the end covers the platform import.

How to migrate from Base44: step-by-step

The manual path takes seven steps. Follow them in order, because the count from Step 1 sets the scope for Steps 3 to 5.

Step 1: Count every Base44 call in the code

Search the exported code for each base44. call before you start on the database. Every hit is a line you'll rewrite, and the total tells you how big the job is.

grep -rnE "base44\.(entities|auth|functions|integrations|agents|connectors|analytics|actors|sso|app|asServiceRole)" . --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" --exclude-dir=node_modules

The SDK has eleven documented modules, and the pattern above covers ten of them by accessor name, plus asServiceRole. The overview page doesn’t show the accessor for app-logs, so search for that one by hand.

Sort your hits by module. The Step 4 table covers entities, auth, functions, and integrations, so hits from the other modules need a manual review.

Then click through the live version and write down what works, including which pages load, which forms submit, and what each role sees. That list is the checklist you test against in Step 6.

Pro tip: Base44's User entity carries a role field set to admin or user. Log in as both and take screenshots of what changes.

Step 2: Export the code

Export the code with one of the two routes described above. Choose GitHub if the code is still changing and ZIP if you want a one-time snapshot. With GitHub connected, clone the repository and work from your copy, because Base44 changes reach it automatically.

Keep main as the default branch, because Base44's sync doesn't support other names such as master.

Step 3: Set up the target database and auth

The examples below use Supabase, which puts Postgres, auth, storage, and Edge Functions in one project. Create one Postgres table per file in base44/entities, and map each property in the file to a column of the matching type.

For the keys, keep Base44's id values as primary keys, in a text column that accepts any string id. That keeps foreign references resolving after the import. Base44 manages id and created_date itself, and your new tables need both as ordinary columns.

Then enable the login methods your auth/config.jsonc defines. Base44 supports email and password, Google, Microsoft, Facebook, Apple, and SSO, and its SSO setting can't be combined with social login, so check whether your app used SSO or social login.

Pro tip: Rebuild the role field as row-level security policies before the data load. Supabase's docs say that a table in an exposed schema without RLS is readable and writable by any role with a grant on it.

Step 4: Replace the Base44 SDK calls

Replace them one module at a time, starting with entities, and put the replacements behind a single data-access file so the diff stays reviewable.

In the table, Task stands for any entity, and rows that start with a dot continue the supabase.from('tasks') chain.

The left column comes from Base44's data reference, and the right column from Supabase's references for select and eq, functions invoke, and storage upload.

Postgres Changes needs the table added to the supabase_realtime publication before you subscribe.

Base44 backend functions and Supabase Edge Functions both use Deno. TypeScript logic that doesn't call the Base44 SDK can move over. In any function you carry over, each Base44 SDK call, secret read, and endpoint URL has to change.

In practice, replace secrets.get() with Deno.env.get(), and rebuild base44.asServiceRole calls as a Supabase client that uses the service role key on the server only.

The other modules, such as agents and connectors, have no Supabase equivalent in this table. For each hit, decide whether to rebuild the feature elsewhere or drop it.

Pro tip: Search for base44 again when you finish. My read is that a leftover call can reach Base44's servers, so check any hit outside a comment as a possible dependency on them.

Step 5: Transfer the data

Users go first, tables second, and files last. Base44 keeps taking writes until cutover, so this load is a snapshot that Step 7 brings up to date.

Users. Extract the user list with base44.asServiceRole.entities.User.list() inside a backend function, the service-role pattern the User schema reference shows.

Then create each account from a server with auth.admin.createUser and email_confirm: true, and queue a resetPasswordForEmail request for each email-and-password address, skipping accounts that sign in through a provider or SSO.

Carry each user's role into the new system too, since the policies from Step 3 depend on it. Before cutover, test verification, permissions, and email delivery on one user per role.

Tables. Pull each table as a CSV from the Data page and import it through the Supabase Table Editor (Insert, then Import Data from CSV). That method has a 100 MB size limit, so use pgloader or COPY for larger files.

Files. Download each file from its stored URL and upload it to a Supabase Storage bucket (the bucket must exist first). Then rewrite the URL columns.

Compare the row count of each table against its CSV before you continue, to catch a short import before cutover.

Step 6: Rehearse the migration while the live app stays up

Deploy the migrated build to a staging URL against a copy of your records, and leave the Base44 version taking writes. Work through the checklist from Step 1, then request a password reset on a test account and follow it through to a successful login.

On the staging run, look for the three bugs that Superblocks' deployment guide for AI-generated apps names, which are hardcoded localhost URLs, missing environment variables, and CORS errors. Check webhooks too, because anything that called a Base44 function URL needs the updated address.

Pro tip: Time the full pull and load on this rehearsal. That number gives you a baseline for the cutover window in Step 7.

Step 7: Cut over the domain

Lower the record's TTL a day ahead, since Base44's custom-domain guide warns that DNS changes at an external provider can take up to 48 hours. Then schedule a cutover window and freeze writes in Base44.

Pull what changed since your test run and load it into the new database. Once the row counts match Base44's, switch the DNS record at your registrar and send the reset emails.

Once the destination host is live and your critical user journeys work, open Domains in the Base44 Dashboard and choose Unlink Domain to release the domain from the old app. Keep the old Base44 app live until the destination host has handled a full week of traffic without errors.

Pro tip: Announce the reset on the login page before the emails go out, so a sudden reset request doesn't read as phishing.

Common mistakes to avoid

Check your plan against these four mistakes before cutover.

• Treating the export as the end of the migration. The exported frontend keeps its Base44 SDK calls, and I'd guess a deployed copy that appears to work is sending requests to Base44's backend.

• Loading CSVs without the original ids. Keep Base44's id values, because new ids break any reference that stores the old id. Foreign keys then point at records that no longer exist.

• Promising users their passwords will carry over. Base44's docs list no hash export. Tell users about the reset before it happens.

• Skipping governance when you switch hosts. Superblocks says a governed app has to answer four questions, who made it, what data it touches, who can access it, and when it last ran.

Moving the code to a generic host doesn't answer them, and generated code carries its own risks on any host, which Superblocks' guide to vibe coding security walks through.

When moving is worth it, and when it isn't

Base44 builds a working app from a text prompt, and its paid tiers add features beyond a prototype. SSO through providers such as Okta and Microsoft is on its Enterprise tier, and custom domains start on the Starter plan.

Automatic backups come with Elite, Business, and Enterprise. Whether those features are enough depends on the project. For one builder with no regulated data, the compliance row below doesn't apply, so the other three rows decide.

The reliability row traces to Base44's backend pricing page, which says the developer backend service is currently in beta.

For the cost row, the main pricing page shows monthly credits that range from 25 messages and 100 integration credits on Free to 1,200 messages and 50,000 integration credits on Elite.

The data ownership row depends on the plan too, since Starter at $16 per month, billed annually, has no ZIP, while Builder at $40 per month, billed annually, does.

The case for moving is clearest when several teams run Base44 apps that IT has never inventoried. Those apps are shadow IT, and IT can't govern an app it doesn't know about. A single app with one owner stays on Base44 unless the reliability, data ownership, or cost row applies.

How Superblocks handles a Base44 migration

Superblocks is a governed enterprise vibe coding platform where business teams build apps with AI and IT sets the controls at the platform level. For a Base44 migration, you import your code into Superblocks, and it runs there under IT governance.

• Import by ZIP. ZIP the root folder of the downloaded project, excluding node_modules/, .git/, and build output. Choose Other and upload it, and Clark by Superblocks analyzes the project and rewrites supported components to run on Superblocks.
  
  The app imports post also names Base44 among supported sources.

• Data layer conversion. The import guide maps Supabase clients to Superblocks integrations, and Supabase Auth and JWT auth to platform-managed authentication and RBAC. Deno functions map to Backend APIs.

• Governance after the import. Role-based access control (RBAC) is included on Teams, while Enterprise adds SSO/SAML/OIDC, audit logs, and source control. The logs record builder activity and permission changes, and IT can query them through the Superblocks MCP server.

• Deployment in your network. On Enterprise, Hybrid keeps production data in your VPC on the major clouds, and Cloud-Prem deploys the full platform in your own AWS, GCP, or Azure account. Source control connects to GitHub and GitLab, among others.

A Base44 export carries code and your records follow separately, so finish Steps 3 to 5 and configure your database integration first, then import.

After the import, search the app for stray base44. references, because the import guide lists conversions for database clients such as Supabase and Prisma and for auth libraries such as Passport but none for the Base44 SDK.

For a production example, Superblocks' Matthews case study reports that a senior marketing manager created OM Builder on Superblocks and cut turnaround on an offering memorandum from 3 to 5 days to 12 hours.

Matthews runs Superblocks inside its AWS VPC with RBAC, and OM Builder is one of the apps there.

On pricing, Teams starts at $125 per month, billed monthly, or $100 per month, billed annually, with RBAC and up to 15 builders. It includes one hosted app per Team. Additional hosted apps cost $10 per app per month.

Above Teams, Enterprise pricing is custom, and the tier adds the governance features above plus Hybrid/VPC or Cloud-Prem deployment.

To try the import on your exported Base44 project, book a demo or start with the import docs. If you also have Lovable apps, the Lovable migration guide explains moving them to Superblocks.

Frequently asked questions

How long does it take to migrate from Base44?

Plan on two to three days for an app with fewer than 10 entities and no backend functions, and one to two weeks for one with login, files, and functions. These are planning estimates, not Base44 figures, and your Step 1 hits show which range applies.

For scale, Replit's docs estimate its import step at four minutes, before any data work.

Can I move a Base44 project to another account?

Partly. Base44's Apps API transfers ownership by email invitation, which expires after 7 days, or immediately to an existing member, and the app stays in its current workspace.

To reach a different workspace, use Move app from the app’s dashboard (Overview, then More actions). You must own the workspace the app is in now, and both you and the app owner need an editor role or higher in the target workspace. Moving the app also disconnects its GitHub sync, so you reconnect it in the new workspace.

Will my users have to reset their passwords?

Yes, if they use email and password. Base44's docs list no hash export, so expect a reset unless that changes. Users who sign in through a provider such as Google, or through SSO, keep using that provider.

Can Superblocks import a Base44 app?

Yes, through the Other source, and Superblocks' app imports post lists from Base44 among its supported sources. Load your data into a database and configure it as an integration first, since a Base44 export is code and your records move on their own path.

Then ZIP the project you downloaded and upload it, and Clark by Superblocks converts the supported components. The docs list no Base44 SDK conversion, so check the result for leftover SDK references.

Do I need a developer to migrate from Base44?

On the manual path, yes, since Steps 3 to 7 involve SQL, server-side functions, and DNS. A done-for-you service or a platform import takes over part of that work, though someone technical has to manage the data and secrets.