What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
You do not have to migrate an existing Delta Live Tables (DLT) pipeline just because Databricks renamed the product to Lakeflow pipelines: Databricks says existing DLT code will continue to work. For a code modernization, replace import dlt with from pyspark import pipelines as dp, then update DLT decorators and references to the corresponding dp names. Test table types, refresh behavior, and operational controls before deploying those changes.
Do you need to migrate Delta Live Tables to Lakeflow?
No forced migration is required to keep an existing DLT pipeline running. Databricks says, “If you have previously used DLT, there is no migration required to use Lakeflow pipelines: your code will still work.” The rename does not, by itself, require an immediate code change.
Databricks recommends modernizing the API names to align with Apache Spark Declarative Pipelines (SDP) and future compatibility. The choice is therefore between leaving working legacy names in place for now and planning a deliberate code update—not between migrating immediately and having a pipeline stop working.
| Choice | Code change | Compatibility and operational considerations |
|---|---|---|
| Keep existing DLT names | No rename is required for existing code to continue working, according to Databricks. | Preserves the current code surface; it does not align the code with the newer SDP API names. |
Modernize to dp |
Update the import and DLT references to the documented pyspark.pipelines names. |
Aligns code with Spark Declarative Pipelines. Validate table and view semantics, refresh behavior, and operational controls as part of rollout. |
What replaces import dlt and @dlt?
Use the pyspark.pipelines module with the alias dp. Update decorators according to the object being defined; do not mechanically replace every decorator with @dp.table.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
| Legacy DLT form | Modernized form | Use |
|---|---|---|
import dlt |
from pyspark import pipelines as dp |
Imports the pipelines API under the dp alias. |
@dlt.table |
@dp.table |
Defines a streaming table. |
| DLT materialized-view decorator/reference | @dp.materialized_view |
Defines a materialized view. |
| DLT temporary-view decorator/reference | @dp.temporary_view |
Defines a temporary view. |
For example, a streaming-table definition that begins with @dlt.table should use @dp.table after the import is changed. For a materialized view or temporary view, use its own decorator rather than assuming the streaming-table decorator is interchangeable.
How to plan a safe code modernization
Treat the API rename as a controlled code change. The sequence below is an implementation approach; it is not a Databricks-mandated migration procedure.
- Inventory the pipeline. Record its notebooks and files, tables and views, expectations, checkpoints, schedules, downstream consumers, and Unity Catalog permissions.
- Change the API names. Replace
import dltwithfrom pyspark import pipelines as dp, then update DLT decorators and references to the appropriatedpnames. - Check object types and refresh semantics. Confirm whether each output should be a streaming table, materialized view, or temporary view. Review whether each flow incrementally processes new records or performs a full refresh, based on source state and flow type.
- Run representative updates in staging. Compare row counts, schemas, expectation results, lineage, and downstream outputs with the existing pipeline.
- Verify operations and governance. Check monitoring, failure recovery, checkpoint continuity, Unity Catalog permissions, and cost before production cutover.
- Prepare the cutover and rollback. Document rollback steps and use a production change window in which the team can monitor the update and respond to failures.
What changes in the pipeline architecture and refresh behavior?
Lakeflow pipelines run on Databricks Runtime and are built on Apache Spark Declarative Pipelines, a declarative SQL and Python framework for organizing dependencies across batch and streaming workloads. Databricks describes SDP as interoperable with other SDP runtimes; that does not, on its own, establish that every Databricks-specific feature or configuration behaves identically on another runtime.
Flows live inside pipelines and execute during pipeline updates. Depending on the source state and flow type, an update can process only new records through incremental refresh or reprocess the source through a full refresh. The decorator rename alone does not determine which refresh occurs, so verify the expected behavior for the affected flow before cutover.
Quick Recap
What should you validate before production?
- Definitions: each output uses the intended streaming-table, materialized-view, or temporary-view API.
- Data behavior: representative updates produce expected schemas, row counts, expectation outcomes, lineage, and downstream results.
- Refresh behavior: incremental and full-refresh cases are understood for the pipeline’s sources and flows.
- Continuity: checkpoints, monitoring, and failure recovery work as expected after the code change.
- Access: Unity Catalog permissions and downstream consumer access remain correct.
- Release readiness: cost has been reviewed, and rollback steps and a production change window are in place.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
