Migrate SQL Server with Airlift

Airlift turns SQL Server assessment, conversion, transfer, validation, and cutover into one governed object ledger. Lakebridge supplies the profiler, Analyzer, Morpheus conversion, and Reconcile implementation; Airlift records which runs and evidence were accepted for each object.

What Airlift adds to a SQL Server migration

This keeps tables, procedures, SQL Agent or SSIS orchestration, SSRS reports, and application consumers in one dependency-aware plan even when each surface uses a different implementation path.

Choose the Databricks target

Use the standard migration pack when SQL Server analytical workloads are moving to the Databricks Lakehouse. Use the Lakebase target path when an operational application database needs PostgreSQL-compatible transactional serving on Databricks:

fa lakebase inspect --file sql-server-manifest.json
fa lakebase plan --file sql-server-manifest.json --json \
  > .airlift/sql-server-lakebase-plan.json
fa lakebase qualification-check \
  --file .airlift/sql-server-lakebase-qualification.json

The Lakebase plan maps schemas, tables, views, functions, roles, and grants while keeping SQL Agent, SSIS, SSRS, and other external workload redesign visible as residue. Runway owns target deployment. Airlift binds the accepted source scope, target artifact, dataset, and validation evidence to one plan digest. See the SQL Server to Lakebase CLI guide for the complete repeatable test.

For workspace proof, do not reuse the compatibility report. Supply a source_connectivity row from the connected SQL Server run and a target_connectivity row from managed Lakebase, both bound to the same build, plan, and dataset digests. Then admit the evaluated report with fa artifact register. The App shows it under Engagement → Artifacts. Registration alone leaves the fail-closed corroboration warning visible. An admitted validation provider must record a passing governed validation run whose subjectArtifactId names the registered certification row and whose artifactDigest equals that row's SHA-256 digest; only then does the App show Connected workspace evidence. Reusing another run's digest is not corroboration. Failed runs remain visible but never create that success label. Client and production boundaries remain unchanged.

After registration, read the same governed phase projection shown in the App:

fa engagement status <engagement-id>
fa engagement status <engagement-id> --json

Compile the executable migration pack

Create a versioned manifest containing SQL objects, SQL Agent jobs, SSIS packages, SSRS reports, linked-server references, cross-database dependencies, permissions, and consumers. Mark observed hard cases on the objects where they occur, then run:

fa migration-pack inspect --file sql-server-manifest.json
fa migration-pack plan --file sql-server-manifest.json --json > sql-server-plan.json

The compiler requires source IDs and complete dependencies, reports missing SQL Server hard-case coverage, and routes each object to deterministic conversion, bounded repair, or human remediation. It generates target mappings, the LSN/watermark transfer contract, SQL Server-specific Experiments suites, and a Runway deployment requirement. See migration-pack commands for registration and certification.

Inspect the developer plan

fa source inspect sql_server
fa source plan mssql
fa source plan mssql --json > .airlift/sql-server-plan.json

Aliases include mssql, sqlserver, azure_sql, and rds_sql_server.

Run assessment

Export DDL, procedures, functions, SQL Agent jobs, SSIS packages, SSRS definitions, linked-server dependencies, roles, and representative query history. Then run:

databricks labs lakebridge configure-database-profiler
databricks labs lakebridge execute-database-profiler \
  --source-tech mssql \
  --output-folder ./artifacts/profile

databricks labs lakebridge analyze \
  --source-directory ./source-export \
  --source-tech "MS SQL Server" \
  --report-file ./artifacts/analysis.xlsx \
  --generate-json true

Use additional Analyzer runs with SSIS and SSRS when those exports are in scope. Record the accepted report and digests through assessmentStart, assessmentRecord, and objectRegister actions.

Convert code

databricks labs lakebridge transpile \
  --source-dialect mssql \
  --input-source ./source-export/sql \
  --output-folder ./artifacts/converted

Morpheus is the preferred deterministic path. Route CLR objects, linked-server calls, cross-database transactions, SQL Agent side effects, and unresolved dynamic SQL into rework. Airlift may record one bounded repair candidate, but independent validation is still required.

Move data

