How to Export Your Data from Base44

Your data is the most valuable thing in your Base44 app, and it’s the part that customers notice if something goes wrong. This guide covers how to get records, files and users out of Base44 and into a database you own, without losing anything.

This is Step 6 of our full Base44 migration guide. If you haven’t audited your app yet, start there.

What you can export, and what you can’t

Asset	How it comes out	Watch out for
Entity schemas	Base44 CLI, as JSON definitions	They aren’t included in GitHub sync
Table data	CSV export per table in the dashboard, or read through the SDK	Nested fields, arrays, references
Uploaded files	Download from their hosted URLs	URLs in your data still point to Base44
Users	User records (email, name, role)	Password hashes can’t be exported
Secrets & OAuth tokens	Not exportable	Re-create them on your own accounts
Automations & agents	Not exportable	Re-build from your notes

Product capabilities change, so confirm the current export options in your Base44 dashboard before you plan the cutover.

Step 1: Map schemas to tables

Start from your entity schemas. For each entity:

• Create a table with real column types: timestamptz for dates, numeric for money, boolean and uuid where they fit.
• Turn references to other entities into foreign keys.
• Give arrays of objects a child table, or use a jsonb column if you never query inside them.
• Keep the original Base44 ID in a legacy_id column. It makes reconciliation, debugging and URL redirects much easier.
• Keep the built-in fields like created date and created-by, since they’re often needed for ownership and permissions.

Step 2: Export the records

For small and medium apps, the per-table CSV export in the dashboard is the simplest route. For larger tables, or for a repeatable scripted process, read through the SDK with pagination. Keep in mind that API reads are page-limited, so loop until you have every page.

Rules we always follow:

1. Script everything. Keep the export and transform code in version control, because you’ll run it at least twice (rehearsal and cutover).
2. Store raw exports untouched. Transform copies, never the originals.
3. Export parent tables first, so foreign keys resolve on load.

Step 3: Transform and load

Common transformations:

• Normalize date strings to UTC timestamps
• Convert string numbers and currency to numeric types
• Resolve reference fields to the new foreign keys through legacy_id
• Flatten or split nested objects
• Trim whitespace and fix inconsistent casing in enum-like fields

Load inside a transaction per table, so a failed load leaves nothing half-imported.

Step 4: Move files

Files uploaded through Base44 live on platform-hosted URLs. For each file field:

1. Download the file.
2. Upload it to your storage (for example, Amazon S3) under a predictable key.
3. Rewrite the URL in your new database.

Then search the whole database for any remaining Base44-hosted URLs, including rich-text fields where images may be embedded.

Step 5: Migrate users

You can bring user records across. You can’t bring passwords, because hashes aren’t exportable. The standard pattern:

1. Import each user into your new auth provider with their email, name and role, and link them to their records by legacy_id.
2. At cutover, email every user a branded welcome message with a secure password-set link or a magic-link sign-in.
3. Keep social logins (Google, Microsoft and so on) working by setting up the same providers on your own OAuth apps. Users just sign in again.

Done well, customers see “We’ve moved to a faster, more secure platform, click here to sign in,” not a broken login page.

Step 6: Reconcile, then reconcile again

Before cutover, and again after it:

• Row counts per table: exported vs. loaded
• Relationship checks: no orphaned child rows
• Spot checks: 20–50 records compared by hand across key tables
• Totals: sums of money columns match
• Files: every file URL resolves on the new storage

Write the results down. If anyone asks later, you’ll have evidence that nothing was lost.

Step 7: Final sync at cutover

Between your rehearsal and go-live, users keep creating data. At cutover:

1. Freeze writes on Base44 (maintenance mode or read-only).
2. Run the full export, transform and load one last time. It’s quick because it’s scripted.
3. Reconcile.
4. Switch DNS.

Need a safe pair of hands?

Data migration is where a Base44 migration either earns trust or loses it. X & Company’s Base44 migration services include scripted, rehearsed, reconciled data and user migration, with the reports to prove it.

Use the Base44 migration checklist to track every step.