Migrations From Legacy BI Tools - FAQs

Yes — there are situations where staying on Tableau is the right call. Organisations with deep, specialist analyst teams doing highly bespoke visual analytics, particularly those without a significant existing Microsoft 365 or Azure footprint, may find the switching cost and retraining effort outweighs the licensing saving. We would say so directly rather than push a migration that does not make sense for a specific client.

Cognos and Power BI can run in parallel during the transition, and we recommend it for exactly the same reason as any other BI migration: running both platforms in parallel for at least one reporting cycle and reconciling figures before retiring Cognos access for a given report, so no one loses a working report mid-transition.

Cognos reports and packages cannot be automatically converted reliably. Cognos Framework Manager packages and report specifications use fundamentally different modelling concepts to Power BI's semantic model, and automated conversion tools tend to produce something technically functional but poorly structured and hard to maintain going forward. We rebuild the underlying model deliberately rather than attempting automated conversion.

Yes — modernisation can work alongside a future replacement, and in many cases it should. The modernised analytics layer is independent of the source system. If a replacement happens later, the analytics layer is rebuilt to point at the new source. The historical data accumulated in the modernised layer survives the replacement, which is the opposite of the usual pattern. This decouples the analytics conversation from the system conversation. They become separate projects rather than one combined risk.

You can sometimes keep using historical data after a replacement, with effort. Most replacement projects bring across enough recent history for operational continuity but cut older data for cost or schema reasons. Reuniting the old and new history afterwards is a separate project that often does not happen. The honest position is that replacement makes historical data harder to use, not easier. Modernisation preserves the history because it does not touch the source system. The history continues to accumulate in the existing place and the analytics layer pulls from it.

Yes — you can run Qlik and Power BI in parallel during the transition, and you almost certainly will. Two to three months of parallel running lets users transition gradually and gives you a fallback if a Power BI report has an issue. Plan for the cost. The risk is letting parallel running drift on indefinitely. A fixed switch-off date avoids that.

You can run SSRS and Power BI in parallel during the migration, and almost always should for at least four to eight weeks. SSRS subscriptions in particular need to keep delivering while Power BI equivalents bed in. Set a fixed switch-off date in the audit phase. SSRS instances often live for years after they should have died if there is no commitment to a date.

Yes — you can run Tableau and Power BI side by side during a transition, and we recommend it. We run both platforms in parallel for at least one full reporting cycle, reconciling figures between the two, before retiring Tableau access for a given report, so no one is left without a working report during the transition.

Your Tableau dashboards do not necessarily need to look identical in Power BI, and we would not usually recommend it. We aim to preserve the metrics, structure, and interactivity users rely on, while taking the opportunity to apply good Power BI-specific design practice rather than forcing a visual layout that fought against Tableau's conventions to now fight against Power BI's.

Yes — we often do BC reporting migrations as part of SSRS work. Many SSRS reports built for older Microsoft ERPs (NAV, AX, GP) need careful handling because they touch BC equivalents. We have a separate playbook for BC reporting options, and the SSRS migration sometimes sits inside that wider conversation. If you are running BC and SSRS together, the two playbooks complement each other.

Hopton has specific experience migrating clients off Tableau, alongside our broader experience migrating clients from Qlik, SSRS, and Excel-based reporting onto Power BI. The underlying discipline - understanding existing logic thoroughly before rebuilding it properly rather than translating it mechanically - is consistent across all of these migration types.

Hopton has specific experience with Cognos migrations, as part of our broader legacy BI migration practice alongside Qlik, Tableau, SSRS, and Excel-based reporting migrations. The core discipline - understanding existing logic thoroughly before rebuilding it properly in Power BI - is the same regardless of which legacy platform is being replaced.

We do not implement or support Tableau as an ongoing platform. Our specialism is the Microsoft data and analytics stack, and our Tableau-related work is specifically migration onto Power BI, not ongoing Tableau delivery.

Hopton only migrates clients off Cognos onto Power BI, rather than implementing or supporting Cognos. Our specialism is the Microsoft data and analytics stack, and our Cognos-related work is specifically about moving clients from it, not delivering or supporting Cognos as an ongoing platform.

Both Tableau and Power BI have invested heavily in AI and natural-language querying - Tableau through Tableau Pulse and Einstein-related capability under Salesforce ownership, Power BI through Copilot for Power BI. For most mid-market organisations already committed to the Microsoft ecosystem, Power BI Copilot benefits from deeper integration with the Microsoft 365 tools those users already work in daily.

