← Documentation

Running a Migration

A migration is four distinct steps, and the order matters: analyze, review, migrate, validate. The review step is the one people skip and the one that decides whether the result is correct — analysis reports exactly which type conversions lose information, before anything is written to the target.

Before you start

  • A project with both connections tested.
  • A target you are willing to have truncated — a full migration clears the target tables first.
  • Enough space on the target for the data plus its indexes.

Steps

  1. 1

    Open your project from the Dashboard

  2. 2

    Click 'Analyze' to scan the source schema — this detects tables, columns, indexes, FKs, and potential data loss

  3. 3

    Review the Schema tab for type mappings, data loss warnings, and table statistics

  4. 4

    Click 'Migrate' to start data transfer — progress streams in real-time via Server-Sent Events (SSE)

  5. 5

    After migration, click 'Validate' to compare row counts and data integrity

  6. 6

    Export a report from the Report tab (HTML or JSON)

What goes wrong

A row count is not proof

Equal counts on both sides say nothing about whether the values survived. Validation compares type-aware checksums per table as well as counts, which is what catches a truncated decimal or a timezone shift.

Foreign keys are applied after the data, deliberately

Loading in dependency order cannot resolve a cycle or a self-referencing tree, so constraints are applied once the rows are in. If a constraint then fails, the run does not report a clean success — the failure is surfaced as a warning.

Rows that cannot be inserted are quarantined, not dropped

A batch that fails is retried row by row, and the rows that still fail are quarantined with the driver's error. Check the quarantine before treating a run as finished — this is where an encoding or type problem shows up.

Next

Understanding Data Loss Warnings

What HIGH, MEDIUM and LOW actually mean in the data-loss report, and which warnings you can accept.

Going Live with Cutover

Move production traffic to the migrated database, with a verification gate that refuses to flip unless the two sides provably match.

Using the Query Playground

Run read-only SQL against either side of a project to spot-check data after a migration.