Mature warehouses often accumulate a measure that everyone reports, nobody questions, and nobody currently responsible for it can fully explain.
In a transformation I led, we found one early. It sat inside the SSAS tabular model we are retiring: a DAX measure that fed an executive report for years. Its name suggested something simple. Its definition contained three nested conditions, a reference to a column that no longer existed in its original source, and the only comment in the model: “don’t touch, breaks Q close.”
Nobody still at the organization had written it. Team turnover had taken the reasoning with it. What remained was the output: a number people trusted because it had always been there, not because anyone could trace how it was produced.
The responsible-looking instinct to avoid
The easy path in a migration is to port the calculation forward as-is. Preserve the output, meet the deadline, and let the mystery travel into the new environment. That path feels responsible because the number has not changed.
But moving an unexplained calculation into a governed, version-controlled model does not resolve the risk. It certifies it. A passing dbt test and a polished semantic definition would give the organization more reason to trust a number we still could not defend.
A four-part recovery process
We treated the measure as a discovery problem rather than an engineering translation.
- Ask the people using the number. Finance maintained a local spreadsheet that adjusted the result during quarter close. The people maintaining it knew more about the intended behavior than the DAX could reveal.
- Trace the calculation’s history. We used AI to read old DAX, T-SQL, and commit history—not to decide the answer. An agent surfaced an earlier version from before the exception was added, narrowing the question from “What does this do?” to “Why was this exception introduced?”
- Turn the hidden exception back into a business decision. The nested conditions encoded a policy for handling one acquired location during its first two reporting periods. A business owner confirmed that the policy still applied.
- Validate the reauthorized rule. We documented it as a named, tested business rule and are running the new definition alongside the legacy report through another close cycle.
Where it stands
As of this writing, the migration work around this measure is not finished, and I would rather say that plainly than present an unfinished transformation as a resolved case study. A documented test now asserts that both definitions agree within the acquired-location exception window. If they diverge, we will know immediately, and we will know why.
The lesson has less to do with Snowflake, dbt, or AI than with what a warehouse preserves over time. Systems keep numbers indefinitely. They are much worse at keeping the reasoning behind them.
A migration is one of the few moments when someone asks a calculation to justify itself again. That discomfort is often more valuable than the dashboard refresh that prompted the migration.