What Governance Actually Means After a Teradata Migration

A migration can hit every technical milestone — schemas converted, row counts matched, dashboards repointed — and still leave a business worse off on governance than it was on day one. Not because anyone did anything wrong. Because governance in Teradata was never really a separate system. It was baked into the platform in ways that don't have a clean equivalent on the other side, and nobody budgets time to rebuild what they didn't know was disappearing.

What Teradata gave you for free (and BigQuery doesn't)

Teradata's access model runs on GRANT statements, roles, and profiles sitting directly on top of the tables — deeply embedded, and largely invisible unless you go looking for it. A lot of environments we assess also have business logic and access logic tangled together inside macros and views, built up over a decade by people who've since left.

None of that migrates automatically. A DDL conversion moves table structure. It does not move the fact that only four people in Finance could see the `customer_pii` view, or that a macro silently masked the last four digits of an account number before returning it. If nobody re-implements that intentionally, one of two things happens: access gets rebuilt too permissively because it's faster, or it gets rebuilt too restrictively and someone files a ticket three weeks after go-live asking why they can't see data they used to see. We've watched both happen on the same migration, in different schemas, within the same week.

The four things that actually need rebuilding

1. A real data catalog

Not a spreadsheet someone maintained for two months and abandoned. A catalog that answers, for every table: what is this, who owns it, what's the sensitivity classification, and how long do we keep it. In Teradata, this knowledge usually lived in someone's head or in a wiki page nobody linked to. Post-migration is the only time you'll ever have this much motivation to write it down properly, because you're already touching every table anyway.

2. Lineage, source to BigQuery

When a number on an executive dashboard looks wrong six months from now, someone needs to trace it back through every transformation to the original Teradata source in under an hour — not reverse-engineer three years of BTEQ scripts from memory. Lineage tracking is cheap to capture during the migration itself, while the source-to-target mapping already exists in your conversion notes. It's expensive to reconstruct afterward.

3. An access control matrix

A single document — schema, table, sensitivity tier, who gets read, who gets write, who gets nothing — cross-referenced against actual BigQuery IAM bindings and row/column-level security policies. This is what the old GRANT statements and view-based masking need to become. It's not glamorous work, but it's the difference between "we know exactly who can see this" and "we think we know."

4. Data quality rules, enforced not assumed

Teradata environments often carry years of implicit data quality assumptions — a column that's "never null in practice," a foreign key that's enforced by application logic rather than the database. None of those assumptions travel with a DDL conversion. Writing them down as explicit, testable rules (and running them as part of the pipeline, not as a one-time validation step) is what keeps quality from silently degrading a year after everyone's stopped paying close attention.

Dataplex, Alation, or DataHub — which one

We get asked this on nearly every assessment. The honest answer depends on where you're starting from, not on which tool has the better logo:

• Dataplex is usually the right default if you're GCP-native end to end. It's built into the platform, handles automated data classification reasonably well out of the box, and doesn't add a second vendor relationship to manage.
• Alation earns its cost when stewardship workflow is the actual bottleneck — when you need business users, not just engineers, actively curating and approving catalog entries, and you're willing to pay for a mature enterprise UI to make that happen.
• DataHub is the right call when budget is tight, engineering capacity is available to run it, or you're already invested in the open-source data tooling ecosystem. It's genuinely capable — it just asks more of your team to operate.

We've implemented all three. None of them fix a governance program that doesn't exist yet — they only make a real one easier to maintain.

Do this during the migration, not after

Every one of these four items is dramatically cheaper to build while you're already inside the schema doing conversion and validation work. "Govern" is the fifth stage of how we run every engagement for exactly this reason — not a phase that starts once the migration is declared done, but a workstream that runs in parallel with Convert and Migrate, so the catalog, lineage, and access matrix are already populated the day BigQuery goes live.

Retrofitting governance onto a platform that's already in production is not impossible. It's just two to three times the effort of building it alongside the migration, because now someone has to reverse-engineer decisions that were never documented in the first place.