Migrating from Tableau makes sense if you are happy with it technically but not with the cost - this is one of the more common and rational reasons to migrate. Cost consolidation on its own is a legitimate business case, provided the migration itself is planned carefully enough that the switching cost does not erode the savings in year one.

No — moving from Cognos to Power BI does not mean losing centralised governance, provided the migration is done properly. Power BI supports strong centralised governance through certified semantic models, workspace permissions, and row-level security; it simply also allows self-service report building on top of that governed layer, which Cognos's more centralised model does not emphasise as strongly.

This applies to both QlikView and Qlik Sense. QlikView is end-of-life and the migration urgency is higher there. Qlik Sense is supported but the same drivers apply: licensing economics, feature parity with Power BI on the workloads most mid-market organisations actually run, and the integration tax of running an analytics platform separate from the rest of the Microsoft estate.

Cognos's namespace, group, and package-based security concepts map onto Power BI's workspace roles and row-level security model, but not one-to-one. We map your existing Cognos security requirements onto the nearest appropriate Power BI equivalent deliberately, rather than leaving this to default settings during migration.

To avoid losing your Qlik power users, involve them early, often, and on their own reports. Power users have spent years learning Qlik and they have legitimate concerns about whether Power BI will let them work the same way. The answer is sometimes yes, sometimes no, and being honest about both builds trust. Train them on Power BI using the reports they care about, not on a generic course.

To get a cost and effort estimate for migrating from Tableau to Power BI, email hello@hoptonanalytics.com with a description of your current Tableau estate - roughly how many workbooks, how many active users, and which data sources are involved. The first conversation is free and exploratory, and typically leads to a scoped Establish phase producing a firm cost and timeline estimate.

To get a cost and timeline estimate for a Cognos migration, email hello@hoptonanalytics.com with a description of your current Cognos estate - roughly how many packages, reports, and active users are involved, and how long the environment has been in place. The first conversation is free and exploratory, and typically leads to a scoped Establish phase producing a firm estimate.

Four things tell you when the SSRS migration is done. Every active report is live in Power BI as paginated or interactive. Every active subscription has a Power BI equivalent running. Inactive reports are documented and retired with sign-off. SSRS server is off and licences released. If any one is missing, the project is not done. The last one is where most migrations linger if no one drives the switch-off.

Three signals, in order of strength, tell you which SSRS reports are actually being used. Active subscriptions, because someone deliberately set them up and presumably reads them. Recent execution logs from the SSRS database, which tell you when each report last ran and how often. Sign-off from named owners, because anonymous reports rarely have anyone willing to defend them. Combine all three and you have the active list.

We manage SSRS subscription transitions during a Power BI migration by mapping every active SSRS subscription, building the Power BI equivalent, running both for a few weeks, then switching off the SSRS one. Recipients see the Power BI version arriving on schedule before the SSRS version disappears. The trust this builds is worth the few weeks of duplicate emails. Switching cold creates anxiety and complaints.

We handle Tableau Server or Tableau Cloud governance and permissions when moving to Power BI by mapping existing Tableau permission structures (who can see and edit what) onto Power BI's workspace and row-level security model, which works differently under the hood but achieves equivalent governance outcomes. This mapping exercise is done deliberately rather than left to default settings, since the two platforms' security models are not a direct one-to-one match.

Embedded VB.NET and custom assemblies often hide business rules and need extracting carefully. Embedded code in SSRS reports tends to grow organically, with formatters, calculation helpers and IIF chains accumulating over years. Document the logic, decide whether it belongs in the data layer, the report, or somewhere else, then rebuild it. Migrating without this audit means rebuilding bugs into the new platform.

For stored procedures that drive SSRS reports, we audit them, document them, then decide what comes with you into the Power BI migration. Many SSRS estates have business logic buried in stored procedures that nobody fully understands. The migration is the moment to surface that logic. Some procs come across to the new architecture. Some get rewritten as DAX or Power Query. Some get retired with their reports. The decision is per proc, not blanket.

Subreports do not have a direct Power BI equivalent. Most need to be flattened into the parent report, replaced with drill-through pages, or split into separate paginated reports. The right answer depends on the use case. Plan extra time for any report with significant subreport use, particularly if subreports drive the page layout.

