BI report migration: how to change platforms without losing the reports people use

To move reports from one BI platform to another without losing the ones people rely on, build the inventory from the old platform's usage logs, not from its content list. Retire what nobody opens, merge the duplicates, and rebuild the metric definitions before the reports. Check each migrated report against the old one, number by number, and keep both running until the report's owner signs off. Vendor conversion tools exist mainly for moves inside one vendor's own product family; between vendors, plan to rebuild.

Start exporting usage data now

The four platforms below each record who opened what. Power BI, Looker and Tableau Cloud keep that record for a limited time. These are examples, in alphabetical order; check the documentation for the platform you are leaving.

• Looker. The System Activity Content Activity dashboard "shows information about which dashboards, Looks, and Explores are being viewed and scheduled," including a list of dashboards and Looks "that have not been accessed in the last 30 days." In the default configuration, "Looker stores a maximum of 90 days of historical query and event data."
• Microsoft Power BI. The activity log records events such as ViewReport and ShareReport. Administrators read it with the Get-PowerBIActivityEvent cmdlet or the Get Activity Events admin REST API. Microsoft states: "Activity log data is available for a maximum of 28 days," and recommends that you "export and retain the data so you can do historical analysis."
• Qlik Sense Enterprise on Windows. The Operations Monitor has a Sheet Usage sheet that shows users accessing sheets "and which sheets in which apps are not accessed." The Sessions Monitor has a Session Details sheet that "helps identifying unused apps and extensive users of apps." For Qlik Cloud, Qlik lists its App Analyzer as covering "user engagement, and sheet-level usage."
• Tableau. On Tableau Cloud, Admin Insights includes a TS Events data source covering "sign-in, publishing, and accessing views," and a Subscriptions data source with creators, recipients and schedules. It "captures up to 90 days of data by default and up to 365 days with an Advanced Management license." On Tableau Server, the Traffic to Views admin view shows view counts by day, the most-visited views and the users who open views most often.

A report opened once a year for the annual close, or once a quarter for the board pack, shows zero views in any 28-day or 90-day window that misses its date. Schedule an export of the usage data into storage you own on the first day of the project. Keep it running for a full business cycle before you mark anything unused. If the timeline cannot wait a year, ask finance, risk and regulatory reporting teams for their calendar-driven reports by name.

Add these consumers to the inventory by hand, because view logs may not show them:

• Subscriptions and scheduled email deliveries, whose recipients may never open the report in the browser.
• Reports embedded in other applications or portals.
• Exports and extracts that feed spreadsheets, other systems or regulatory filings.

Retire, consolidate, then migrate

Put every report in one of four groups.

• Retire. No views across a full cycle, no subscription, no owner who objects. Save the definition and a PDF of its last output, then remove it from scope.
• Consolidate. Several reports that answer the same question with different filters. Microsoft's migration requirements guidance says similar reports "might be consolidated using techniques such as filters, bookmarks, or personalization."
• Migrate. Used, owned, and still answering the right question.
• Redesign. Used, but the consumers export the data and rework it in a spreadsheet. Ask what they do with the export. The new report should do that step.

Every surviving report needs a named business owner before it enters the backlog.

Microsoft's migration overview advises against "strictly attempting to always migrate reports precisely as they appear in the legacy BI platform" and tells teams to "focus on the business question the report is trying to answer."

Rebuild or convert

The conversion tools the vendors document move content inside their own product families. None of the tools below converts another vendor's reports.

A conversion tool does not prove the numbers are right, and it carries over any dead content you did not retire first. Retire and consolidate before converting.

If the target platform is still undecided, CIOPages compares Microsoft Power BI vs Tableau and Qlik vs Tableau using its buyer guide evaluations.

Rebuild the metric definitions before the reports

Business logic in an old BI estate sits in many places: calculated fields in workbooks, filters saved on one dashboard, load-script expressions, SQL in a report's dataset. Two reports that both say "revenue" can compute it differently, and a migration copies that disagreement to the new platform.

Microsoft's requirements guidance tells teams to "identify and document all calculations, KPIs, and business rules that are currently defined within the existing report." Do that for every report in scope, then:

1. List each metric once, with every variant you found.
2. Have the metric's business owner pick one definition, in writing, with the reason.
3. Build that definition once, in the new platform's shared semantic model, not inside each report.
4. Point every rebuilt report at the shared model.

Microsoft's guidance on Power BI encourages separating the data model from reports "for data reusability purposes." The same structure applies on other platforms. Record every definition change in a log the report owners can read; each one will appear later as a reconciliation difference.

Reconcile number by number

Microsoft's content validation guidance sets the bar: "you'll need to ensure the data in the new report matches what's displayed in the legacy report," or be able to explain why it differs. It adds: "It's more common than you might think to find an error in the legacy solution that gets resolved in the new solution."

A reconciliation that holds up has these parts:

• Same data, same moment. Point both platforms at the same source, refreshed at the same time, or at a frozen snapshot.
• Test cases written in advance. For each report: the grand total, every top-level breakdown, several deep slices, and the edges of the calendar (month end, fiscal year end, the first period after a restatement).
• Security cases. Run the same checks as users with restricted access, to confirm row-level security returns the same rows on both sides.
• Tolerances agreed up front. Exact match for counts and currency amounts. A stated rounding rule for ratios and averages.
• A cause for every difference. Each one is a bug in the old report, a bug in the new one, an agreed definition change from the log, or a timing issue. A difference with no cause blocks sign-off.
• Repeatable checks. Script the comparisons where you can, so they run again after every change during the parallel period.

Microsoft lists four areas of validation: data accuracy, security, functionality and performance. Test all four before sign-off.

Run in parallel, then switch off on a date

Keep the old report live, unchanged, while the new one is in use. The parallel period should cover at least one full reporting cycle, including a month-end close, for every wave.

During that period:

• Make the old report read-only, with a notice that links to the new one.
• Check the new platform's usage data to confirm the old report's users are opening the new one. Follow up with anyone who has not moved.
• Keep the reconciliation scripts running.

Then set a decommission date and announce it. On that date, remove access to the old report, keep the archived definition and output for your records retention period, and, after the last wave, end the old platform's licenses. Check the old vendor's contract renewal date before you set the wave plan, so the last wave finishes before it.

Sign-off, by role

Microsoft's requirements guidance asks teams to identify each report's "owner and subject matter expert" and to include the "approvals and sign-offs" required for future changes. Capture those names during the inventory.

Count a report as migrated when its owner signs

Track progress by signed reports. A report counts as migrated when four things are true: its users are opening the new version, its reconciliation log is closed, its owner has signed, and the old version is switched off. A rebuilt report that is still running beside the old one is work in progress.

Frequently asked questions

Can Tableau workbooks be converted to Power BI automatically? None of the vendor migration tools in the table above does this. Plan to rebuild, and test any third-party converter on your hardest reports first.

Related Reading

• Business Intelligence & Analytics
• Embedded Analytics Platforms
• Data Catalog & Metadata Management
• Data Quality & Observability
• The Modern Data Stack: Selecting the Right Tools for Your Data Platform
• Data Governance at Scale: Building a Federated Governance Operating Model
• DataOps and Data Observability: Ensuring Trust in Data Pipelines