MySQL to Databricks

fa source inspect mysql
fa source plan mysql --variant mysql
fa source plan mysql --variant aurora_mysql --json

Variants are MySQL, Amazon Aurora MySQL, Amazon RDS for MySQL, and MariaDB. Inventory tables, views, routines, triggers, event schedules, binlog change data, and downstream applications before planning waves.

What Airlift adds

• A governed estate with the exact platform variant and opaque connection reference.
• Explicit disposition of routines, scheduler behavior, and engine-specific features into deterministic, repairable, or human-owned lanes.
• Snapshot and binlog/CDC catch-up evidence with retained GTID or file-position state, restart checkpoints, and reconciliation.
• Independent checks for character sets, collations, zero dates, temporal types, unsigned numerics, and JSON semantics.
• Signed certificates, frozen wave scope, authenticated approvals, and a verifiable consumer cutover or rollback.

Migration route

1. Accept metadata and dependency artifacts through assessment_start and assessment_record.
2. Register schema objects and consumers. Route routines, scheduler behavior, engine-specific features, cross-schema side effects, and transaction coupling to deterministic, repairable, or human-owned lanes.
3. Run a consistent snapshot and binlog/CDC or watermark catch-up. Retain GTID or file-position boundaries, restart checkpoints, deletes, lag, and reconciliation.
4. Validate character sets, collations, zero dates, temporal types, unsigned numerics, JSON, change ordering, business queries, and performance thresholds independently.
5. Mint certificates from admitted evidence; freeze and approve the consumer cutover; verify or roll back.
6. Modernize to Lakeflow Connect, Delta, Unity Catalog, Databricks SQL, and streaming change-data products in a separate release.

The pack is cataloged. Generate and check a live source-certification manifest before claiming assessable, executable, or certifiable support.

Complete developer command sequence

Generate this exact recipe from the installed CLI so the guide and executable surface stay in sync:

fa source recipe mysql
fa source recipe mysql --variant mysql --json > .airlift/mysql-recipe.json

The App is engagement-aware. MySQL and Aurora MySQL appears under Active sources only after the source estate is added to an active engagement. The menu is derived from governed engagement scope; installing Airlift does not expose unrelated source pages.

Every remote mutation below requires --host, --org, authenticated workspace identity, and a stable --idempotency-key. JSON request files contain identifiers, artifact references, and opaque credential references—never passwords, tokens, or connection strings. Run fa <resource> <operation> --help for the current schema and exit semantics.

0. Inspect the source contract

fa source inspect mysql --json > .airlift/mysql-profile.json
fa source plan mysql --variant mysql --json > .airlift/mysql-capability-plan.json

Expected artifacts:

• .airlift/mysql-profile.json
• .airlift/mysql-capability-plan.json

Open Engagements → active engagement in the App. This stage is visible at /engagements after replacing the placeholder ID with the governed engagement ID.

1. Create governed scope and connection references

fa engagement create --file engagement.json --idempotency-key migration-create-v1
fa estate register --file mysql-estate.json --idempotency-key mysql-estate-v1
fa connection register --file mysql-connection.json --idempotency-key mysql-connection-v1
fa engagement update --file mysql-scope.json --idempotency-key mysql-scope-v1
fa engagement preflight <engagement-id>

Expected artifacts:

• Governed engagement
• Source estate
• Opaque connection binding

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id> after replacing the placeholder ID with the governed engagement ID.

2. Assess and accept inventory

fa assessment start --file mysql-assessment-start.json --idempotency-key mysql-assessment-start-v1
fa assessment status <assessment-id> --json
fa assessment record --file mysql-assessment-record.json --idempotency-key mysql-assessment-record-v1
fa assessment accept --file mysql-assessment-accept.json --idempotency-key mysql-assessment-accept-v1
fa inventory list --estate-id <estate-id> --json

Expected artifacts:

• Assessment report reference
• Normalized inventory
• Dependency graph

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/sources/mysql after replacing the placeholder ID with the governed engagement ID.

3. Implement the admitted source adapter

No source-specific executable compiler exists in this release. Continue with assessment, governed work, and an admitted adapter; Airlift does not invent executable output.

Expected artifacts:

• Capability plan and adapter requirements only

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/artifacts after replacing the placeholder ID with the governed engagement ID.

This source is cataloged or assessable but has no source-specific executable compiler in the installed Airlift generation.

4. Convert, move, and remediate

fa plan generate --file mysql-migration-plan.json --idempotency-key mysql-plan-v1
fa conversion batch create --file mysql-batch.json --idempotency-key mysql-batch-v1
fa conversion batch start --file conversion-batch-start.json --idempotency-key conversion-start-v1
fa residue list --engagement-id <engagement-id>
fa transfer plan --file mysql-transfer.json --idempotency-key mysql-transfer-v1
fa transfer run <transfer-id> --idempotency-key transfer-run-v1
fa transfer reconcile <transfer-id> --idempotency-key transfer-reconcile-v1

Expected artifacts:

• Target artifacts
• Residue cases
• Transfer checkpoints
• Reconciliation evidence

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/runs after replacing the placeholder ID with the governed engagement ID.

5. Validate independently and inspect discrepancies

fa validation run --file mysql-validation.json --idempotency-key mysql-validation-v1
fa validation status <validation-execution-id> --json
fa discrepancy list --engagement-id <engagement-id>
fa artifact list --engagement-id <engagement-id>

Expected artifacts:

• Provider run references
• Readiness evidence
• Discrepancies

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/runs after replacing the placeholder ID with the governed engagement ID.

6. Certify, cut over, and export evidence

fa certificate list --object-id <object-id>
fa cutover status <wave-id> --json
fa evidence list --engagement-id <engagement-id>
fa evidence export --file mysql-evidence-export.json --idempotency-key mysql-evidence-export-v1

Expected artifacts:

• Migration certificates
• Cutover evidence
• Content-digested evidence export

Open Engagements → active engagement in the App. This stage is visible at /assurance after replacing the placeholder ID with the governed engagement ID.

Runway executes releases; Experiments owns validation verdicts; Airlift owns migration readiness and cutover policy.

What developers see in the App

The contextual source workspace shows the accepted estate and the factory stages for this engagement. Artifacts displays immutable references, content digests, media types, and provider lineage. Runs displays assessment, conversion, transfer, validation, and deployment executions without treating a provider's success as an Airlift verdict.

View full size

These are automated captures from public synthetic engagements. The source workspace is specific to MySQL and Aurora MySQL; no unrelated source is presented as its migration journey. For sources without an evidence-backed journey, the image demonstrates setup, navigation, and developer entry points only—not a live connection, converted output, or certified migration. No client data, credentials, workspace hostnames, or internal deployment identifiers are embedded in the images.