Subscriptions are usually the most-used SSRS feature and often the least documented. Active email subscriptions are the strongest signal of which reports are actually used. Map every active subscription before switching anything off. Power BI subscriptions cover the same use cases, sometimes more cleanly. The migration is the moment to also question whether each subscription still serves a purpose.

We migrate Tableau calculated fields into Power BI by understanding the business logic each calculated field represents and rebuilding it as a proper DAX measure in Power BI's semantic model, rather than translating formula syntax mechanically. This is also the opportunity to correct or simplify calculations that may have accumulated workarounds over the Tableau workbook's lifetime.

We migrate a Cognos Framework Manager model into Power BI by treating the Framework Manager model as a specification of the business's dimensional structure and calculation logic, then rebuilding that structure properly as a Power BI semantic model with appropriate relationships, hierarchies, and DAX measures, rather than translating metadata mechanically.

A migration from Tableau or QlikView to Power BI is a rebuild, not a lift-and-shift, because the way each tool models data, calculates measures and handles row-level security is different. The approach that avoids losing reports is to inventory the existing reports first, identify which are actually used, and rebuild the important ones on a clean, governed Power BI semantic model rather than copying every legacy quirk across. Business logic is re-expressed in DAX, security is rebuilt with Power BI row-level security, and the old and new systems run in parallel until users have signed off. A typical mid-market migration runs over a few weeks to a few months depending on report volume and data complexity. Hopton Analytics migrates businesses from Tableau, QlikView and MicroStrategy to Power BI in the UK.

Hopton engages on an SSRS migration in two ways. A migration audit, two to three weeks at fixed price, with no obligation to proceed. Or a full migration programme, direct contracting, fixed milestones, SSRS retirement date in the plan from day one. Most clients start with the audit because the audit answer often changes the migration scope significantly.

Hopton typically engages on a Qlik migration in two ways. A migration audit, which is a two to three week assessment of your Qlik estate at fixed price and fixed output, with no obligation to proceed. Or a full migration programme, end to end, with direct contracting and a decommission date written into the plan from day one. Most clients start with the audit because it is the cheapest insurance on a project of this size.

Qlik Set Analysis does not translate directly to DAX. Set expressions, dollar-sign expansions and complex modifiers do not have one-to-one DAX equivalents. Most Set Analysis logic gets rewritten as DAX measures, often more cleanly than the original. Treat Set Analysis as documentation of intent, not as code to be ported. Rewrite the intent in DAX patterns native to Power BI.

Power BI is typically materially cheaper per user, particularly for organisations already paying for Microsoft 365, where Power BI often represents an incremental cost rather than an entirely new licence line. Tableau's licensing is usually higher per seat and priced independently of any other software you already own.

Cognos has traditionally centred on IT-authored, centrally governed reports and packages, with business users mainly consuming rather than building. Power BI leans further towards self-service, where trained business users build their own reports against a governed semantic model. Neither approach is objectively better; the right fit depends on how much you want reporting authorship distributed versus centralised in your organisation.

Paginated reports preserve print fidelity. Interactive Power BI reports do not, by design. If a report is printed, it should be paginated. Forcing interactive reports into print contexts is the most common cause of complaint after an SSRS migration. Get the per-report decision right at the audit phase and print fidelity is a non-issue.

A Cognos to Power BI migration typically takes, for a focused core reporting suite, eight to fourteen weeks from discovery through validated go-live, reflecting the typically more complex underlying data models found in longer-established Cognos estates. Larger, long-running Cognos deployments with many packages and report authors are usually phased over a longer programme.

A Tableau to Power BI migration typically takes six to twelve weeks for a focused set of core dashboards, from discovery through validated go-live. Larger Tableau estates with many interconnected workbooks and a broad analyst user base are usually phased over a longer programme, prioritising the highest-usage dashboards first.

Modernisation typically takes three to six months for a mid-market business with one main source system. Replacement takes 18 to 30 months. The cost ratio is comparable: modernisation is usually 10 to 25 per cent of the cost of a comparable replacement. The risk ratio is wider still, because modernisation projects have failure modes that are smaller and more recoverable than replacement projects. The only thing replacement does that modernisation cannot is fix problems that are genuinely in the source system.

