Understand your migration report

The Discovery & readiness report is a starting assessment of your source app. Discovery means collecting the information available from the connected repository and source inspection steps. The report shows that evidence, its gaps, and the work proposed for your target. A target is the Supabase project or other destination you are migrating into.

Partially inspected

Staticbot found some usable information about this area, such as table definitions, function names, or storage buckets. The evidence does not establish that everything in the source has been found or that the migrated app will behave correctly. Read the explanation below the label to see what was actually inspected.

For example, finding a storage bucket establishes that its definition was returned. Checking the files inside it, access permissions, and successful file transfer requires further work. Finding a function name likewise does not prove its secrets are configured or that it runs.

Not established

Discovery has not supplied usable evidence for this area. The source may need additional access or inspection, or the available export may not include it. An empty response can also be inconclusive when a source inspection failed or lacked permission.

This label does not establish that the source contains zero items. Follow any waiting source inspection steps and check the area in your source platform. If the information remains unavailable, account for that gap when reviewing the plan and testing the result.

Observed counts and Count not established

10 observed means discovery returned ten items in the named area. The item type comes from the row: ten tables, ten functions, or ten buckets, for example. It is not a count of migrated database records or proof that the whole source has been inspected. The report may show only a sample of the names even when it has a larger count.

Count not established means a reliable count was not provided. Earlier versions could display only “observed” when the count was missing; read that as an unknown count, not zero. An explicit 0 observed describes the returned evidence and still needs to be interpreted alongside the coverage explanation.

Review needed

A finding needs someone to inspect it and decide what action is appropriate. For example, an integration may need replacement, or a source feature may need a compatibility check. Read the finding's explanation, decide who will handle it, and test the affected behavior before relying on the migrated app.

A review finding and an approval blocker serve different purposes. A finding records work or uncertainty to address. An approval blocker is a condition that currently prevents the plan from starting; those conditions appear beside the approval button.

Who handles each step?

Verification pending

The finding has not been verified as working in the migrated app. Discovery records evidence and expected work; successful verification comes from checking the target and exercising the app. A completed transfer step alone does not verify login, permissions, integrations, or your critical business workflows.

What is the execution plan?

The plan is the proposed sequence of migration jobs, grouped into phases. A job is one unit of work, such as exporting data, applying a database schema, or asking you to configure a provider. A phase groups related jobs. The handling label shows who is expected to carry out each step.

Review the source branch, destination project, destination schema, observations, gaps, and proposed jobs together. A schema is a namespace for database objects, commonly public. A project reference identifies a particular Supabase project. Make sure the target is the intended destination before approving work against it.

Transfer methods and required source or destination checks

A migration strategy is the method Staticbot will use to transfer your app. For example, when a suitable official export is available, the options can include restoring that snapshot or rebuilding the database from the repository's migration files and importing data through the source helper. The available methods depend on your source and destination. Read the options and their consequences on the card shown in your migration.

A source or target readiness gate is a card asking you to complete a check or decision before migration can proceed. It can ask you to deploy and validate the source export helper, select a transfer method, or resolve a destination issue such as insufficient database space or existing data. The source is your current app; the target is its destination.

The report names the card that needs attention, such as Check your source project for an export or Your target project is not empty. Open that card on the same migration page and follow its instructions. A check-only card may ask for a recheck rather than offer a transfer-method choice. Earlier versions used the general message “Choose a migration strategy at the source or target readiness gate.”

Why are the migration steps not ready to review yet?

The execution plan is the list of migration jobs Staticbot prepares from source discovery and the chosen transfer method. When that list is empty, a source inspection, helper deployment, transfer-method choice, branch decision, or destination check may still need to finish. The actions listed beside the approval button explain what is currently required.

Earlier versions said “The execution plan is still being prepared” or “Wait for the migration execution plan to be prepared.” Read those messages as “The migration steps are not ready to review yet.” If a card or job is waiting for your action, complete that action first.

1. Look for waiting jobs and messages elsewhere on the migration page.
2. Complete the requested source or destination check, or make the requested transfer-method or branch choice. See transfer methods and required checks.
3. Read any conditions listed beside the approval button.
4. Use Refresh report after the underlying steps progress, then review the updated proposal.

