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.

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. We 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.

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.

We 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 us what you know, including the unknowns. Never paste secrets into the worksheet or the enquiry.