A typical Qlik to Power BI migration takes three to six months for a typical mid-market estate of fifty to two hundred Qlik objects. Larger estates take longer, mostly because the audit phase is where the real work sits. The build phase is usually the most predictable part. The pre-build audit and the post-build user transition are where projects slip if they slip.

A typical SSRS migration takes two to six months, with a wide range driven by estate size more than by complexity per report. A small estate of fifty active reports finishes in two to three months. A two-hundred-report estate with stored proc dependencies and active subscriptions takes four to six. The audit phase often takes longer than expected because most SSRS estates have not been mapped in years.

A Qlik to Power BI migration costs, for most mid-market migrations, between sixty and two hundred thousand pounds, depending on estate size and complexity. The audit is usually fifteen to twenty-five thousand. The build scales with the number of Qlik apps and the complexity of the data layer underneath. The user transition phase is often underestimated and can be ten to twenty per cent of total project cost.

No, IBM continues to actively develop and support Cognos Analytics. Organisations migrating away from it are typically doing so for cost, ecosystem fit, and skills-availability reasons specific to their own situation, not because Cognos itself has become unsupported or technically obsolete.

Power BI Premium per-capacity licensing (P SKUs) has been superseded by Fabric capacity licensing (F SKUs), which Microsoft now positions as the standard way to license Power BI at capacity scale, alongside the rest of the Fabric platform (data engineering, data warehousing, real-time intelligence, and data science). Existing Premium capacities continue to be supported for a transition period, but Fabric capacity is the direction Microsoft's licensing and roadmap are heading.

SSRS is not formally being deprecated by Microsoft. SQL Server Reporting Services remains supported and still ships with SQL Server. What has changed is the direction of investment. Microsoft is putting effort into Power BI Paginated and Fabric, not into SSRS. SSRS will keep working for years, but new capability is going elsewhere. Most organisations migrate not because SSRS has stopped working but because the rest of their stack has moved on.

Tableau is not being deprecated - it remains an actively developed, well-supported product under Salesforce ownership. Power BI's growth has been driven by Microsoft's ecosystem bundling and aggressive feature investment rather than Tableau declining. Migrations we see are driven by an organisation's own cost and ecosystem decisions, not by Tableau becoming unsupported.

Tableau has historically had an edge in bespoke, highly customised visual design, and it retains a loyal following among specialist analysts who value that flexibility. Power BI has closed much of that gap over recent releases and, for the large majority of standard business reporting - trends, comparisons, breakdowns, KPI tracking - the two are functionally comparable. The remaining gap matters most for organisations doing genuinely novel, custom visual analytics rather than standard business dashboards.

Often, yes, particularly where the Cognos estate has grown over many years and multiple report authors, because the underlying Framework Manager models tend to accumulate more embedded business logic than equivalent Tableau or Qlik estates of a similar age. We scope this properly during discovery rather than assuming migration complexity is uniform across legacy platforms.

No — not every SSRS report should move to Power BI, and that is the point. Most SSRS estates have sixty per cent or more of reports that nobody runs. The migration is the chance to retire those, with proper sign-off, rather than dragging them along. The active reports move to Power BI Paginated or Power BI interactive depending on use case. The inactive ones get documented and switched off.

Qlik variables, triggers and actions matter in a migration because heavy use of these usually signals a control surface that someone built to make Qlik feel like an application. Replicating the form in Power BI rarely works well. Replicate the function instead. Bookmarks, buttons, parameters and Power Apps integration cover most of what variables and triggers were doing, often more cleanly. Some functions do not transfer at all and the migration is the moment to ask whether they were worth it.

Your Tableau data source connections and extracts are rebuilt as Power BI data source connections and, where appropriate, a proper semantic model with Power Query transformations, rather than carried over as-is. Where the underlying data platform is also changing (moving onto Fabric, for example), this is a natural point to improve the data architecture at the same time.

A typical SSRS migration project runs in three phases. Discover, where we inventory every report and subscription, identify active versus inactive, and audit stored procs and custom code. Two to four weeks. Migrate, where we rebuild paginated as paginated, tactical as interactive, and migrate subscriptions. One to four months. Embed, where we switch off SSRS and hand over a smaller, governed estate. Two to four weeks.

The Qlik to Power BI migration audit delivers a written assessment covering: every Qlik object inventoried, active versus inactive identified, complexity scored, business-rule risks flagged, a recommended migration sequence, a target end state on Fabric or Power BI, and an indicative cost and timeline. You can take the output and run the migration with anyone, including in-house.