Refreshing loads the latest available report; it does not deploy a helper, answer a choice, or complete a waiting job. If the plan stays empty with no actionable instructions, contact Staticbot support with the migration link and the waiting job's message.

Report revisions

Revision 2 is a saved version of the discovery evidence, configuration, and proposed work. New evidence or changed choices can require another revision. Approval applies to the particular revision displayed, so review the report again if Staticbot says it changed. A revision number is not a migration attempt number or a count of retries.

After approval, the saved report remains visible as the record of what you approved. Existing migrations may show available discovery evidence with no recorded report approval; that is stated in the report rather than treated as a new approval.

What am I approving?

Approve revision … and start migration starts the migration steps shown in the report in your selected destination project. Check that the destination and proposed work are correct before approving. The report lists the automated steps and any setup or verification tasks for you, such as supplying provider settings or testing sign-in and access permissions after transfer.

Source inspection and any requested source helper deployment can occur while the plan is being prepared. Once those checks and choices are complete, review the resulting steps and approve that saved revision. If a required action is still outstanding, the approval button stays unavailable and the report names what needs to be completed.

Both Streamlined and Guarded migration modes require this initial plan approval. Guarded also asks at later checkpoints. Streamlined reduces those later pauses. Neither mode establishes that every source feature will work automatically.

Plan approval starts the migration process. Releasing a live app still requires verification and a deliberate cutover. See the live app migration guidefor maintenance, a fresh final copy, testing, and switching traffic.

Jobs, retries, and history

A job's status describes that step, such as waiting for your action, running, completed, or failed. A retry makes another attempt at the step. History records earlier work so you can understand what happened. These records serve a different purpose from a report revision, which describes the evidence and proposal you review for approval.

Read the current waiting or failed job's instructions before retrying. Repeating a validation cannot repair an incorrect URL, restore an unavailable source project, or supply missing access.

What is a source export helper?

Some migration paths prepare a temporary function in the source app to inspect or export information that the repository alone cannot provide. Its name may look like staticbot-export-…. An edge function is server-side code called over HTTP. Preparing or committing its source code and deploying it into the source platform are separate steps. Follow the migration job's deployment instructions and keep its export secret private.

A message from Lovable saying the function was deployed identifies the function name. Staticbot still needs to reach the correct project hostname and authenticate to the function before it can continue with source inspection.

Validating the source function

Validation makes a lightweight authenticated request to the export helper. For Supabase, the normal invocation URL is https://PROJECT_REF.supabase.co/functions/v1/FUNCTION_NAME. Copy the full invocation URL from the current source project rather than constructing it from the function name alone. Confirm that it refers to the source app being migrated, including after a remix or a change of project.

If the migration shows a different URL, use its URL override to enter the confirmed invocation URL and validate again. Successful validation can complete the waiting source-sync step and allow inspection to continue. Share URLs without secret query parameters when requesting help.

• DNS lookup failed: the project hostname could not be resolved. Follow the checks below.
• 401: the endpoint rejected authentication. Check that the intended export helper and its expected secret are deployed.
• 404: the requested function was not found at this URL. Confirm the source project, function name, and deployment.
• 546: the function exceeded a runtime resource limit. Inspect the source function's logs to identify the limit and reduce the work it performs.
• Timed out: validation did not finish in time. Check the URL and source availability, then retry.

For provider-specific details, see Supabase's function status codes.

DNS lookup failed: deployed function, unreachable hostname

DNS translates the hostname in a URL into a network address. If that lookup fails, Staticbot cannot contact the function or check its authentication. A deployment confirmation alone cannot establish that the URL shown in the migration reaches that deployed function.

1. Open the current source project's function details and copy its full invocation URL.
2. Compare the project reference and hostname with the URL in the migration. Check the active project rather than an older repository configuration or remix.
3. Check the project's status in the source platform. Restore a paused project if appropriate, or obtain the correct URL if the reference is wrong.
4. If the hostname is correct and the project is active, check DNS from another network or public resolver and ask the source provider to investigate persistent failures.
5. Once the hostname resolves, validate the confirmed URL in Staticbot. Authentication or function errors may then require their own checks.

Supabase documents wrong project references, paused or deleted projects, and resolver problems as possible causes of NXDOMAIN, a response meaning the queried DNS name does not exist. The DNS result alone does not identify which cause applies. See Supabase's DNS troubleshooting guide.