The Base44 Migration Checklist

Most failed migrations don’t fail on the hard parts. They fail on the forgotten parts: a scheduled job nobody knew existed, a file URL that still points at the old platform, or a permission rule that never got ported.

This Base44 migration checklist is the list we run through on every project. Print it, copy it into your project tracker, or use it to check someone else’s migration plan.

Tip: if you’re still deciding whether to move, go through the readiness check on the home page first.

Phase 1: Inventory

• Confirm your Base44 plan allows code export (Builder or above)
• Turn on GitHub two-way sync, or download a ZIP of the app
• Pull entity schemas and backend function files with the Base44 CLI
• Export every table to CSV as a baseline snapshot
• List every entity, with approximate row counts
• List every backend function and what triggers it
• List every integration in use (LLM, email, SMS, file upload, image generation, data extraction)
• List every connector (OAuth apps like Google, Slack, Stripe) and which account owns it
• List every automation, scheduled job and agent
• Document every permission rule for each entity
• Record your custom domain, DNS provider and current DNS records
• Note any third-party services that call into your app (webhooks, Zapier and so on)

Phase 2: Code audit

• Search the code for base44.entities, base44.auth, base44.integrations and base44.functions
• Map every SDK call to the page or feature that uses it
• Find the environment variables and secrets the functions rely on
• Check for hardcoded Base44 URLs, including file links and API endpoints
• Decide what to keep, fix or drop. Migrations are a good time to delete dead features, not to add new ones.

Phase 3: Target architecture

• Choose the database (PostgreSQL is the usual default)
• Choose the API framework and ORM
• Choose the auth provider and login methods (email/password, Google, Microsoft, SSO)
• Choose file storage (S3 or compatible)
• Choose email, SMS and AI providers, and create the accounts in your company’s name
• Choose hosting (see the self-hosting options)
• Plan staging and production environments
• Decide the backup policy and retention

Phase 4: Build

• Database schema created from the entity definitions, with indexes and foreign keys
• API endpoints that mirror every SDK call
• Permission checks re-implemented on the server, and tested
• Backend functions ported and tested
• Automations re-created as cron jobs or queue workers
• Integrations re-wired to your own provider accounts
• @base44/sdk removed from package.json, and the build passes
• Secrets stored in a secrets manager or environment, never in the repository

Phase 5: Data, files and users

• Transformation scripts written and version-controlled
• Full rehearsal migration run on staging
• Row counts reconciled for every table
• Spot-checks of relationships, dates, currency and time zones
• Files copied to your storage, and URLs rewritten in the data
• Users imported into the new auth provider
• Password-reset or magic-link email written and tested
• Roles and ownership (who owns which records) verified

Phase 6: Hosting and security

• Server provisioned (for example, EC2 Ubuntu LTS with an Elastic IP)
• Firewall or security group: SSH restricted, and only 80/443 public
• Nginx configured, with Certbot SSL issued and auto-renewal tested
• Security headers set (HSTS, CSP, X-Content-Type-Options)
• Automated backups running, and a restore tested
• Uptime monitoring and error tracking on
• CI/CD pipeline deploying to staging and production

Phase 7: Cutover

• DNS TTL lowered at least 24 hours before cutover
• Maintenance window announced to users
• Writes frozen on Base44
• Final data and file sync run, and counts reconciled again
• DNS switched
• Sign-in, core flows and payments tested with real accounts
• Welcome and reset emails sent
• Rollback plan written down and owned by a named person

Phase 8: After launch

• Base44 app kept read-only as a fallback for 2–4 weeks
• Error logs and support inbox watched closely for the first week
• Webhooks and third-party integrations updated to the new URLs
• Runbooks written for deploy, backup, restore and incident response
• Base44 plan cancelled once you’re confident

Want a second pair of eyes?

A checklist tells you what to do. The hard part is knowing what your specific app hides in each item. X & Company runs this exact list as the audit step of every engagement. Get a free Base44 migration assessment and we’ll tell you where your app’s risks are before you commit to anything.

For the full walkthrough behind each phase, read how to migrate off Base44.