The SSRS to Power BI migration audit delivers an inventory of every SSRS report and subscription. Active versus inactive map. Paginated versus interactive candidate list. Subscription mapping. Stored proc and custom code dependency map. A recommended migration sequence and indicative cost. The audit often pays for itself in the retirement decisions alone, before the migration even starts.

If the readiness assessment recommends a system replacement, we say so plainly and explain the reasoning. Hopton does not deliver ERP replacements (BC, AX, NAV, etc.) so we will refer you to partners who do. Even in this case, we often recommend a parallel modernisation track for the analytics layer, because the replacement will need a modern analytics layer afterwards anyway. Building it independently lets it deliver value during the replacement project rather than after. We have several clients running this hybrid pattern.

During migration, your existing Cognos reports are handled by priority: we prioritise rebuilding the reports that are actually used regularly, based on usage data where available, rather than assuming every historical Cognos report needs to be recreated. Organisations that have run Cognos for many years typically have a long tail of rarely used reports that are not worth migrating.

Your existing Qlik licences run alongside Power BI through the migration period and get cancelled at switchover. The decommission date matters. Without one, both platforms run forever and you pay for both. Set the date in the project plan and make it visible. Hopton clients commit to a switch-off date during the audit phase, and the rest of the work runs to that deadline.

Undocumented Qlik QVDs with the original developers gone is a common situation. The audit phase becomes a forensic exercise: trace data flows, profile outputs, and reconstruct the rules from the data itself. It is slower than auditing a documented estate but rarely impossible. Plan an extra two to four weeks in the audit phase and engage someone who has done this before. Skipping the audit and rebuilding in the dark is much more expensive.

If you have already started an ERP replacement project, the assessment is still useful. Many in-flight replacements can be paused or scoped down once the analytics-first alternative is on the table. The assessment is honest about what is salvageable from the work already done and what the cleanest path forward looks like from the current state. We have helped clients pause replacement projects mid-flight, deliver the visible value through modernisation, and then evaluate whether the original replacement was still worth completing. Sometimes it was. Often it was not.

The biggest risk in a Cognos migration specifically is underestimating the complexity embedded in a mature Framework Manager model that has been extended over many years, and rebuilding a simplified Power BI version that quietly changes what established metrics mean. Thoroughly understanding the existing model with people who know its history, before rebuilding, is the step that prevents this.

The biggest risk in a Tableau to Power BI migration that goes badly is underestimating the calculation logic buried in Tableau calculated fields and level-of-detail expressions, and rebuilding a simplified version in Power BI that quietly changes what a number means. Thoroughly documenting existing logic with the people who use the reports, before rebuilding, is the step that prevents this.

Tableau is a standalone visual analytics tool with a strong reputation for visualisation flexibility and depth, historically licensed and priced independently of any single software ecosystem. Power BI is built and priced as part of the Microsoft ecosystem, with tight integration into Microsoft 365, Azure, Fabric, and Teams. The practical difference for most mid-market buyers is less about raw visualisation capability and more about how well the tool fits the rest of your technology estate.

The first step if we are only exploring a move away from Cognos, not yet committed is a discovery conversation reviewing your current Cognos usage, licensing cost, and the specific pain points driving the consideration, so we can give an honest view of whether migration is likely to deliver a worthwhile return before any commitment is made.

The most common pitfall in a Qlik to Power BI migration is treating it as a lift and shift. Qlik apps are not Power BI reports in different clothes, and trying to make them so wastes the migration. The teams that succeed treat it as a redesign that happens to retire the old platform. The teams that struggle try to recreate the originals visual by visual and end up with something less useful than what they started with.

The most common reason organisations migrate from Tableau to Power BI is cost and ecosystem consolidation. Many mid-market organisations already pay for Microsoft 365 and are running some Power BI licences somewhere in the business; consolidating onto a single reporting platform that is effectively bundled into existing Microsoft spend, rather than paying for two overlapping BI tools, is usually the deciding factor.

Around sixty per cent of SSRS reports are typically retired during a migration. Some estates are higher, some lower. The wholesalers and retailers we work with often retire seventy or eighty per cent because the estates have grown organically over many years with no review. The discipline is having someone willing to sign off on retirement. Without that, everything gets migrated and the savings are lost.

