CLI · Migration

kiri migrate covers the path from a legacy warehouse to a contract-governed Databricks platform: analyse the source system, translate its logic, gate the target infrastructure, and reconcile the migrated data against the source.

kiri migrate analyze

Introspect the legacy source system and write sources/*.yml for everything it finds.

Usage: kiri migrate analyze [OPTIONS]

Flag	Description	Default
`--project`, `-p`	Project directory
`--source-target`	Named legacy-source target profile in `kiri.yml`
`--output`, `-o`	Where to write the generated sources YAML
`--owner`	Owner email for the generated source
`--domain`	Domain tag for the generated source	`migration`

kiri migrate sp

Classify and translate one legacy stored procedure into Spark SQL artefacts.

Usage: kiri migrate sp --procedure <schema.name> [OPTIONS]

Flag	Description
`--procedure`	Fully qualified procedure name, e.g. `dbo.usp_LoadShifts` (required)
`--source-target`	Named legacy-source target profile in `kiri.yml` (the source database)
`--output`, `-o`	Write the translated artefact to a file

Additional source-system-specific migration verbs (including the standalone deterministic SQL-dialect translators and legacy-metadata importers) are documented in the product repo.

kiri migrate lint-models

Apply the 5-layer medallion layer-policy lint to a migrated dbt model tree.

Usage: kiri migrate lint-models [--models <dir>]

Checks that each model sits in the right layer and only references layers it is allowed to — the guard-rail that keeps a lifted-and-shifted model tree from re-growing legacy spaghetti.

kiri migrate verify

Run Databricks pre-deploy infrastructure checks before the first apply.

Usage: kiri migrate verify [OPTIONS]

Flag	Description
`--target`, `-t`	Named profile from `kiri.yml`
`--catalog`	Override catalog (defaults to `profile.catalog`)
`--landing-url`	ADLS Gen2 landing URL to verify the external location for

kiri migrate verify-names

Verbatim name-preservation gate: asserts that migrated table and column names match the contract exactly.

Usage: kiri migrate verify-names --contract <yml> --schema <live-schema> [OPTIONS]

--catalog labels the live catalog (defaults to profile.catalog); the JSON report goes to --output or stdout. Run this per contract in CI during the migration window — silent renames are the classic parity killer.

kiri migrate emit-fk-ddl

Emit foreign-key constraint DDL for every declared FK in the project, so informational constraints survive the move to the target platform.

kiri migrate emit-fk-ddl --target prod -o fk_constraints.sql

kiri reconcile

Post-migration data validation: source vs target, table by table.

Usage: kiri reconcile [OPTIONS]

Flag	Description	Default
`--source-target`	Legacy-source profile in `kiri.yml`
`--target-target`	Databricks profile in `kiri.yml`	`databricks`
`--source-table` / `--target-table`	Fully-qualified tables to compare
`--primary-key`	Comma-separated PK column list
`--columns`	Columns for the null-rate check
`--date-columns`	DATE/TIMESTAMP columns for bounds checks
`--business-key`	SCD2 business-key columns
`--effective-from` / `--effective-to`	SCD2 effectivity columns
`--attribute-columns`	Full-row fingerprint columns (default: `--columns`)
`--source-snapshot-id`	Observed source frozen-batch snapshot id
`--report-mode`	`full` \| `locked` — LOCKED omits raw values from the report
`--pk-mode`	Override `reconcile.pk_check_mode`: `full` \| `sample` \| `spot`
`--sample-size`	Override `reconcile.pk_sample_size` (`0` = use config)	`0`
`--format`	`json` \| `markdown`	`json`
`--output`, `-o`	Overall report path; per-table reports land in `--reports-dir` (default `<project>/reconciliation`)
`--write-apply-log` / `--no-apply-log`	Write an `_kiri_apply_log` row via the target adapter (best-effort; never blocks the report)	on

The check families cover row counts, PK presence, null rates, date bounds, SCD2 effectivity, and full-row fingerprints. LOCKED reports are the artefact bound into cutover approvals: kiri approve consume-reconcile consumes a use-once approval token against a specific LOCKED reconcile report, optionally pinned to --environment and --snapshot-id (see the releases page).

A typical cutover sequence

kiri migrate analyze --source-target legacy          # inventory the source
kiri migrate verify --target prod                    # gate the Databricks side
kiri apply --target prod                             # build the new platform
kiri migrate verify-names --contract contracts/…     # names survived verbatim
kiri reconcile --source-table … --target-table … \
  --primary-key id --report-mode locked -o report.json
kiri approve consume-reconcile --token … --report report.json