BI Governance: Migration Playbook

Automation

BI governance during a migration is not a documentation exercise. It is the decision system that determines which dashboards survive, which metrics become official, who owns them, and what quality controls must exist before people rely on the new BI environment.

Why BI governance matters during a migration

A BI migration exposes every reporting shortcut a company has accumulated: duplicated dashboards, conflicting revenue definitions, abandoned reports, manual CSV uploads, hidden spreadsheet logic, and no clear owner when numbers break.

If you migrate everything as-is, the new tool inherits the old distrust. The interface changes, but the operating problem remains. People still debate which dashboard is right. Leaders still ask for manual reconciliations. Analysts still spend too much time explaining numbers instead of improving decisions.

Good BI governance gives the migration a filter. Instead of asking, Can we move this report?, the team asks, Should this report exist, who owns it, what decision does it support, and how will we know if it is wrong?

Define the governance scope before moving dashboards

Start by defining what BI governance means for this migration. Keep it practical. A beginner team does not need a heavy governance council, but it does need explicit rules for the assets that matter most.

At minimum, define governance for five things:

• Metrics: which calculations are official, where they are defined, and who can approve changes.
• Dashboards: which reports are certified, which are exploratory, and which should be retired.
• Data sources: which tables, models, or semantic layer objects are approved for reporting.
• Access: who can view, edit, publish, export, or grant access to reporting assets.
• Reliability: what checks, alerts, freshness rules, and incident processes protect important dashboards.

The goal is not to control every chart. The goal is to make important decisions traceable to trustworthy data.

Step 1: Inventory the current BI environment

Before choosing what to rebuild, create an inventory of the existing BI environment. This should include dashboards, reports, scheduled exports, embedded analytics, downstream spreadsheets, and recurring manual reporting packs.

For each asset, capture the practical facts:

• Dashboard or report name.
• Primary audience.
• Business decision it supports.
• Owner or closest known subject matter expert.
• Data sources and upstream models.
• Key metrics used.
• Usage pattern, if available.
• Known quality issues or stakeholder complaints.
• Whether the report is regulatory, executive-facing, operational, customer-facing, or exploratory.

Do not spend weeks perfecting the inventory. A useful inventory is complete enough to make migration decisions, not polished enough to become a separate project.

Step 2: Classify what to migrate, retire, or redesign

Most BI migrations fail quietly because teams move too much. Every old dashboard feels safer to preserve than challenge. But carrying forward low-trust reporting increases maintenance cost and confuses users in the new environment.

Classify each asset into one of four groups:

• Migrate: still used, trusted enough, clearly owned, and tied to an active decision.
• Redesign: still needed, but structurally broken, duplicative, confusing, or based on weak logic.
• Archive: occasionally needed for historical reference, but not part of active operations.
• Retire: unused, obsolete, duplicated, ownerless, or not tied to a real decision.

This is where BI governance becomes practical. A dashboard does not earn migration because it exists. It earns migration because it supports a decision and has enough ownership and reliability to deserve continued investment.

Classification	Use when	Governance action
Migrate	The dashboard is used, trusted, owned, and tied to an active decision.	Rebuild with validation, ownership, and support expectations.
Redesign	The dashboard is needed but confusing, duplicated, slow, or based on weak definitions.	Resolve definitions and workflow requirements before rebuilding.
Archive	The report is rarely used but may be needed for historical reference.	Preserve access with clear labeling, but keep it out of the official reporting path.
Retire	The report is unused, obsolete, duplicated, or ownerless.	Communicate retirement and remove it from active navigation.

Step 3: Standardize metric definitions before rebuilding charts

Do not rebuild dashboards before resolving conflicting metric definitions. If three dashboards define active customer differently, migrating them into a new tool only makes the disagreement easier to find.

Pick the high-value metrics first. For a SaaS company, that may include revenue, churn, active accounts, pipeline, conversion rate, product usage, and support response metrics. For an operations-heavy business, it may include fulfillment time, backlog, margin, utilization, defects, and SLA performance.

For each governed metric, document:

• The plain-English definition.
• The calculation logic.
• The source tables or approved model.
• Important filters and exclusions.
• Refresh expectation.
• Business owner.
• Technical owner.
• Known limitations.
• Change approval process.

The best metric definitions are boring, discoverable, and maintained close to the data logic. If the definition lives only in a slide deck, people will eventually rebuild it differently somewhere else.

Step 4: Assign ownership and change control

BI governance breaks when everyone can request changes but nobody owns the consequences. During migration, assign ownership at three levels.

• Business owner: accountable for what the metric or dashboard means and whether it supports the right decision.
• Technical owner: accountable for the data model, transformation logic, tests, deployment, and troubleshooting path.
• Consumer owner: accountable for confirming that the migrated report supports the workflow of its audience.

For small teams, one person may wear multiple hats. That is acceptable if the responsibility is explicit. The failure mode is not a small team. The failure mode is assumed ownership.

Define change control for certified assets. A minor label edit should not need a committee. A revenue definition change should require review, communication, testing, and a clear effective date.

Asset type	Minimum owner	Change control needed
Certified metric	Business owner and technical owner	Required for definition, source, filter, or grain changes.
Executive dashboard	Business owner, technical owner, consumer owner	Required for metric, layout, source, refresh, or audience changes.
Team dashboard	Business owner or delegate, technical support owner	Lightweight review for major logic changes.
Exploratory analysis	Creator	Usually no formal approval unless promoted to official reporting.

