Decommissioning a table sounds like a five-minute job — drop it, done. In a real enterprise environment, it almost never is. Somewhere downstream, someone built a report, a job, or a linked server query that still points at the "dead" table, and you won't find out until it breaks in production.
This is a walkthrough of how I approach decommissioning a table in Databricks/Delta Lake when there's a hybrid environment involved — specifically when SQL Server (accessed via SSMS) still has visibility into or dependencies on that data, which is common in enterprises mid-migration to Azure.
## The problem
A table gets marked for removal — maybe it's a legacy staging table, a duplicate created during a migration, or a dataset that's been replaced by a new Delta table. The instinct is to just drop it. But in most enterprise setups, tables don't exist in isolation:
Linked servers or external tables in SQL Server may reference the same underlying data