The biggest technical difference between Qlik and Power BI is the associative engine. Qlik lets users select from any field and the entire data model responds. Power BI uses star schemas and slicers. The mental model is different, and trying to replicate associative behaviour in Power BI usually ends in pain. Most Qlik power users adjust within a few weeks, but the design needs to embrace Power BI's pattern rather than fight it.

A full ERP replacement is the right answer when the source system genuinely cannot hold the data you need for the business as it is today. When the system is unsupported and presents real security or compliance risk. When the cost of working around its limitations exceeds the cost of replacement. When a major business change (acquisition, divestment, fundamental restructure) requires a different operating model the existing system cannot support. These cases exist. They are the minority. Replacement is the right answer when modernisation cannot solve the problem, and that is rarer than vendor narratives suggest.

An SSRS report should become interactive instead when the original was paginated only because SSRS could not do interactive. Many tactical SSRS reports built years ago would have been dashboards if Power BI had existed at the time. The migration is the chance to redesign them for what users now expect: drill-through, slicers, dynamic filters. Most tactical SSRS reports become better when redesigned, not when ported.

An SSRS report should stay paginated in Power BI when the format is non-negotiable. Invoices, statements, packing slips, regulatory submissions, audit reports, and anything that prints. Pixel-perfect output is genuinely required and Power BI Paginated is built for it. The mistake is forcing paginated reports into interactive dashboards just because the migration is happening. Sometimes paper is the right answer.

The full Legacy ERP and Modern Analytics whitepaper is on hoptonanalytics.com under Resources. The whitepaper covers the migration failure data, the replace-versus-modernise framework, the historical data argument, the architecture, and the Reporting Modernisation Assessment. Email hello@hoptonanalytics.com to discuss your situation or to book the assessment.

You can see the full Qlik to Power BI migration playbook on hoptonanalytics.com under Resources. The deck covers what is distinctive about a Qlik migration, the common pitfalls, what success looks like, and the three-phase process. To discuss a specific situation, email hello@hoptonanalytics.com.

You can see the full SSRS to Power BI playbook on hoptonanalytics.com under Resources. The deck covers what is distinctive about an SSRS migration, the common pitfalls, what success looks like, and the three-phase process. To discuss a specific situation, email hello@hoptonanalytics.com.

Organisations are migrating from Qlik to Power BI for three reasons, in roughly this order. Cost, because per-user Qlik licensing rarely makes sense for mid-market when Power BI Pro comes bundled with most M365 plans. Capability, because Microsoft Fabric, Direct Lake, Copilot and the wider AI investment are now genuinely ahead of the Qlik roadmap. And control, because native integration with Entra ID, Purview and existing M365 governance is simpler than the third-party patchwork Qlik environments often become.

Organisations are migrating from SSRS to Power BI for three drivers. Risk, because SSRS sits on ageing infrastructure that is harder to support each year and has fewer specialists in the market. Modernisation, because Power BI Paginated and Fabric give the same operational reporting on a modern, cloud-ready platform. And consolidation, because most SSRS estates are full of duplicates and unused reports, and the migration is the chance to clear them out.

Organisations move from Cognos to Power BI for three reasons that come up most often: cost (Cognos licensing and the specialist administration it requires is expensive relative to Power BI, particularly for organisations already paying for Microsoft 365), skills availability (Cognos specialists are harder to find and more expensive to hire than the much larger Power BI and DAX talent pool), and user experience (business users generally find Power BI's self-service model more approachable than Cognos's more IT-centric authoring model).

Yes, meaningfully - Cognos Report Studio and Power BI Desktop are different enough tools that experienced Cognos authors need proper Power BI and DAX training rather than assuming their skills transfer directly. We build this training into every Cognos migration engagement.

Most Qlik extensions do not transfer directly to Power BI. Power BI custom visuals fill some of the same gaps but rarely the same one. The migration is a good moment to question whether the extension was earning its place. Most Qlik extensions added in the early years are no longer the best answer in either tool. If you genuinely need an equivalent, scope it as a separate workstream.

Some initial resistance from specialist Tableau users is common and understandable, particularly if they value specific visualisation techniques Power BI handles differently. Structured training focused on translating their existing analytical thinking into Power BI's equivalent capabilities, rather than assuming familiarity will transfer automatically, is the main way we address this.