Step 5: Build reliability into the migration

Pipeline reliability is part of BI governance because dashboard trust depends on upstream behavior. A beautiful dashboard is not useful if the source job silently fails, the transformation produces duplicate rows, or the refresh timestamp is misleading.

For every critical migrated dashboard, define the reliability contract:

• What upstream data must arrive?
• How fresh does the dashboard need to be?
• What tests protect the key models?
• What volume, uniqueness, null, and relationship checks matter?
• Who receives alerts?
• What is the escalation path when numbers look wrong?
• How is a known incident communicated to users?

Automation helps here, but it should enforce a clear operating rule. Automated tests with no owner become noise. Alerts with no response expectation become background email.

Step 6: Design permissions for safe self-service

Self-service BI does not mean every user can publish official dashboards. It means users can answer more questions safely because the trusted data products, permissions, and publishing paths are clear.

Create simple permission tiers:

• Viewers: consume certified dashboards and governed reports.
• Explorers: build ad hoc analysis from approved datasets or semantic objects.
• Creators: publish team-level dashboards using governed sources.
• Certifiers: approve official dashboards and governed metric usage.
• Admins: manage platform configuration, access, and sensitive settings.

The exact names depend on the BI platform. The durable principle is separation of exploration from official reporting. Exploration should be encouraged. Certification should be deliberate.

Step 7: Run parallel validation before cutover

Before replacing old dashboards, run the new and old versions in parallel for the assets that matter. The goal is not to make every number match perfectly. The goal is to explain every meaningful difference.

Common causes of differences include:

• Different date logic.
• Different time zones.
• Changed filters or default parameters.
• Different handling of deleted, refunded, inactive, or test records.
• Late-arriving data.
• Duplicate source records that were hidden by old logic.
• Manual adjustments in the old process that were never documented.

Keep a validation log. For each difference, mark whether it is a migration bug, an intentional definition change, a source data problem, or an old dashboard defect. This log becomes part of the trust-building process with stakeholders.

Validation question	Why it matters	Evidence to collect
Do old and new dashboards use the same metric definition?	Prevents false migration defects caused by definition drift.	Metric spec, SQL or model logic, filters, exclusions.
Are date and timezone rules aligned?	Many reporting mismatches come from period boundaries.	Date logic, timezone setting, example records near boundaries.
Are manual adjustments present in the old process?	Manual corrections often explain unexplained gaps.	Spreadsheet formulas, adjustment logs, recurring finance or ops entries.
Is the difference acceptable and explained?	Not every mismatch is wrong, but every important mismatch needs a reason.	Validation log with owner sign-off.

Step 8: Certify, launch, and monitor

Once dashboards pass validation, certify them in a way users can recognize. Certification should mean something specific: the dashboard has an owner, uses governed definitions, has passed validation, and has a known support path.

At launch, communicate three things clearly:

• Which dashboards are official.
• Which old dashboards are retired or archived.
• How users should report issues or request changes.

After launch, monitor adoption and reliability. A migrated dashboard that no one uses should be questioned. A heavily used dashboard with recurring incidents needs stronger upstream controls. BI governance continues after cutover because business definitions, source systems, and operating workflows keep changing.

Common BI governance migration failure modes

Most BI governance problems are predictable. Watch for these patterns during a migration.

• Lift-and-shift reporting: every old dashboard is rebuilt without asking whether it is still useful.
• Metric debates after launch: definitions were not resolved before dashboards were published.
• Ownerless certified dashboards: reports appear official, but nobody is accountable when numbers change.
• Access sprawl: too many people can publish, duplicate, or modify important assets.
• Hidden spreadsheet dependencies: the BI tool changes, but critical reporting still depends on manual files.
• No incident process: users notice broken numbers before the data team does.
• Over-governance: simple exploratory work becomes so restricted that teams export data and work around the system.

The right level of governance reduces ambiguity without freezing analysis. If governance only creates approvals and no trust, it is too heavy. If it creates freedom with no standards, it is too loose.

How to measure whether BI governance is working

BI governance is working when the organization spends less time arguing about numbers and more time using them. That can be measured with simple operational signals.

• Reduction in duplicate dashboards for the same decision area.
• Percentage of critical dashboards with named business and technical owners.
• Percentage of certified dashboards with documented metric definitions.
• Number of recurring data quality incidents affecting executive or operational reporting.
• Time to detect and communicate dashboard issues.
• Usage of certified dashboards versus shadow reports.
• Number of unresolved metric definition disputes.
• Stakeholder confidence in official reporting during planning, forecasting, and operating reviews.

Do not treat these as vanity metrics. Use them to find the next weak point in the reporting system.

Key takeaways

• BI governance is the operating system for trusted reporting, not a one-time documentation task.
• A migration should filter dashboards by usage, ownership, decision value, and reliability instead of moving everything by default.
• Metric definitions should be standardized before dashboards are rebuilt, especially for executive, financial, and operational reporting.
• Pipeline reliability belongs inside BI governance because dashboards depend on upstream freshness, tests, alerts, and incident response.
• Good governance separates exploration from certification so teams can move quickly without confusing ad hoc analysis with official reporting.

Next step

Start with a one-page BI migration inventory. List your top 20 dashboards, assign each to migrate, redesign, archive, or retire, and identify the owner, key metrics, source models, freshness expectation, and known trust issues for each one.