SAP to Databricks

Airlift treats SAP as an ERP migration, not a collection of anonymous tables. The source pack keeps business objects, CDS views and extractors, BW objects, process chains, authorizations, currencies, units, hierarchies, and downstream analytics in one governed scope.

Generate the route

fa source inspect sap
fa source plan sap --variant sap_s4hana
fa source plan sap --variant sap_bdc --json > .airlift/sap-bdc-plan.json
fa application-pack plan --file sap-bdc-manifest.json --json > sap-bdc-plan.json

Supported variants are sap_bdc, sap_s4hana, sap_ecc, sap_bw4hana, sap_hana, and sap_datasphere. Select the deployed system rather than using a generic label; the variant is stored with the governed estate.

What Airlift adds

Custom ABAP extractors, BW process-chain logic, authorization-dependent semantics, and variant-specific extensions stay visible as residue. Ingestion success is not treated as business-semantic proof.

Register the estate

await runtime.invokeAction(AIRLIFT_ACTION_IDS.estateRegister, {
  ...authenticatedContext,
  idempotencyKey: 'sap-finance-estate-v1',
  params: {
    name: 'SAP finance',
    sourceSystem: 'sap',
    sourceVariant: 'sap_s4hana',
    environment: 'prod',
    owner: 'finance-data',
    connectionRef: 'uc-connection://sap-finance',
  },
});

The SAP BDC business-semantic compiler is executable. The S/4HANA, ECC, BW/4HANA, HANA, and Datasphere profiles remain cataloged until their source-specific compiler and recurring evidence ship. An executable compiler is not live client proof; promote a capability claim only after its inventory, movement, validation, scale, and—when requested—cutover evidence passes the source-pack contract.

See enterprise application-pack commands for the SAP BDC manifest and governed registration flow.

Complete developer command sequence

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

fa source recipe sap
fa source recipe sap --variant sap_bdc --json > .airlift/sap-recipe.json

The App is engagement-aware. SAP 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 sap --json > .airlift/sap-profile.json
fa source plan sap --variant sap_bdc --json > .airlift/sap-capability-plan.json

Expected artifacts:

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

3. Compile the enterprise application pack

fa application-pack inspect --file sap-manifest.json
fa application-pack plan --file sap-manifest.json --json > generated/sap-plan.json

Expected artifacts:

• Business-semantic target plan
• Control totals
• Security mappings
• Consumer transitions

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