Before you say yes: what to get from the client
One MSP on Reddit summed up the usual policy: “We try to say yes, so as long as the bounds are there”. In practice that means code backed up and data that isn’t exposed. With a Base44 app, getting there starts with eight answers:
- Workspace. Which Base44 workspace the app lives in: the employee’s personal one or a company workspace.
- Plan and billing. Which plan, on whose card, and how many credits the published app uses each month.
- Code backup. Whether GitHub sync is on (Builder plan or higher), and whether the repository belongs to the company’s GitHub organization or to a person.
- Editors. Who can change the app today, and whether anyone on that list has left the company.
- Secrets and integrations. Which API keys and connected services the app uses, and whose accounts they are.
- Data. What the app stores (customers, staff, money) and whether any of it is regulated.
- Who can open it. Whether the published app is public or private, and how people sign in.
- AI training. On every plan except Enterprise, Base44’s license allows the content to be used to train AI models. Make sure the client knows.
If the app sits in someone’s personal workspace, on their card, with no GitHub sync, the company doesn’t really hold it. That’s the first thing to fix, whatever route comes next.
On the client’s servers, the code is in their repository and the data is in their database, so most of these questions answer themselves.
What you can’t control while it runs on Base44
Base44’s security overview says each app’s security is the responsibility of whoever builds it. For an MSP, that lands on you as soon as you say yes. These are the parts you can’t reach:
- The sign-in layer. Company SSO for the app is only on the Enterprise plans (Business or Enterprise), sold through sales. On public plans you can’t tie access to the client’s directory.
- Security settings per app. Session tokens are kept in the browser’s local storage, and you can’t set your own security headers (CSP, HSTS) for one app.
- Production backups. The data lives in Base44’s database. You can download tables as CSV by hand, but backend functions, sign-in and uploaded files stay on Base44.
- Changes to the platform. Plans, credits and features change on Base44’s schedule. The client’s app has to follow.
Base44 takes care of the platform. What falls outside your tools is the layer they normally watch over for a client.
On the client’s servers, sign-in, backups and the database sit in tools you already manage and monitor.
Who really owns the app: workspace, owner and plan
The most common mistake when a company “takes over” a Base44 app: making someone in the company the app’s owner and thinking it’s done. Base44’s documentation says apps belong to the workspace where they were created and use that workspace’s plan and credits, whoever is working on them.
The order that works:
- Create a company workspace, with the company as owner and you as admin if your contract covers it.
- Move the app into it. Only the app’s owner can do it, the data goes with it, the credits don’t, and moving from a personal workspace to a shared one can’t be undone.
- Change the owner if needed. The new owner has to accept. For each connected service you choose to keep or disconnect it, so the client can reconnect their own accounts.
- Turn on GitHub sync to a repository in the company’s organization.
Handing an app to someone outside the workspace directly is only available on the Enterprise plans and for approved Base44 Partners. This section comes from Base44’s documentation as of October 13, 2026: check it again before you do it, because these pages change often.
Enterprise, a one-time migration or the hybrid model: which fits
Base44 Enterprise answers the sign-in question and adds audit logs. The app and its data stay in Base44’s cloud, production keeps spending credits, and the price comes from sales. It fits when sign-in is the only objection and the client is happy with the cloud.
A one-time migration moves the app off Base44 for good. You get the code and the data, and you lose the editor: from then on, every change is a developer’s job. It fits when the client has a developer who will own that code.
The hybrid model is the only one where both things are true: the app runs on the client’s servers, inside your bounds, and the person who built it keeps building it in Base44. It suits a client who doesn’t want to give up the tool they built the app with.
The hybrid model: the client keeps building, the app runs inside your bounds
Keep44 moves the app’s backend to a Windows server (IIS, SQL Server and Node.js), at the client’s site or one you run for them. The client keeps editing in Base44 with test data. Each change goes through GitHub to the server, with a backup first and a way back.
What that gives an MSP, piece by piece:
- Backups you control: the real data is in SQL Server, in the backup plan you already run. Each sync takes a backup before it touches anything.
- A way back: if a change from Base44 breaks something, the server goes back to the previous version.
- Company sign-in: people use their Entra ID account with MFA. Roles come from Entra, and someone disabled there is logged out within minutes. Details in the guide to Base44 SSO with Microsoft Entra ID.
- No credits in production: employees using the app don’t spend Base44 credits. The client only needs a plan to keep editing.
- The client keeps building: a new field or screen made in Base44 reaches the server without a ticket to a developer.
Tested in the lab on October 6 to 8, 2026: Windows Server 2025, IIS, SQL Server, Node.js and a free Entra ID tenant, with a demo app built in Base44. Changes made in the editor, new fields included, reached the server with a backup first, and rolling back took 12 seconds. Whether it fits your client’s app is confirmed in the Diagnosis.
Where Keep44 fits: the Base44 part, and the client stays yours
Supporting one app shouldn’t turn an MSP into a development shop. In the hybrid model the work splits like this:
| Who | Does |
|---|---|
| Keep44 | The Diagnosis, moving the backend, setting up the sync and sign-in, and the handover document |
| You, the MSP | The server, backups, monitoring, users in Entra and the client relationship |
| The client | Keeps building the app in Base44 |
The Diagnosis report is written so you can quote from it. Keep44 doesn’t sell server or support contracts to your client. If the full IT question list helps, the Base44 security review checklist for IT covers it, and the guide to running a Base44 app on-premise explains the move step by step.
When Keep44 isn’t the answer: if the client already has a Base44 Enterprise plan and accepts the app in the cloud, set the bounds inside Base44 with the list above. If the client wants to leave Base44 for good and has a developer to own the code, a one-time migration is simpler.
What to put in writing with the client
To paste into the onboarding ticket or the agreement. Each point needs an answer before you take the app on.
- Workspace: the app lives in a company workspace, not a personal one.
- Plan: who pays for Base44, and who is told when the plan or credits change.
- Code: GitHub sync on, to a repository in the company’s organization.
- Editors: the list of people who can change the app, reviewed when someone leaves.
- Secrets: every API key and connected service, and whose account it is.
- Data: what the app stores, and how and how often it’s backed up.
- Sign-in: who can open the app and how someone who leaves is removed.
- Scope: what you support (access, backups, uptime) and what you don’t (changes to the app itself).
If you’re the one who built the app
Your MSP isn’t trying to take the app away from you. The questions above are what lets them say yes. In the hybrid model you don’t rebuild anything: you keep changing the app in Base44, and the changes reach the company server. Send your MSP this guide with the answers you already know.
Sources
- Base44: Managing your workspace apps (apps belong to their workspace, moving workspaces, changing the owner, transfers outside the workspace). Accessed 10/13/2026.
- Base44: Transfer ownership to a workspace member (beta API, apps with secrets or integrations excluded). Accessed 10/13/2026.
- Base44: Security overview (each app’s security belongs to its builder, session tokens, headers). Accessed 10/8/2026.
- Base44: Setting up SSO (app SSO on the Enterprise plans). Accessed 10/9/2026.
- Base44: Pricing (public plans, Enterprise through sales, GitHub sync). Accessed 10/13/2026.
- Base44: for agencies (partner program). Accessed 10/13/2026.
- Base44: Terms of Service update, June 2026 (license for training AI models). Accessed 10/8/2026.