When you need to know what a schema change will break
The question is always the same and is almost never answerable: if I change this column, what breaks? Most organisations answer it by asking around, which finds the dependencies people remember.
The situation
A change is planned — a column type widens, a table splits, a service moves. The change itself is an hour of work. Establishing that it is safe is three weeks, and it is done by messaging teams and waiting for replies.
That method finds the dependencies people happen to know about. It reliably misses the report someone built two years ago, the integration owned by a team that has been reorganised, and the job that runs monthly.
Impact analysis over a model answers from recorded relationships instead. It is only as good as the model — which is the honest limitation, and also the reason to import rather than draw.
You are here if
- The last change of this kind broke something nobody predicted.
- Sign-off depends on a person rather than an artefact.
- You have been asked for a blast radius and can only give an anecdote.
- Nobody can produce a list of consumers for a given table.
How the work gets done
Make sure the model reflects reality first
Impact analysis reads the relationships recorded in the model. If the model was drawn by hand from memory, the answer inherits every gap in that memory — so import the schema from the database or the DDL rather than trusting a picture.
This is the step that decides whether the output is evidence or decoration.
Data ▸ Live DB ImportData ▸ Import DDL / Mermaid ER
Ask the dependency question directly
Run impact analysis from the object you intend to change. What comes back is what the model knows depends on it, following the recorded relationships rather than a text search for the table name.
Read the result as a floor, not a ceiling: it tells you what definitely depends on this, and it cannot tell you about a dependency nobody ever recorded.
Data ▸ Impact Analysis
Follow the data as well as the structure
Structural dependency and data flow are different questions. Lineage answers the second one — where the values in this column end up — which is what matters when the change is semantic rather than structural.
Data ▸ Lineage
Produce the migration and confirm the result
Generate the delta as a migration script from the model, so the change that ships is the change that was analysed rather than a hand-written approximation of it.
Afterwards, compare environments to confirm the target actually matches what was intended. A migration that ran without error is not the same as a migration that did what you meant.
Data ▸ Delta DDL / MigrationData ▸ Env Compare
What you end up holding
- A dependency list per object, derived from recorded relationships rather than recollection.
- A lineage trace for the values, separate from the structural dependencies.
- A migration script generated from the analysed model, and an environment comparison confirming the outcome.
Not this, if
- The model does not exist yet. Build it first — impact analysis over a model that is missing half the estate produces confident, wrong answers, which is worse than no answer.
- The dependencies you care about are in application code that is not modelled. Some can be found by tracing a diagram to source; some cannot, and pretending otherwise is how the two-in-the-morning discovery happens.
- You want runtime dependency discovery from live traffic. Nothing here observes a running system.