https://community.databricks.com/t5/data-governance/changing-root-metastore-location/m-p/168405#M2984 <P><a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/232293">@yawningbrain</a>&nbsp;this is a great topic. The <A href="https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/manage-metastore#remove-metastore-level-storage" target="_blank" rel="noopener">Azure Databricks documentation⁠</A> supports removing the existing metastore root and adding a new path. You cannot edit the existing path in place. <STRONG>This does not migrate existing data. </STRONG></P><P>When you remove the root, catalogs without their own storage location inherit the old path as their catalog-level storage. That preserves access, but means replacing the metastore root does not necessarily remove dependencies on the legacy account.</P><P>The two catalogs you mentioned need separate consideration:</P><UL><LI><EM>system</EM>: Operational system-table data is stored in a Databricks-hosted storage account, according to the <A href="https://learn.microsoft.com/en-us/azure/databricks/admin/system-tables/#where-is-system-table-data-stored" target="_blank" rel="noopener">system tables reference</A>⁠. A legacy path displayed in catalog properties would not, by itself, establish that those tables are physically stored there.</LI><LI><EM>__databricks_internal</EM>: Databricks identifies this as an internal catalog used for pipeline materializations and advises <STRONG>against</STRONG> accessing its tables directly. And I never tried to. For that dependency, I would get Databricks Support to confirm the migration or cleanup procedure before changing internal paths or retiring the storage account.</LI></UL><P>That said, keep the old account and its access permissions intact until those dependencies are resolved - the documented root-removal behavior is <STRONG>not a guarantee of zero impact</STRONG> when the underlying storage is deleted.</P><P>Are you seeing actual objects stored in the legacy account, or only the old path in these catalogs' properties?</P> Sat, 12 Sep 2026 01:45:09 GMT ivanvyd 2026-09-12T01:45:09Z https://community.databricks.com/t5/data-governance/changing-root-metastore-location/m-p/168376#M2983 <P>We currently have a default root metastore location l<FONT face="arial,helvetica,sans-serif">inked</FONT> to an ADLS container.<BR />At the same time we are working on a ADLS migration project.<BR />All of the tables and files (everything we use for day to day business related) have moved to the new ADLS so there are no dependencies on the legacy ADLS - except for the <FONT face="courier new,courier">system</FONT> and <FONT face="courier new,courier"><SPAN>__databricks_internal <FONT face="arial,helvetica,sans-serif">catalogs</FONT></SPAN></FONT>.<BR /><BR />How can we safely change the root metastore location without breaking our environment - ideally with minimal to 0 impact on our pipelines and system metadata.</P> Fri, 11 Sep 2026 14:49:17 GMT https://community.databricks.com/t5/data-governance/changing-root-metastore-location/m-p/168376#M2983 yawningbrain 2026-09-11T14:49:17Z https://community.databricks.com/t5/data-governance/changing-root-metastore-location/m-p/168405#M2984 <P><a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/232293">@yawningbrain</a>&nbsp;this is a great topic. The <A href="https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/manage-metastore#remove-metastore-level-storage" target="_blank" rel="noopener">Azure Databricks documentation⁠</A> supports removing the existing metastore root and adding a new path. You cannot edit the existing path in place. <STRONG>This does not migrate existing data. </STRONG></P><P>When you remove the root, catalogs without their own storage location inherit the old path as their catalog-level storage. That preserves access, but means replacing the metastore root does not necessarily remove dependencies on the legacy account.</P><P>The two catalogs you mentioned need separate consideration:</P><UL><LI><EM>system</EM>: Operational system-table data is stored in a Databricks-hosted storage account, according to the <A href="https://learn.microsoft.com/en-us/azure/databricks/admin/system-tables/#where-is-system-table-data-stored" target="_blank" rel="noopener">system tables reference</A>⁠. A legacy path displayed in catalog properties would not, by itself, establish that those tables are physically stored there.</LI><LI><EM>__databricks_internal</EM>: Databricks identifies this as an internal catalog used for pipeline materializations and advises <STRONG>against</STRONG> accessing its tables directly. And I never tried to. For that dependency, I would get Databricks Support to confirm the migration or cleanup procedure before changing internal paths or retiring the storage account.</LI></UL><P>That said, keep the old account and its access permissions intact until those dependencies are resolved - the documented root-removal behavior is <STRONG>not a guarantee of zero impact</STRONG> when the underlying storage is deleted.</P><P>Are you seeing actual objects stored in the legacy account, or only the old path in these catalogs' properties?</P> Sat, 12 Sep 2026 01:45:09 GMT https://community.databricks.com/t5/data-governance/changing-root-metastore-location/m-p/168405#M2984 ivanvyd 2026-09-12T01:45:09Z