How to Migrate a Base44 App Onto Infrastructure You Actually Own

If the app should stay on Base44, check whether you need an ownership transfer or a workspace move. Neither operation moves the application off Base44. Base44's workspace documentation says the current owner can transfer to an existing collaborator who is also a workspace member with an editor role or higher. Open the editor's collaborators panel, choose the person and select Make app owner. Review connected services during the handover. A workspace move changes the managing workspace while retaining the app owner. Its permissions and plan conditions differ. Follow the vendor's current instructions rather than assuming an invitation, clone or export transfers ownership. Before handing over, agree who controls billing, domains, integrations and recovery. Test the new owner's access. Continue with this guide if the objective is to run the application on infrastructure outside Base44.

Every data read, every login and every backend call in a Base44 app is a call through the Base44 SDK to Base44's servers. Remove the platform and the frontend has nothing to talk to. Base44's public quickstart shows the pattern in three lines. You create a client with your app ID, then call `base44.entities.Products.list()` to read data and `base44.auth.loginViaEmailPassword()` to sign a user in. Those are not local functions. They are network calls to a runtime you do not host. According to Base44's developer documentation, the pieces behind those calls are a MongoDB-compatible database (their words: "The database is MongoDB compatible, allowing you to use all MongoDB operators when querying through the SDK"), Deno-based serverless backend functions, and a built-in authentication service handling registration, login and session management across email and password, Google, Microsoft, Facebook, Apple and custom SSO. The frontend is React and Vite with Tailwind CSS and shadcn/ui, which is the genuinely portable part. So when people ask whether Base44 lets you own your code, the answer is that the question is aimed at the wrong layer. You can hold every line of the frontend and still not be able to run the app, because the database, the auth service, the file storage, the scheduled jobs and the agents all live somewhere else. A migration is not a file transfer. It is rebuilding a backend.

Base44's documentation states plainly that "Base44 site hosting currently supports Single Page Applications (SPAs) only." There is no server-side rendering and no server components, which is a real constraint if search traffic matters to your product. A single-page app ships an empty HTML shell and builds the page in the browser. Google can render JavaScript, but rendering is queued separately from crawling, it is slower, and it is less reliable for large or slow-loading pages. AI answer engines are stricter again: many retrieval pipelines read the raw HTML response and do not execute JavaScript at all, so a page whose content only exists after hydration is a page with no content as far as they are concerned. For an internal tool, a dashboard or a logged-in product, this does not matter. For anything with marketing pages, a blog, a directory, product listings or location pages, it is a permanent handicap that no amount of on-page work fixes. You cannot add server rendering to Base44 hosting, so the only fix is to host the frontend somewhere that supports it. This is worth naming because it is one of the few migration triggers that is not about a bug or a limit you have hit. It is a ceiling that exists from day one and only becomes visible when you start caring about organic traffic.

Base44 offers three ways to get code out and a separate per-table CSV export for data. None of the four is an exit, and one of them is actively confusing. | Method | What you get | What is missing | |---|---|---| | ZIP download (Builder tier, US$40 a month, about A$61) | React frontend source plus custom backend function source | Live data, users, files, secrets, entity schemas, a working backend | | GitHub two-way sync (Builder tier, beta) | The same code, synced both ways, editable in VS Code, Cursor or Claude Code | Entity schemas are excluded from the repository, and so are live database records | | CLI `base44 eject` | Frontend, entity schemas, backend functions, config files | Creates a new backend on Base44 with a new app ID and an empty database | | Per-table CSV export | The rows and fields Base44 exposes, one table at a time | Hidden and private fields, private auth records, password hashes, agents, conversations, automations, secrets | The `eject` command deserves a warning of its own. The name suggests it removes you from the platform. According to Base44's documentation it does the opposite: it stands up another Base44 backend with a fresh app ID and an empty database. It is a project-scaffolding command, not an exit ramp, and mistaking one for the other costs you a day. The detail that settles the argument is an environment variable. The exported frontend needs `VITE_BASE44_APP_BASE_URL` set to a Base44 address. That variable exists because the exported code is a client. Cancel the subscription and every screen that reads or writes data stops working.

Four categories of thing simply do not come out of Base44 in any format: private authentication records, file URLs, backend function runtime configuration, and everything in the automations and agents layer. The authentication problem is the one with a customer-visible cost. User accounts survive as CSV rows, so you keep the email addresses. The private authentication record behind each user does not export, which means nobody can sign in with their existing password after you move. Every real user gets forced through a password reset, and a forced reset on a product people use casually is a churn event, not an inconvenience. File fields point at URLs still served by Base44. Each one has to be downloaded, re-uploaded to your own storage and rewritten in the database. Miss some and they keep working right up until the subscription lapses, then break quietly and in no particular order. Backend function source exports without its entry point, runtime, dependencies, secrets, public URL, permissions or the automation that triggers it. You get the body of the function and none of the context that made it run. Automations themselves, along with their schedules, entity triggers, arguments and execution identity, plus agents, conversations, memories, connectors and OAuth configuration for custom integrations, appear in no export at all. They have to be rebuilt from observed behaviour. This list comes from EscapeBase44, a company that sells Base44 migrations and therefore has a commercial interest in the work sounding hard. We are citing it because the technical claims line up with Base44's own documentation and its published SDK, not because the vendor said so. Their summary line is fair: "An export gives you the files. A migration is what gets the app out of Base44."