Choose change tracking, SQL Server CDC, or an application watermark per table class. Implement the Airlift transfer contract as snapshot, incremental catch-up, restart, and reconcile steps. Preserve source LSN or watermark and target snapshot identities in the returned evidence.

Validate

databricks labs lakebridge configure-reconcile
databricks labs lakebridge auto-configure-recon-tables
databricks labs lakebridge reconcile

Review generated table pairs before execution. Add scenarios for collation and case, datetime and decimal behavior, identity/sequence semantics, temporary tables, dynamic SQL, SSIS control flow, and SSRS result sets. Record admitted runs with validationRunRecord and readinessRecord; do not treat transpiler success as parity.

Certify and cut over

Assign profiles that match the object class, admit the required validation runs, and let Airlift mint the certificate from current evidence. For cutover, implement project effectors for connection strings, SQL Agent or SSIS schedules, report data sources, and application endpoints. Rehearse checkpoint, apply-once, verification, and rollback for each wave; a successful table comparison cannot authorize an untested consumer switch.

Databricks modernization backlog

After baseline certification, disposition SQL Agent and SSIS into Lakeflow Jobs or Declarative Pipelines, map database roles into Unity Catalog, move serving workloads to Databricks SQL, and evaluate liquid clustering. Keep these changes in a release separate from the parity-preserving migration.

Complete developer command sequence

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

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

The App is engagement-aware. SQL Server 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 sql_server --json > .airlift/sql_server-profile.json
fa source plan sql_server --variant sql_server --json > .airlift/sql_server-capability-plan.json

Expected artifacts:

• .airlift/sql_server-profile.json
• .airlift/sql_server-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 sql_server-estate.json --idempotency-key sql_server-estate-v1
fa connection register --file sql_server-connection.json --idempotency-key sql_server-connection-v1
fa engagement update --file sql_server-scope.json --idempotency-key sql_server-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 sql_server-assessment-start.json --idempotency-key sql_server-assessment-start-v1
fa assessment status <assessment-id> --json
fa assessment record --file sql_server-assessment-record.json --idempotency-key sql_server-assessment-record-v1
fa assessment accept --file sql_server-assessment-accept.json --idempotency-key sql_server-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/sql_server after replacing the placeholder ID with the governed engagement ID.

3. Compile the sql_server migration pack

fa migration-pack inspect --file sql_server-manifest.json
fa migration-pack plan --file sql_server-manifest.json --json > generated/sql_server-plan.json

Expected artifacts:

• Dependency-aware migration pack
• Transfer requirements
• Validation requirements
• Residue lanes

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.

4. Convert, move, and remediate

fa plan generate --file sql_server-migration-plan.json --idempotency-key sql_server-plan-v1
fa conversion batch create --file sql_server-batch.json --idempotency-key sql_server-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 sql_server-transfer.json --idempotency-key sql_server-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 sql_server-validation.json --idempotency-key sql_server-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 sql_server-evidence-export.json --idempotency-key sql_server-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.

Authenticated hermetic run ledger

In the isolated sandbox, open Engagements → engagement → Run ledger. Airlift renders Start SQL Server journey only from the engagement's canonical SQL Server estate; the browser submits organization and engagement identifiers, never provider identity, workflow generation, or candidate lineage. The server resolves one exact verified SQL Server source binding, planned transfer, requested deployment, and assigned validation scope before it starts or attaches to the deterministic Temporal workflow.

Worker activities select the SQL Server hermetic provider from that server-resolved source, record its exact provider generation and private content-digested diagnostic references, and project lifecycle stages into shared PostgreSQL. Missing, duplicate, mixed-source, or unsupported provider composition fails closed. Existing Synapse workflow identities remain replay-compatible; SQL Server receives a distinct source-bound identity.

This lane proves authenticated orchestration, provider isolation, durable lifecycle, exact validation continuation, cancellation cleanup, and source-bound idempotency only. It does not connect to live SQL Server, provision or inspect managed Lakebase, establish workspace/client proof, certify production readiness, or bypass the owner-bound workspace certification recipe below.

View full size

View full size

View full size

View full size

These are automated captures from public synthetic engagements. The source workspace and run-ledger control are specific to SQL Server; 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.