Data teams measure plenty of things, yet few measure how much of their own estate is still alive. Pipelines get built for a project, the project ends, and the tables keep refreshing for years because nobody dared switch them off. This checklist treats your existing DataOps estate as something to inspect before you add another source or another model. Work through it in order and keep a note of the evidence for each answer, because a claim of “it seems fine” is exactly what these checks exist to replace.<\/p>\n
The approach is analytical on purpose. For each item you gather a small piece of evidence, compare it with what you expected, and decide to keep, repair or retire. That three-way decision is the whole method.<\/p>\n
You cannot judge what you cannot list. Export every scheduled job, every orchestrated workflow and every table that receives writes. Then add the consumers: dashboards, notebooks, exports and downstream models. The list will usually reveal orphans on both sides, jobs that write data nobody reads and reports that read data nobody refreshes.<\/p>\n
One practical trick is to ask the people who read the dashboards, not only the people who build the pipelines. A short conversation with an analyst often uncovers the table everyone avoids because it was wrong once and never fixed. That folk knowledge is evidence too, and it points you at the assets with the weakest reputations.<\/p>\n
Validation suites decay too. A rule written for last year’s schema may pass trivially because the column it guards is now always populated by a default value. Check that each expectation can still fail. One way is to feed it a deliberately broken sample and confirm that it complains. If you use a library for declarative checks, the guide to writing data validation rules in practice<\/a> is a useful companion while you review which expectations still earn their place.<\/p>\n When you review a suite, sort it by age. The oldest expectations were written under assumptions that may no longer hold, and the newest were written in a hurry after an incident. Both groups deserve a second look, for opposite reasons.<\/p>\n Transformation code accumulates sediment. Models are copied, renamed and left behind, and lineage grows tangled. Review which transformations still feed something. A walkthrough of building reliable transformations with dbt<\/a> describes the structure you should be aiming for, and comparing your repository with that shape quickly shows where drift has set in.<\/p>\n Be wary of the temptation to rewrite everything at this stage. The audit is about knowing the state of things. Rewrites come after, and only for the assets that justify them. Small repairs, such as deleting a dead model or renaming a confusing one, deliver most of the value for a fraction of the effort.<\/p>\n Workflow engines are happy to run stale graphs forever. Open the scheduler and review each workflow for outdated dependencies, retired source systems and tasks that always succeed in zero seconds, which usually means they do nothing. Then list every secret the estate relies on: service accounts, tokens, warehouse roles and API keys. Note the expiry of each and who rotates it. For a broader view of coordinating tasks, the article on bringing order to scattered data workflows<\/a> offers a good vocabulary for the review.<\/p>\n Plan for the unglamorous cases as well. A retired source system may still be queried by a legacy report that someone checks once a quarter. A rotated credential may break a monthly export that nobody remembers. Searching your logs for rare access patterns, not only frequent ones, catches these stragglers before the owner finds them the hard way.<\/p>\n\n
Part three: inspect the transformation layer<\/h2>\n
\n
Part four: verify orchestration and credentials<\/h2>\n
\n
Part five: verify the references around the data<\/h2>\n