Planning checklist
An enterprise BI migration checklist
Use this checklist as a discussion document for a specific migration wave. Assign an owner and evidence to each decision. An unchecked item should become a discovery task or an explicit release dependency. Adapt the checks to your reporting estate; this is a planning guide, not a claim that every platform exposes the same validation controls.
1. Scope and ownership
Start with the reporting outcomes that must survive the move. Rationalize overlapping assets before treating the raw report count as the migration backlog. Record why each asset is in scope and who can approve its replacement.
- Source and target platforms, versions, and asset types are documented.
- A business owner is assigned to each reporting area.
- Keep, merge, retire, rebuild, and migrate decisions are reviewed.
- Dependencies, critical reporting periods, and release constraints are recorded.
2. Access and baseline evidence
A reproducible baseline makes differences easier to diagnose. Capture expected outputs with their data snapshot, filters, parameters, and refresh time. If source and target use different data snapshots, a result difference may not be caused by the conversion.
- Required source exports or connections are available.
- Target data access and publishing permissions are scoped.
- Reference datasets, filters, and expected outputs are captured.
- Deployment, identity, and infrastructure responsibilities are agreed.
3. Conversion and model review
Inspect converted artifacts before assuming they preserve source behavior. Review the grain of each table, relationships, shared calculations, and how filters propagate. Record unsupported constructs or redesign decisions in an exception register that stays with the asset.
- The selected migration path supports the intended input variant.
- Target model relationships and data types are reviewed.
- Calculation translations are inspected in business context.
- Parameters, visuals, navigation, and report interactions are checked.
- Manual repairs and known limitations have owners.
4. Validation and business acceptance
Syntax validation is useful, but it does not prove a metric has the same meaning. Reconcile reference results at detail and total levels. Exercise empty results, missing values, date boundaries, and representative filter combinations. Agree tolerances only where the business considers them acceptable.
- Reference totals and detail values reconcile or have explained differences.
- Filters, time calculations, and drill behavior are reviewed.
- Access requirements and representative user roles are tested.
- Refresh behavior and expected reporting performance are checked.
- Business owners accept the result and outstanding exceptions.
5. Cutover and support
Release planning should cover the people using the report as well as the artifact being published. Communicate the new location, changed interactions, and the support route. Preserve a recovery path until the replacement has been accepted in its intended environment.
- Publishing responsibility and the release window are agreed.
- Source retention and rollback decisions are documented.
- User communication and support ownership are ready.
- Post-release refresh and access checks have assigned owners.
- Source retirement happens only after the agreed acceptance gate.