Audit, rationalise, rebuild, validate and retire
Power BI migration consultancy
Move from Qlik, Tableau, SSRS, Cognos, Excel or other legacy reporting to governed Power BI without carrying every old report and workaround into the new estate. Hopton maps active use and logic, rebuilds the right content, validates old and new in parallel, and drives the legacy platform to an agreed retirement.
Migration starts with an inventory and owner decisions, not a dashboard count. The first conversation will establish the source platform, renewal or retirement date, report estate, data dependencies and continuity risk.
Audit first
before estimating the rebuild
Retire safely
instead of copying unused content
Rebuild natively
for Power BI rather than translate mechanically
Validate in parallel
before switching legacy reporting off
When migration becomes necessary
The legacy reporting platform is now a cost, continuity or growth constraint
A Qlik, Tableau, Cognos or other licence renewal is approaching.
The organisation needs a credible audit and sequence before committing to another term.
SSRS or paginated reporting has become difficult to support.
Active subscriptions, stored procedures and regulatory outputs need mapping before retirement.
Excel reporting depends on a few specialists.
Complex workbooks contain undocumented business logic, manual steps and version risk.
An ERP migration has split reporting history.
Old and new systems must be reconciled in one governed model.
The Microsoft estate makes Power BI the stronger long-term fit.
Entra ID, Microsoft 365, Azure, Fabric or Business Central can reduce platform fragmentation when designed properly.
Users want self-service, but cannot lose trusted logic.
Important calculations and workflows must be understood and carried into the new operating model.
The legacy tool is technically live but operationally fragile.
Support skills, server risk, failing jobs or undocumented dependencies threaten continuity.
Leadership wants the old platform switched off, not merely duplicated.
A clear retirement owner, acceptance criteria and cutover date are required.
If the current Power BI estate is the problem, use the Power BI Health Check. If the target platform is unresolved because of a wider ERP or Fabric decision, use the Reporting Modernisation Assessment before committing to migration.
What changes by source platform
The migration discipline is consistent; the technical risks are not
| Current estate | What must be understood | Power BI destination considerations |
|---|---|---|
| QlikView or Qlik Sense | Load scripts, associative model, set analysis, extensions, section access, bookmarks and active apps | Rebuild a governed semantic model and DAX measures; redesign security and user navigation rather than copying the Qlik application structure |
| Tableau | Data sources, extracts, joins, LOD expressions, table calculations, parameters, actions and workbook usage | Re-express business logic in models and DAX; redesign interactions for Power BI; carry power users through the change |
| SSRS | Active reports, subscriptions, stored procedures, parameters, print layouts, custom code and regulatory use | Choose paginated or interactive destination per use case; map every active subscription and dependency before switch-off |
| Cognos or BusinessObjects | Framework or universe metadata, prompts, bursting, schedules, security and report packages | Treat the semantic layer as a specification; rebuild dimensional logic, distribution and security natively |
| Excel | Workbook owners, formulas, Power Query, macros, manual inputs, linked files and process steps | Separate governed data and reusable measures from legitimate planning or input workflows; do not force every spreadsheet use case into Power BI |
| Legacy ERP reports | Source tables/APIs, historic data, custom fields, business rules and timing of ERP replacement | Preserve required history, reconcile old and new structures and select the right extraction/data-platform route |
No automated converter can replace this analysis reliably. The visual rebuild is often the easy part; understanding and governing the business logic is the migration.
How the migration works
Five stages from estate audit to legacy switch-off
- 1
Inventory and evidence
Record reports, apps, workbooks, subscriptions, owners, users, refresh schedules, sources, security, calculations, dependencies and renewal or retirement dates. Use system evidence as well as stakeholder memory.
- 2
Rationalise and prioritise
Classify content as retire, replace, consolidate, rebuild, retain temporarily or investigate. Frequency is evidence, not the only decision: an annual regulatory report may be critical even when rarely run.
- 3
Design the Power BI target
Define the governed semantic models, data architecture, security, workspace structure, deployment route, report patterns and migration waves. Decide whether Power BI alone is enough or Fabric is justified.
- 4
Rebuild and validate in waves
Recreate approved logic natively, consolidate duplicated reports and release working slices to owners. Reconcile totals, filters, security, performance and user workflows against agreed test cases.
- 5
Cut over and retire
Train users, migrate subscriptions and access, complete sign-off, freeze legacy change, switch the audience to Power BI and shut down the old platform when the definition of done is met.
A migration is not complete while the old platform remains the fallback. If temporary coexistence is necessary, give it an owner, cost, end condition and review date.
Control the scope
The audit produces a migration backlog people can approve
Required inventory fields
| Field | Purpose |
|---|---|
| Asset and platform | Identify the report, app, workbook or subscription |
| Business owner | Name the person accountable for its continuing need |
| Audience and use | Record who uses it, for which decision and how often |
| Criticality | Distinguish operational, financial, regulatory and convenience use |
| Source and dependency | Identify data, code, schedule, server and upstream/downstream links |
| Business logic | Record measures, calculations, prompts, filters and exceptions |
| Security | Record current audience and row/data restrictions |
| Current quality | Note reliability, performance, support and known discrepancies |
| Target decision | Retire, replace, consolidate, rebuild, retain temporarily or investigate |
| Migration wave | Sequence according to dependency, value and risk |
| Acceptance owner | Name the person who will sign off the Power BI replacement |
Core deliverables
- 1Estate inventory and ownership gaps.
- 2Rationalisation decisions and evidence.
- 3Target semantic-model and architecture design.
- 4Security and workspace mapping.
- 5Migration waves, dependencies and continuity plan.
- 6Report and logic mapping at the agreed scope.
- 7Validation and reconciliation test pack.
- 8Training and adoption plan by audience.
- 9Cutover, freeze, rollback and retirement plan.
- 10Cost and timeline for the defined migration scope.
Do not quote a full migration from a report count alone. Complexity sits in logic, sources, security, subscriptions, history, user workflows and the amount of content that can be retired.
Protect reporting continuity
Define success before the first legacy report is rebuilt
Validation must cover
- Reconciliation of agreed totals and measures across defined periods and entities.
- Filters, prompts, parameters, drill paths and exceptions required by the use case.
- Row-level security and audience access using named test identities.
- Refresh completion, freshness and failure handling.
- Report performance under representative use.
- Subscriptions, exports or paginated output where they remain necessary.
- Accessibility and usability for the intended audience.
- Named business-owner sign-off and recorded exceptions.
Definition of done
- 1Every active asset in scope has a recorded target decision.
- 2Every rebuilt or consolidated Power BI output has an owner and accepted test evidence.
- 3Required subscriptions, security and operating procedures are live.
- 4Users have the training and communication needed for cutover.
- 5Legacy content is frozen and the switch-off decision has an accountable owner.
- 6The old platform is switched off, or any agreed temporary coexistence has a documented end condition.
Running both platforms forever is not a successful migration. It preserves cost, risk and user confusion.
Choose the target data foundation
A migration to Power BI does not automatically require Fabric
Power BI-first migration
Suitable when the approved content uses a manageable number of reliable sources, the transformation and history needs are limited, and the immediate value sits in a governed semantic and reporting layer.
Power BI with Fabric
Suitable when several sources and platforms must be combined, legacy history must be preserved, shared transformations need a governed home, or engineering and analytics workloads need one Microsoft platform.
If the target remains uncertain, resolve it in the Reporting Modernisation Assessment before the migration backlog becomes a build commitment.
Published migration evidence
Nationwide Hygiene Group: QlikView to Power BI with no reporting loss
Nationwide Hygiene Group used Dynamics NAV and Business Central for ERP and QlikView for reporting. It needed to move QlikView, SQL and Excel reporting to Power BI, bring old NAV and new Business Central data together, and keep QlikView stable until the Power BI work was complete.
Hopton first secured and reworked parts of the QlikView system so the team could continue to trust the data. In parallel, Hopton migrated the approved reporting to Power BI and combined historic and current ERP data in one consistent environment.
Published outcomes
- One Power BI environment covering old NAV and new Business Central data.
- No loss of information or reporting during the move.
- Better visibility and efficiency once live.
- Lower ongoing cost and reduced platform risk.
“Working with Hopton has been a great decision for us. They have helped us migrate to Power BI, integrate our old and new ERP systems, and secure our QlikView project. Thanks to them, we have more confidence in our data, and we have reduced our ongoing costs and risks.”
Elena Stolyarova, Finance Director, Nationwide Hygiene Group
Plan before you migrate
Detailed guides for the source platform you are leaving
Common questions
Power BI migration: scope, risk and completion
Can Tableau or Qlik reports be converted automatically to Power BI?
Not reliably. Their data models, calculation languages, security and interaction patterns differ from Power BI. Automated conversion may produce files, but it does not create a governed, maintainable Power BI estate. Important logic must be understood and rebuilt natively.
Should every legacy report be migrated?
No. Inventory active use, ownership, criticality and dependencies first. Retire unused content with owner approval, consolidate overlapping reports and rebuild only what the future operating process requires.
How long does a Power BI migration take?
It can range from a few weeks to several months depending on report volume, source complexity, business logic, security, subscriptions, history and validation. The audit and rationalisation phase is what turns that uncertainty into a credible plan.
How much does a Power BI migration cost?
Cost depends on the approved migration backlog, model and source complexity, security, historic data, report redesign, parallel running and user transition. Hopton scopes fixed-price phases after the estate has been inventoried; a report count alone is not a reliable estimate.
How do you avoid losing reports or logic?
Create an evidence-based inventory, record owners and dependencies, map business logic, rebuild approved content, and run agreed old-versus-new reconciliation. The old platform remains available until critical outputs, security and subscriptions are signed off.
Can old ERP history be kept?
Yes, where the history is accessible and its meaning can be reconciled. The target model must map old and new structures explicitly. Hopton's Nationwide Hygiene Group case combines old Dynamics NAV and new Business Central data in one Power BI environment.
Do we need Microsoft Fabric for the migration?
Not automatically. Fabric is useful when multiple sources, preserved history, shared transformations or wider engineering workloads justify a governed data platform. A focused migration may use Power BI with a simpler curated source.
When is the migration finished?
It is finished when every active in-scope asset has a target decision, approved Power BI replacements are live and owned, required security and subscriptions work, users have transitioned, and the legacy platform is switched off or has a documented temporary end condition.
Start before the renewal or cutover deadline
Discuss your Power BI migration
Tell us the platform you are leaving, the approximate estate size, the source systems involved and any renewal, ERP or retirement date. We will explain the evidence needed for a safe scope and whether a migration audit or broader assessment should come first.