Platform migration scope: functions, data and integrations

A useful migration quote starts with what the application depends on, not just how many pages it has. This worksheet helps you describe the work without sharing credentials or exporting customer data.

Download the plain-text migration worksheet, fill in what you know and mark the rest as unknown. It is a scoping aid, not an automated price or a security assessment. A developer still needs to verify the implementation.

Choose the relevant service: Base44 migration, Lovable migration or general platform migration.

Planning a Base44 move? Use the dependency matrix and cutover checklist after completing the general scope.

1. Define the reason and the boundary

What requirement is the current setup failing to meet? Examples include deployment control, a specific integration, query performance or a maintenance workflow. Record an observable problem rather than assuming leaving a platform will solve it.

Decide what you are considering moving: frontend hosting, backend/data, development tooling or the whole application. State anything you want to keep. An app can change hosting without changing its editor, and a frontend can continue using the same backend.

2. Count functions, then describe their responsibilities

List backend functions, API routes, scheduled jobs and queue workers. For each, record its purpose, caller, privileged operations, external services and expected failures.

A synthetic example: one function reads a public catalog; another processes subscription events, updates entitlements and retries failed notifications. Both count as one function, but they are not equivalent units of migration work.

Mark duplicate or unused functions for investigation. Do not delete them during scoping: an integration or schedule may still call an endpoint that the interface no longer references.

3. Map integrations and side effects

List payments, email, AI providers, analytics, CRM connections, OAuth providers and incoming webhooks. Record whether each has a test mode and who owns the provider account.

Include return URLs, webhook destinations and recurring work that needs to change at cutover. A successful import does not prove that a payment update or scheduled email still reaches the right system.

Share provider names and responsibilities, not API key values. I arrange access securely once the engagement is agreed.

4. Describe data and access

Record approximate data volume, entities or tables, key relationships and file-storage size. Identify unusual fields, duplicate identities and historical data that must be preserved. Sensitive categories can be described without attaching examples.

List user roles, shared workspaces, administrators and the ways access changes. Authentication credentials, user profiles and app records have separate migration requirements. Do not assume that copying the users table preserves passwords, OAuth identities or active sessions.

5. Make cutover and recovery explicit

Can the app pause writes during a maintenance window? If not, explain how new changes will reach the target until the switch. Identify who controls domains, deployment and provider configuration.

Define what would trigger rollback and how data created after the switch would be handled. A backup is useful only if there is a workable restore path. Agree which restore and business-flow checks should be rehearsed.

6. Set acceptance checks

Choose the workflows that must work before launch: sign-in, account recovery, a private record read, staff access, a paid action, a file download and the key integration for your product.

Use permitted and rejected cases. A record-count comparison should be accompanied by relationship and value checks. Keep tests isolated from real payments, customer emails and destructive production operations unless a specific safe procedure is agreed.

Base44 dependency matrix: what actually moves?

Moving development to GitHub and moving a running application off Base44 are separate decisions. Start by choosing which one solves your problem. You may only need a developer working in your repository while the backend stays where it is.

As of 24 September 2026, Base44 documents two-way GitHub sync on Builder and higher plans. Its eject workflow creates a separate Base44 backend and downloads the frontend and backend resources. That new backend starts with an empty database. Neither operation, by itself, establishes an independent production deployment. GitHub integration, eject workflow.

The SDK also supports external applications that continue using Base44 as their backend. Privileged service-role operations are documented as available only inside Base44-hosted backend functions. A function that depends on those operations therefore needs more than a new hosting URL. Base44 client documentation.

Use the table below to separate reusable code from services that need to stay, move or be replaced. “Verify” means the answer must come from the actual project and provider, not from the presence of a folder in an export.

The table is deliberately not a claim that Base44 exports every listed component. It is the inventory to complete before agreeing that a component can move.

Choose the smallest useful migration

If the problem is the editing workflow, use local development and keep the managed services. If it is frontend hosting, investigate a separately hosted interface that still uses the existing backend. Confirm authentication and platform constraints in a staging build first.

If the requirement is independent data, authorization or backend operation, plan those replacements explicitly. Managed Postgres with a managed authentication service is one option. An application server, database and object store is another. The choice should follow the app's permissions, workload, background tasks and the team's ability to operate it. A small product does not automatically benefit from managing more infrastructure.

Keep working screens and useful business logic where they fit. Migration does not require redesigning the product or converting every React application to Next.js.

A staged cutover checklist

1. Define success. Write down the specific requirement and the components that will remain on Base44. Assign an owner to every unknown in the matrix.
2. Rehearse in isolation. Build the destination with synthetic or appropriately protected authorized data. Disable real customer notifications and charge-producing integrations.
3. Verify behaviour. Check sign-in, account recovery, permissions, files and the product's paid workflow. Record the source revision and test results.
4. Plan the final data change. Use an agreed write pause, or an engineered synchronization process if a pause is unacceptable. Include external webhook events arriving during the window.
5. Switch with a decision point. Name the person who can stop the cutover, the observations that trigger that decision and the maximum acceptable interruption.
6. Reconcile and hand over. Check records, relationships and critical flows on the target. Retain the previous environment for the agreed period before decommissioning it.

Rollback needs a data plan. Once the destination has accepted new orders or edits, changing DNS back may leave those changes behind. Specify how post-switch writes will be captured and reconciled, or how you will repair the release in place. Do not promise instant rollback merely because the old deployment still exists.

For each rehearsal, record:

Workflow:
Source revision and destination deployment:
Synthetic account / fixture:
Expected permitted action:
Expected rejected action:
Observed result and evidence location:
Unresolved dependency and owner:
Cutover gate: ready / blocked / accepted limitation
Post-switch data recovery method:

What affects the quote

Function complexity, provider constraints, identity transfer, data quality and downtime tolerance can matter more than the number of screens. The target stack also changes the ongoing responsibility for backups, patching, monitoring and support.

I use this inventory to agree a paid migration scope and written quote. It does not assign a universal price per function or promise that every migration is faster and cheaper than staying put.

Request a developer-verified migration quote. Tell me what you know, including the unknowns. Never paste secrets into the worksheet or the enquiry.