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
- Any domain
Rebuild something already in production and prove the new form behaves like the old one.
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 business rule in an incremental model was corrected, and only a known date range of published history should be restated.
A dbt model is correct but a full refresh is too slow or too expensive to run routinely, and gets slower as history grows.
A model has grown into one long query with logic packed inline, and nobody dares change it because dashboards and reports depend on its output.
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 Type 2 dimension is kept by a hand-written MERGE procedure or trigger that nobody wants to maintain.
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.
A required change to a published relation's grain, column meaning or shape cannot keep the old interface.
A load into a fact or reporting table still runs from a mapping built in a visual ETL tool, and its lookups, filters, routing and insert-update-delete rules are visible only on the tool's canvas.