SQL Server to Lakebase with fa

The current release candidate admits the repeatable hermetic contract only. Historical raw workspace reports were withdrawn from the candidate; rerun the sanitized producer and admit its same-digest output before requesting workspace_proven.

The fa lakebase command group turns an accepted SQL Server inventory into a Lakebase-specific migration plan and evaluates digest-bound execution evidence. It does not translate T-SQL, deploy a database, or mark a migration complete by itself.

Use an admitted converter or human-reviewed SQL artifact for target DDL. Fabric Runway owns deployment. Airlift records the source scope, target intent, artifact digests, human work, validation requirements, and the proof boundary.

1. Compile the target plan

Start with the same SQL Server manifest accepted by the migration-pack compiler:

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

The plan contains:

• source inventory and dependency digests;
• a route for every SQL Server object;
• PostgreSQL-compatible Lakebase target kinds;
• deterministic, agent-repairable, and human-only dispositions;
• explicit human redesign for SQL Agent, SSIS, SSRS, and other external workloads;
• the validation stages required before stronger proof can be claimed;
• a content-derived planDigest.

The plan deliberately keeps operational database objects separate from orchestration. A SQL Agent job does not silently become a stored procedure in Lakebase; it remains a visible redesign item for Lakeflow Jobs or another approved runtime.

2. Register the immutable plan

Upload the plan to your approved artifact store, then register its reference:

fa lakebase register \
  --file .airlift/sql-server-lakebase-plan.json \
  --engagement-id <engagement-id> \
  --estate-id <estate-id> \
  --artifact-id volumes/migrations/sql-server/lakebase-plan.json \
  --idempotency-key lakebase-plan-v1

register invokes the governed artifact action. It records a reference and matching digest; it does not upload or deploy the file.

3. Run the repeatable compatibility demo

From an Airlift source distribution, run:

pnpm demo:sql-server-lakebase

The test creates an explicitly named ephemeral PostgreSQL 18 container, applies the target schema, loads representative rows, executes validation, writes the reports, and removes the container. It verifies:

1. plan compilation;
2. schema application;
3. data loading;
4. row counts;
5. aggregate parity;
6. decimal, timestamp, and null semantics;
7. identity/sequence behavior;
8. idempotent restart/replay;
9. a negative schema-isolation assertion.

The output is compatibility proof. It is not managed Lakebase proof and it is not proof of a client SQL Server estate.

4. Evaluate qualification evidence

fa lakebase qualification-check \
  --file .airlift/sql-server-lakebase-qualification.json

Use requestedProofLevel: hermetic_proven for the repeatable PostgreSQL-compatible test. workspace_proven additionally requires both sides of the migration:

• source_connectivity from a connected SQL Server engine; and
• target_connectivity from an actual managed Databricks Lakebase workspace run.

Every evidence row must carry the same build, plan, and dataset digests, including both connectivity rows and every compatibility stage. A target-only run, a PostgreSQL container standing in for SQL Server, a mismatched digest, or a missing stage blocks promotion.

The workspace runner or your delivery automation writes one qualification request. Run the same public evaluator before admitting it:

fa lakebase qualification-check \
  --file .airlift/sql-server-lakebase-workspace-qualification.json \
  --json > .airlift/sql-server-lakebase-workspace-report.json

The report's boundaries.sourceConnected must be true, eligible must be true, and maximumProofLevel must be workspace_proven. Those fields prove the engineering fixture only; they do not convert the run into client or production evidence.

5. Admit the connected workspace report

Store the report bytes in an approved Unity Catalog Volume or another immutable artifact store. Then register only its reference and SHA-256 digest with the engagement:

fa artifact register \
  --file sql-server-workspace-artifact.json \
  --idempotency-key sql-server-workspace-evidence-v1

sql-server-workspace-artifact.json identifies the engagement and estate, uses kind: "evidence", points artifactRef at the provider-owned report, repeats the exact digest in both digest fields, and records the producer generation. It never contains a database password, OAuth token, or connection string.

In the App, open Engagement → Artifacts. Registration first shows Workspace evidence not corroborated. An admitted provider must record a passing governed validation run whose subjectArtifactId names this platform-minted artifact row and whose artifactDigest matches its SHA-256 digest. Only then is the row labeled Connected workspace evidence; reusing the digest of another passing run does not qualify. Open the row to copy the digest and provider reference, inspect whether independent validation and a Runway requirement are bound, and read the proof boundary. Airlift still will not infer client approval or production cutover authority from its file name.

6. Read the status in automation and the App

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

Open the engagement in the Airlift App and select Migration status. The route reads SQL Server → Databricks Lakebase when the engagement contains the governed target reference databricks:migration_target:lakebase. The page displays all eight migration phases, active blockers, human residue, evidence counts, certificates, and the exact next action.

View full size

Proof labels

None of these labels means client-proven or production-certified. Client evidence must come from the accepted client scope, and production cutover still requires the normal certificate and cutover gates.