Turn migration findings into portable Databricks Apps and Lakebase releases with governed state, synthetic BDD, branch rehearsal, and evidence-qualified delivery.

Operational application modernization

A migration can expose a second opportunity: the source estate may contain operational workflows that should become a Databricks-native application. Examples include customer service, agent review, compliance cases, asset operations, and the migration workbench itself.

Airlift helps engineering teams define that application as an executable delivery contract instead of leaving it as a slide or backlog item. It answers:

which operational state belongs in Lakebase;
which governed lakehouse data must be served through Synced Tables;
which Databricks App resources must be bound at runtime;
which domain schemas, grants, fixtures, and user journeys are required;
which validation, preview, restore, deployment, and SLO evidence blocks promotion; and
which Fabric product owns each execution step.

Architecture

Unity Catalog governed data
  -> Synced Tables or admitted movement contract
  -> Lakebase serving tables

Databricks App
  -> valueFrom runtime bindings
  -> Lakebase transactional application state
  -> Platform governed actions
  -> Harness agents when the domain needs bounded automation

Experiments BDD/evaluations + Runway release + Radar observations
  -> foreign references and exact digests
  -> Airlift application-kit qualification

Lakebase is not used as a substitute for the lakehouse. Lakebase holds transactional application state and low-latency serving projections; Unity Catalog remains the governed source for analytical data, permissions, lineage, and data ownership.

End-to-end developer journey

1. Capture the application opportunity

fa application-kit init \
  --name "Risk review" \
  --module risk_compliance \
  --cloud aws \
  > application-kit.json

Edit logical bindings, Synced Table contracts, module artifact references, BDD feature references, and the Radar SLO profile. Keep credentials and physical workspace resource IDs in environment-owned Databricks App resources, never in the manifest.

2. Compile the family delivery contract

fa application-kit plan \
  --file application-kit.json \
  --json > application-plan.json

The plan expands module behavior into observable acceptance scenarios. A risk and compliance module requires case-state transitions, separation of duties, policy retrieval quality, and immutable decision evidence. Common scenarios cover authenticated and unauthorized users, tenant isolation, governed mutation denial, binding failure, data freshness/recovery, and branch preview/restore.

3. Build the application release

Implement the application vertical with Platform actions and Harness agents. Resolve all Databricks resources through App bindings. Generate or assemble the Declarative Automation Bundle as a Runway release input.

Use fr, not fa, for the release:

fr validate --dir generated
fr deploy --dir generated --environment preview

The preview environment uses an isolated Lakebase branch or an equivalently isolated state store. Run the restore rehearsal before promotion.

4. Execute behavior and quality evidence

Write synthetic BDD for every advertised workflow and negative authorization path. Execute it through Fabric Experiments against the same candidate digest:

fx apply experiments/
fx report <suite-id>

Agent modules also need versioned datasets, evaluators, budgets, tool-denial tests, and release thresholds. A passing agent answer cannot approve, waive, deploy, certify, or change application state outside Platform.

5. Qualify the joined evidence

fa application-kit qualify \
  --file application-plan.json \
  --evidence application-evidence.json \
  --level workspace_proven

The decision fails closed unless Runway and Experiments identify the same artifact digest. It also requires branch preview/restore evidence and a Radar observation when the kit has an SLO. Provider outages, cross-scope references, digest drift, and failed scenarios are blockers, not warnings.

6. Promote, operate, and measure separately

Runway promotes or rolls back the release. Radar owns operational health. Airlift may admit their references into a modernization item and measured-value report, but it does not duplicate their state.

Measure the application against a reviewed baseline: user handling time, queue time, error/rework rate, latency, cost, or another agreed outcome. Do not publish an acceleration percentage from a synthetic run or a single engagement.

Proof levels

Level	Required evidence
`contract_only`	valid manifest, deterministic plan, explicit owners
`hermetic_proven`	bundle validation, secret scan, binding evidence, synthetic fixtures, BDD contract
`workspace_proven`	same-digest Runway deployment, Experiments execution, branch restore, required Radar observation
`client_proven`	representative client data and accepted business journeys
`production_certified`	production rollout, rollback, SLO, security, and support evidence

Each level is a ceiling. It does not imply the next level.

Where to work in the App

Open Application kits to see available modules, registered immutable plans, the developer command flow, and the evidence join. Open Release qualification for the same-digest release boundary and Modernization studio to connect an accepted kit to a separate modernization release and measurable outcome.

See Databricks application-kit commands for the complete CLI contract.

Operational application modernization

On this page