How to Migrate Off Base44 (Step-by-Step)

Base44 is a very good way to go from idea to working app. What it isn’t is a place you fully own. If you’ve decided to migrate off Base44, whether because of cost, control, compliance or just peace of mind, this guide goes through the whole process in the order we use on real projects.

It’s long because a migration is more than an export button. Skim the headings, then come back to each step when you reach it.

Short version: exporting your code gets you the frontend. A real Base44 migration means rebuilding the backend the SDK was hiding, moving your data and users, and deploying everything to infrastructure you control.

Before you start: what a Base44 migration really is

A Base44 app has two halves:

1. The frontend. This is a React app, built with Vite and Tailwind, that you can see and export.
2. The platform behind it. This is a database, authentication, file storage, backend functions (on a Deno runtime), integrations like LLM calls and email, automations and permission rules. Your frontend reaches all of it through the @base44/sdk.

The export features give you the first half. The second half doesn’t come with the ZIP. Your exported code still makes network calls like base44.entities.Order.list() and base44.auth.me() to servers you don’t run. So if you “export” and then cancel your plan, the app stops working.

The steps below are how you close that gap.

Step 1: Export your code

On the Builder plan and above, Base44 gives you two ways to get code out:

• ZIP download. A one-time snapshot of the app.
• GitHub two-way sync. A live repository you can clone and edit in VS Code, Cursor or Claude Code.

We recommend GitHub sync because you get history and can keep working while you plan. The Base44 CLI can also pull entity schemas (JSON definitions of your data model) and backend function source files. Get those too, because they become the blueprint for your new database and API.

While you’re in the dashboard, export every table as CSV now as a baseline, even though you’ll do a final export at cutover.

Step 2: Audit every Base44 dependency

This step decides how long the migration takes and how much it costs. In your exported repository, search for every place the app touches the platform:

grep -rnE "base44\.(entities|auth|integrations|functions|agents)" src/

Build a simple inventory table:

SDK call	Where it’s used	What replaces it
base44.entities.Order.filter()	Orders page, dashboard	GET /api/orders
base44.auth.me()	Layout, route guards	Auth provider session
integrations.Core.SendEmail	Invite flow	Postmark / SES
integrations.Core.UploadFile	Profile photos	S3 bucket
integrations.Core.InvokeLLM	AI summaries	Your OpenAI / Anthropic key

Also write down anything that doesn’t show up in the code: automations, scheduled jobs, agents, row-level permission rules and connector credentials. These live in Base44’s configuration, and they’re the things that most often get missed.

Step 3: Design your target stack

You’re replacing a platform, so pick one component for each service it gave you. A common, boring-in-a-good-way stack looks like this:

• Database: PostgreSQL. It can be managed (AWS RDS, Supabase, Neon) or run on your own server.
• API: Node.js with TypeScript (Express, Fastify or Hono) and an ORM such as Prisma or Drizzle.
• Auth: Auth.js, Clerk, AWS Cognito, Keycloak, or Supabase Auth.
• File storage: Amazon S3 or any S3-compatible bucket.
• Email / SMS: Postmark, Amazon SES, Resend, Twilio.
• AI features: Your own OpenAI, Anthropic or other provider account.
• Hosting: An AWS EC2 Ubuntu server with Nginx and Certbot SSL, a VPS, or a managed platform. Our self-hosting options guide compares them.

Keep the first version close to what you had. A migration is not the time for a redesign.

Step 4: Rebuild the backend

With the inventory and target stack decided:

1. Turn entity schemas into database tables. Base44 entities are JSON-like documents. Map each one to a table with proper types, foreign keys and indexes. Watch for arrays and nested objects, which may need their own tables or JSONB columns.
2. Write the API to mirror the SDK. For each SDK call in your inventory, create an endpoint that returns the same shape of data. That keeps the frontend changes small.
3. Port backend functions. Base44 functions run on Deno, so most of the TypeScript can move over with small changes to imports and environment variables.
4. Re-implement permissions. Base44’s permission rules (for example, “users can only see their own records”) have to become explicit checks in your API. Don’t skip this step. It’s where security bugs come from.
5. Re-create automations as cron jobs or queue workers.

Step 5: Replace the SDK in the frontend

Create one API client module and swap calls across the app:

// Before
import { base44 } from '@/api/base44Client';
const orders = await base44.entities.Order.filter({ status: 'open' });

// After
import { api } from '@/lib/api';
const orders = await api.orders.list({ status: 'open' });

If you mirrored the SDK’s return shapes in Step 4, the UI should keep working with very few other changes. When you’re finished, remove @base44/sdk from package.json. If the build still passes, you’ve found every call.

Step 6: Migrate data, files and users

This is the step that matters most to your customers. Our Base44 data export guide covers it in detail. In summary:

• Data: Export each table, transform the rows (IDs, dates, nested fields, references), load them, then reconcile row counts table by table.
• Files: Download uploaded files from their Base44-hosted URLs, upload them to your storage, and rewrite the URLs in your data.
• Users: Import user records into your auth provider. Password hashes can’t be exported, so plan a password-reset or magic-link email that welcomes users to the new app.

Do a full rehearsal on staging before the real cutover.

Step 7: Deploy to your own server

A solid baseline for a single-server deployment:

1. An AWS EC2 instance running Ubuntu LTS with an Elastic IP.
2. Nginx serving the built frontend and proxying /api to your Node process, which is managed by systemd or PM2.
3. Certbot for free, auto-renewing Let’s Encrypt SSL.
4. A firewall that only allows ports 22 (restricted), 80 and 443.
5. Automated database backups and a tested restore.
6. CI/CD that builds on push and deploys to staging, then production.
7. Uptime monitoring and error tracking.

Test everything on a staging subdomain with real (anonymized) data.

Step 8: Cut over and decommission

1. Announce a short maintenance window.
2. Freeze writes on Base44 and run a final data and file sync.
3. Lower the DNS TTL beforehand, then switch DNS to your server.
4. Verify sign-in, core flows and payments with real accounts.
5. Send the user welcome and reset emails.
6. Keep the Base44 app read-only for a few weeks as a fallback, then cancel.

How long does it take?

That depends on what Step 2 finds. A small app with a handful of entities and no integrations is a short project. A multi-tenant product with AI features, automations and thousands of users takes more planning, mostly in data and user migration. The audit is what turns “it depends” into a real number.

DIY or hire help?

If you have a developer who knows React, SQL and Linux hosting, and time to rehearse the cutover, this guide is enough to do it yourself. If the app earns revenue and you can’t afford a botched login or missing records, it’s worth having people who’ve done it before.

Base44 migration services by X & Company cover every step above, from audit to cutover, for a fixed-scope quote. Before you start, go through the Base44 migration checklist either way.