Convert an ADF mapping data flow into dlt and dbt and prove parity
Order or customer reporting still comes from an Azure Data Factory mapping data flow whose logic lives only on the ADF canvas, with no tests or review.
- Transformation
Larger outcome
9 RecipesRecipes for moving existing SQL, notebooks, connectors and estates onto dbt, dlt and Fabric, from assessing what a move would take to converting each piece.
Order or customer reporting still comes from an Azure Data Factory mapping data flow whose logic lives only on the ADF canvas, with no tests or review.
A Synapse dedicated SQL pool or a set of SSIS packages is due to move to Fabric, and nobody can say what is in it, what each piece would take or what stops it.
A report or table is still produced by a hand-run SQL script or a database view outside dbt, with no tests, lineage or review.
A managed connector's bill changed shape, or it broke and the vendor fix has been pending for weeks, and the team wants the load in code it owns.
Warehouse logic lives in a materialized view that nobody can test, review or trace, and the team wants it in the dbt project.
A table or report is still produced by running a notebook by hand, pulling warehouse data into dataframes, with no tests, lineage or review.
Models or views call a scalar function created directly in the warehouse, so dbt cannot see the dependency and changes to it are not reviewed or tested.
A Spark notebook lands raw files into bronze, and the team wants that load as tested pipeline code without keeping a cluster for it.
A nightly load is a stored procedure nobody fully understands, and it inserts, updates, deletes or merges rows in a table people depend on.