Base44's data documentation records two limits that shape how you plan a migration: deleted records are retained for 30 days and then "permanently deleted and cannot be restored", and since 27 November 2025 there is a cap of 5,000 items per request. The 5,000-item cap is the practical one. If a table holds more rows than that, pulling the data out means paginating, and paginating means writing a script against the SDK rather than clicking the CSV export button. Budget for that. The 30-day retention window matters in the other direction: if something is deleted during the migration and you notice in week six, it is gone. The ownership context changed in June 2025, when Wix acquired Base44. Wix's press release of 18 June 2025 puts the initial consideration at approximately US$80 million (about A$122 million at a rate of 1 AUD to 0.655 USD), plus earn-out payments through to 2029 contingent on performance. Base44 was roughly six months old with about six employees at the time. What the acquisition changed in practice is hosting, which now runs on Wix infrastructure, and distribution. What it did not change is the SDK-mediated architecture. The export story is the same before and after. We want to be precise here: we could not retrieve Base44's terms of service, so we make no claim about what their contract says regarding code ownership. Everything in this guide is checkable in the developer documentation and the public SDK, and that is deliberate.

Do the migration in this order: dependency audit, security audit, authentication, database, secrets, storage, automations, monitoring, then verification against real accounts. Skipping straight to copying components feels like progress and produces nothing testable. Start by grepping the frontend for every `base44.entities.*`, `base44.auth.*` and backend function call. Each hit is a service you have to replace, not a URL you can re-point. That list is your actual scope of work, and it is usually longer than anyone expected. Run a security audit before anything moves. Escape scanned 5,600 publicly available vibe-coded applications on 29 October 2025 and found 2,038 highly critical vulnerabilities, more than 400 exposed secrets and 175 distinct instances of exposed personally identifiable information including bank account data. Escape's own caveat is that they scanned passively, so the findings "reflect only a subset of exploitable issues". Migrating a vulnerable app just relocates the breach. Then authentication, in isolation, before anything else. It is the largest single time sink and nothing downstream can be properly tested while it is broken. Plan the forced password reset, write the email, and decide when to send it. Database next. MongoDB-compatible documents have to be remodelled for whatever you are moving to, and record IDs, relationships and field types all have to survive intact or referential integrity breaks without any error message. Rotate every secret rather than transplanting it, because Veracode's 2025 GenAI Code Security Report found that when models were given a choice between a secure and insecure implementation across 80 curated tasks and more than 100 large language models, they chose the insecure one 45% of the time. Assume anything that lived in generated code is compromised. Storage, automations and monitoring follow, and then you verify with real accounts and real data. The failure mode of a botched migration is not a crash. It is an app that looks finished while a customer sees someone else's data.

The cost of leaving Base44 is not proportional to how complex your app is. It steps up sharply the moment you have real user accounts, real uploaded files and real automations carrying state. Before that point, a migration is mostly a rebuild of a backend you already understand, with a database you can seed from scratch. After it, you are also managing a forced password reset across your user base, a file URL rewrite you cannot fully verify, and a set of automations you have to reverse engineer from behaviour because they were never exported. Same app, very different job. That gives you a reasonably clear decision rule. If Base44 is doing what you need, you have no organic search requirement, and the app is a prototype or an internal tool, stay. The platform is fast and the constraint is not biting. If you are building something with public pages that need to rank, or something you intend to run for years, or something where a single customer seeing another customer's data would be a serious incident, move earlier rather than later. Our view, and this is opinion rather than sourced fact: the honest version of "you own your app" is being able to run it after the vendor is gone. On that test, a Base44 export does not clear the bar, and the earlier you deal with that the cheaper it is. The code ownership checklist is a reasonable starting point if you want to check where you stand before committing to anything.

Does exporting my code from Base44 mean I own my app? You own the frontend source and the source of your custom backend functions. You do not own or hold the database, the authentication service, the file storage, the function runtime or the automations layer, all of which stay on Base44's servers. The exported app still needs `VITE_BASE44_APP_BASE_URL` pointed at Base44 to work, which is the clearest proof that the export alone is not independence. What does the `base44 eject` command actually do? It gives you the frontend, entity schemas, backend functions and config files, and then creates a new backend on Base44 with a new app ID and an empty database. Despite the name, it does not eject you from the platform. Treat it as a scaffolding command for starting a fresh Base44 project rather than as a migration tool. Will my users be able to log in after I migrate? Not with their existing passwords. User records export as CSV rows, but the private authentication record behind each account does not, so every real user has to go through a password reset. Plan the reset email as part of the migration rather than discovering it on cutover day, and expect some drop-off from users who never complete it. Can I get all my data out at once? Not through the dashboard. The CSV export runs one table at a time, and since 27 November 2025 the API returns a maximum of 5,000 items per request, so anything larger needs a paginated script written against the SDK. Deleted records are retained for 30 days and then permanently removed, so verify your extract before you delete anything. Did the Wix acquisition change what I can take with me? Not architecturally. Wix acquired Base44 in June 2025 for approximately US$80 million (about A$122 million) plus earn-outs through 2029, and hosting moved onto Wix infrastructure. The SDK-mediated design and the export mechanisms are the same before and after. We were unable to retrieve Base44's terms of service, so we make no claim here about their contractual ownership position. Is it cheaper to rebuild than to migrate? Sometimes, and it is worth pricing both. If the app is small, the generated code is disorganised and you have few real users, a clean rebuild against a stack you control can take less time than untangling an export. If you have live users, uploaded files and automations in production, migration usually wins because a rebuild has to replicate all of that anyway plus everything else.