Migration accelerator
Migrate the estate, and be able to prove it
A governed migration factory for moving warehouse and ETL estates to Databricks.
- Role in the family
- Migration accelerator
- Databricks surfaces
- LakebridgeUnity CatalogDatabricks Asset BundlesDatabricks AppsTemporal
- Status
- Console, worker, CLI, and declarative Databricks Asset Bundle deployment are implemented. Twenty-seven source platforms have executable playbooks, including Snowflake, Azure Synapse, Amazon Redshift, Oracle, Teradata, SQL Server, BigQuery, Netezza and SAP. The first two weeks of an Airlift engagement are sold on their own as the Migration Readiness Sprint.
- Documentation
- airlift.techfabric.com
The problem
Conversion is the easy part of a migration. The hard part is proving what was in scope, which tool version produced which artifact, what evidence says it is correct, and how to reverse a cutover at two in the morning when it is not.
How it works
Airlift composes Databricks Lakebridge for profiling, analysis, SQL conversion, and reconciliation, then wraps it in a policy-enforced lifecycle: discovery and scope acceptance, independent validation, signed migration certificates, approved waves, and reversible cutover. Every artifact carries the tool version that produced it and the evidence that cleared it.
What it does
Evidence, not assertions
Each converted artifact is bound to immutable evidence proving it is ready to promote.
Signed migration certificates
A wave cuts over only when its certificate is issued. The certificate is the gate, not a status field.
Reversible cutover
Checkpoint, apply, verify, with a defined path back out of an external change.
Wave planning
Scope is accepted explicitly and cut over in approved waves.
A warehouse migration your risk function will actually sign off. Scope, evidence, certificates, and a reversible cutover are part of the process, so the migration stops being a long weekend with a rollback plan nobody has tested.
The conversion works. The evidence does not exist.
Converting SQL is the part everybody plans for. What sinks a migration is the six months afterwards, when somebody asks a question the project cannot answer.
Nobody can say what was in scope
The inventory was a spreadsheet, taken in March, by somebody who has left. Three objects nobody counted are still running on the old platform and something depends on them.
The cutover has no way back
Which is why it happens on a Friday night. A plan with no reverse is a plan that can only be run when being wrong is survivable, and that window is always a weekend.
The old platform never gets turned off
Nobody is funded for decommissioning, so the bill runs in parallel for a year and the migration that was supposed to save money has not yet.
None of that is a conversion problem. It is a record-keeping problem, and a migration that keeps its own records answers all three without anybody being asked to remember.
The shift
Three ways to move a warehouse. Two of them lose the receipts.
Every migration picks one of these, and the choice is usually made by whoever is available.
Hand conversion
Accurate, and it does not finish
A conversion tool and a spreadsheet
Fast, and unprovable
A governed migration factory
Provable, and reversible
What runs the migration
Six parts, and the reason it is a factory rather than a project is that each one produces a record.
Twenty-seven source platforms
Snowflake, Synapse, Teradata, SQL Server, Oracle, Hadoop, Redshift and twenty more, each with an executable playbook rather than a methodology slide.
Inventory as data
Object counts, dependencies and the pieces nobody has run in two years, held as a queryable record rather than as a spreadsheet somebody owns.
Signed migration certificates
Per object, recording what was converted, by which tool version, and what the validation said. An auditor reads them instead of asking you to remember.
Validation before the switch
Row counts, checksums and business-rule reconciliation between the old estate and the new one, signed off before any traffic moves.
A reversible cutover
The switch has a tested way back. That is what turns a migration weekend into a migration morning.
Decommissioning in the plan
Turning the old platform off is where migrations quietly fail, because nobody is funded for it. It is a phase here rather than an afterthought.
27
Source platforms with executable playbooks
Built because we were doing it by hand
Airlift exists because we ran these migrations before we automated them, and the parts that hurt are the parts it now handles. It is free and open source under Apache-2.0 and it runs in your own workspace.
FAQ
TechFabric Airlift, answered
Which source warehouses can Airlift migrate?
Twenty-seven, each with an executable playbook. Snowflake, Azure Synapse and Teradata have their own pages at /databricks/from-snowflake, /databricks/from-synapse and /databricks/from-teradata. Redshift, Oracle, SQL Server, BigQuery, Netezza and SAP are covered too. Tell us your source and we will confirm what the playbook does today.
What makes a migration reversible?
Cutover runs as checkpoint, apply, verify, with a defined path back out of an external change. A wave only cuts over once its certificate is issued, so the gate is the evidence itself.
Can our risk function audit the migration?
That is the design goal. Every converted artifact is bound to immutable evidence and carries the tool version that produced it, so what was in scope, what proved it correct and who approved the wave are all answerable after the fact.