Post-Migration Governance: Maintaining a Clean Assets Schema After Go-Live

[#1]

Migration projects get a kickoff, a timeline, a project owner, and a retro. Then go-live happens, the project closes — and the schema that everyone spent three months carefully mapping just... keeps existing. Usually without anyone assigned to look after it.

Six months later it looks nothing like the clean structure you migrated. Not because anything broke. Because nobody owned it.

This is what schema drift actually looks like

It rarely happens as one bad decision. It happens as fifty small, reasonable ones:

• A team lead asks for "just one field" to track something urgent. It ships. Nobody documents why it exists.

• Two different teams independently create near-identical object types because neither knew the other's existed.

• An automation rule gets built to solve a one-off problem and quietly keeps running two years later, touching objects nobody remembers the logic for.

• Naming conventions that were airtight at go-live slowly diverge as new admins join and nobody wrote them down anywhere but "how we've always done it."

None of this shows up as an incident. It shows up as a schema that's slower to navigate, harder to onboard new admins into, and increasingly risky to touch — because nobody's confident anymore about what depends on what.

What governance actually needs to cover

Not a heavyweight process. Four things, owned by someone:

1. A named schema owner. Not a team — a person. Migration had a project owner; the schema needs one too, permanently, not just for the ninety days after go-live.

2. A lightweight change request path. "Can you just add one field" doesn't need a six-week approval chain. It needs a five-minute check: does this already exist somewhere, and who else does it affect.

3. A quarterly audit. Thirty minutes, four questions: What's unused? What's duplicated? What's undocumented? What's an automation rule touching that nobody can explain? That's usually enough to catch drift before it compounds.

4. A deprecation policy. Old fields and object types don't need to be deleted immediately — they need a documented "this is retired, here's why" so the next admin doesn't have to guess.

Why this matters more after a migration than before one

Pre-migration, your schema had months of scrutiny — everyone was looking at it, mapping it, arguing about it. Post-migration, that scrutiny disappears overnight, right when the schema is at its cleanest and easiest to keep that way. The next twelve months determine whether it stays that way or quietly reverts to the mess you just spent a quarter fixing.

Backup protects you from losing the schema. Governance protects you from the schema slowly becoming something you don't recognize.

[Maria Reisinger _MetaFrazo_]

The framing I keep coming back to is your last line, that backup protects the schema and governance protects it from becoming something you don't recognize. That distinction gets collapsed constantly, and the two need completely different answers.

One thing I'd add to the quarterly audit. Your four questions all describe the current state: what's unused, duplicated, undocumented. They're the right questions, and they still leave the hardest one open, which is what changed since the last audit and who changed it. Without that, every audit starts from scratch and drift is only visible if someone happens to remember what it looked like before.

That's most obvious in your automation example. "A rule nobody can explain" is not really a documentation problem. By the time it surfaces, the person who built it and the reason it existed are both gone from anywhere you can look.