<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Announcement | A Decision Framework for ETL Migration to Databricks in Announcements</title>
    <link>https://community.databricks.com/t5/announcements/announcement-a-decision-framework-for-etl-migration-to/m-p/162776#M914</link>
    <description>&lt;P&gt;&lt;SPAN&gt;Databricks has shared a practical framework for &lt;/SPAN&gt;&lt;STRONG&gt;ETL migration&lt;/STRONG&gt;&lt;SPAN&gt; that moves the conversation away from one-size-fits-all rewrites. The core idea is simple: most teams do not choose a single migration path, they use a mix of &lt;/SPAN&gt;&lt;STRONG&gt;Spark Declarative Pipelines&lt;/STRONG&gt;&lt;SPAN&gt;, &lt;/SPAN&gt;&lt;STRONG&gt;Lakehouse / Databricks SQL&lt;/STRONG&gt;&lt;SPAN&gt;, and &lt;/SPAN&gt;&lt;STRONG&gt;PySpark or Spark SQL notebooks&lt;/STRONG&gt;&lt;SPAN&gt; depending on the workload.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size="4"&gt;&lt;STRONG&gt;What’s new&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;
&lt;UL&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Three paths, not one&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks frames migration as a tool-selection problem, with Spark Declarative Pipelines suited to managed ETL and data quality, Databricks SQL well suited to SQL-heavy workloads, and PySpark or Spark SQL notebooks reserved for more complex engineering logic.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Phase the migration for outcomes&lt;/STRONG&gt;&lt;SPAN&gt;: Rather than a big-bang cutover, the recommended approach is to assess first, capture quick wins, modernize the pipelines worth redesigning, and then optimize once the legacy platform is being retired.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Use automation where it helps most&lt;/STRONG&gt;&lt;SPAN&gt;: Lakebridge is positioned as a migration accelerator for profiling, assessment, SQL and ETL conversion, validation, and reconciliation, so teams can spend more time on business validation and less on mechanical translation.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Start with low-risk, high-visibility wins&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks emphasizes using early migrations to build confidence, especially where simple SQL jobs or visible reporting flows can show value quickly.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;The end goal is simplification, not just conversion&lt;/STRONG&gt;&lt;SPAN&gt;: The post makes the case that successful migrations retire old schedulers, redundant validation layers, and fragmented tooling instead of recreating them on the new platform.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;&lt;SPAN&gt;Databricks also points to migrations like &lt;/SPAN&gt;&lt;STRONG&gt;Walgreens&lt;/STRONG&gt;&lt;SPAN&gt;, which moved off legacy Teradata, now processes about &lt;/SPAN&gt;&lt;STRONG&gt;40,000 data events per second&lt;/STRONG&gt;&lt;SPAN&gt;, and uses the lakehouse for near real-time supply chain and pharmacy workflows.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="p8i6j01 paragraph"&gt;&lt;A style="background-color: #ff3621; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; font-weight: bold; display: inline-block;" href="https://www.databricks.com/blog/decision-framework-etl-migration-databricks" target="_blank" rel="noopener"&gt; &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_right:"&gt;👉&lt;/span&gt; Read the full post here &lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Mon, 13 Jul 2026 09:47:48 GMT</pubDate>
    <dc:creator>Tushar_Parekar</dc:creator>
    <dc:date>2026-07-13T09:47:48Z</dc:date>
    <item>
      <title>Announcement | A Decision Framework for ETL Migration to Databricks</title>
      <link>https://community.databricks.com/t5/announcements/announcement-a-decision-framework-for-etl-migration-to/m-p/162776#M914</link>
      <description>&lt;P&gt;&lt;SPAN&gt;Databricks has shared a practical framework for &lt;/SPAN&gt;&lt;STRONG&gt;ETL migration&lt;/STRONG&gt;&lt;SPAN&gt; that moves the conversation away from one-size-fits-all rewrites. The core idea is simple: most teams do not choose a single migration path, they use a mix of &lt;/SPAN&gt;&lt;STRONG&gt;Spark Declarative Pipelines&lt;/STRONG&gt;&lt;SPAN&gt;, &lt;/SPAN&gt;&lt;STRONG&gt;Lakehouse / Databricks SQL&lt;/STRONG&gt;&lt;SPAN&gt;, and &lt;/SPAN&gt;&lt;STRONG&gt;PySpark or Spark SQL notebooks&lt;/STRONG&gt;&lt;SPAN&gt; depending on the workload.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size="4"&gt;&lt;STRONG&gt;What’s new&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;
&lt;UL&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Three paths, not one&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks frames migration as a tool-selection problem, with Spark Declarative Pipelines suited to managed ETL and data quality, Databricks SQL well suited to SQL-heavy workloads, and PySpark or Spark SQL notebooks reserved for more complex engineering logic.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Phase the migration for outcomes&lt;/STRONG&gt;&lt;SPAN&gt;: Rather than a big-bang cutover, the recommended approach is to assess first, capture quick wins, modernize the pipelines worth redesigning, and then optimize once the legacy platform is being retired.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Use automation where it helps most&lt;/STRONG&gt;&lt;SPAN&gt;: Lakebridge is positioned as a migration accelerator for profiling, assessment, SQL and ETL conversion, validation, and reconciliation, so teams can spend more time on business validation and less on mechanical translation.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Start with low-risk, high-visibility wins&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks emphasizes using early migrations to build confidence, especially where simple SQL jobs or visible reporting flows can show value quickly.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;The end goal is simplification, not just conversion&lt;/STRONG&gt;&lt;SPAN&gt;: The post makes the case that successful migrations retire old schedulers, redundant validation layers, and fragmented tooling instead of recreating them on the new platform.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;&lt;SPAN&gt;Databricks also points to migrations like &lt;/SPAN&gt;&lt;STRONG&gt;Walgreens&lt;/STRONG&gt;&lt;SPAN&gt;, which moved off legacy Teradata, now processes about &lt;/SPAN&gt;&lt;STRONG&gt;40,000 data events per second&lt;/STRONG&gt;&lt;SPAN&gt;, and uses the lakehouse for near real-time supply chain and pharmacy workflows.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="p8i6j01 paragraph"&gt;&lt;A style="background-color: #ff3621; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; font-weight: bold; display: inline-block;" href="https://www.databricks.com/blog/decision-framework-etl-migration-databricks" target="_blank" rel="noopener"&gt; &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_right:"&gt;👉&lt;/span&gt; Read the full post here &lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jul 2026 09:47:48 GMT</pubDate>
      <guid>https://community.databricks.com/t5/announcements/announcement-a-decision-framework-for-etl-migration-to/m-p/162776#M914</guid>
      <dc:creator>Tushar_Parekar</dc:creator>
      <dc:date>2026-07-13T09:47:48Z</dc:date>
    </item>
  </channel>
</rss>

