Migrations - frequently asked questions

There are three hidden costs to plan for. First, the data layer rebuild, which is often larger than expected because QVDs hide complexity. Second, user retraining, which is more than a one-hour session for power users. Third, parallel running for two to three months while users transition. None of these is hidden if you plan for them. They are hidden if you assume Power BI is just a swap for Qlik.

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.

Hopton can help even if your spreadsheets pull data from several different systems already; this is in fact the more common case than a single-source spreadsheet, and it is exactly the kind of multi-system reconciliation work a proper semantic model is designed to solve better than a spreadsheet held together with manual copy-paste and VLOOKUPs.

Yes — Hopton can migrate from Looker to Power BI. Once the strategic decision to move has been made, Hopton runs it as a structured engagement: auditing the existing Looker dashboards and LookML models, rebuilding the semantic model natively in Power BI, recreating the report visuals, and running a short parallel-validation period before cutover. LookML does not convert automatically, so the architectural rebuild is the bulk of the work; the visual rebuild is comparatively quick. We use the same phased approach for the Tableau and Qlik migrations covered elsewhere in this FAQ library.

Tableau workbooks cannot be automatically converted to Power BI reports reliably, despite some third-party tools claiming to do this. Tableau and Power BI have fundamentally different underlying data models and calculation languages, and an automated conversion tends to produce something that opens in Power BI but is poorly structured, hard to maintain, and does not reflect Power BI best practice. We rebuild rather than attempt 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.

Report by report is almost always better. Group related reports into batches, migrate each batch, get user sign-off, then move to the next. Big-bang switches are higher risk and higher stress. The exception is when the underlying data layer needs a complete rebuild, in which case the data layer migration must complete before any reports go live. Even then, the report layer is incremental.

Yes - Fabric capacities can be paused when not in use and resized more flexibly than Premium capacities typically were, which is one of the more concrete cost-management advantages of the move, particularly for capacities that see uneven usage across the week or year.

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.

RDL files mostly convert to Power BI Paginated automatically, with care. The Power BI Report Builder accepts RDL files and most simple RDL files convert with minimal changes. The trouble starts with embedded VB.NET code, custom assemblies, subreports and complex datasets. Each needs separate handling. Allow time for testing rather than assuming the conversion is one-click.

No, user-level licensing (Power BI Pro or Premium Per User) is separate from capacity licensing and is unaffected by a Premium-to-Fabric capacity migration. This migration specifically concerns the shared capacity that hosts your workspaces, not individual user licences.

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.

You can license Power BI-only usage through Fabric F SKUs without adopting the other Fabric workloads at all - a Fabric capacity licenses Power BI Premium features whether or not you use Fabric's data engineering, warehouse, or real-time capabilities. The migration is a licensing and platform change more than an immediate requirement to adopt the wider Fabric feature set.

Ad hoc flexibility in the exact way Excel offers it does reduce for the governed, shared reports - that is largely the point, since uncontrolled ad hoc changes are what created the version-control problem in the first place. Power BI's own self-service features (Analyze in Excel, Power BI Desktop for individual analysis, DAX for new measures) provide a different, more controlled kind of flexibility on top of the trusted model.

Power BI alone is sufficient for the great majority of spreadsheet migrations. Fabric becomes relevant where the underlying data volumes are large, where multiple messy source systems need proper data engineering before they can feed a semantic model reliably, or where the ambition extends well beyond replacing the spreadsheet into a wider data platform.

Whether you need to migrate the data warehouse as well as the reporting layer depends on where your data currently sits. If Cognos reports query a well-structured existing data warehouse, that warehouse can often remain as the Power BI data source with limited change. If Cognos itself has been doing significant data preparation work, that logic typically needs to move into Power Query or a Microsoft Fabric pipeline as part of the migration.

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.

We deliver both Power BI on Fabric and Power BI Premium without Fabric. If your destination is Power BI Premium without Fabric, that is a valid and supported path. The decision depends on your data volumes, your wider Microsoft estate, and your appetite for sitting on the modern stack. The audit covers this question explicitly: not every Qlik migration ends with Fabric, and we will tell you when it does not need to.

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.

Yes - the capacity sizing and cost analysis is usually the more valuable part of this engagement, since the technical reassignment itself is comparatively quick. We review your current Premium capacity utilisation, model the appropriate Fabric SKU size, and give you a clear cost comparison before any switch happens.

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.

This kind of migration is one of the most common starting points for new Hopton engagements. A large proportion of mid-market businesses we work with are moving off Excel-based reporting as their first step into a proper Power BI estate, so this is core, well-practised work rather than a peripheral service.

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.

No — moving to Power BI does not mean giving up Excel entirely, and we would not recommend that framing. Power BI becomes the governed reporting layer; Excel remains genuinely useful for ad hoc analysis, one-off modelling, and scenarios that do not need to be a permanent, shared report. Power BI has native Excel connectivity (Analyze in Excel) specifically so people can keep working in Excel against a trusted, governed dataset rather than a disconnected copy.

Yes — your Power BI Premium renewal date matters for planning this migration; it is usually the natural trigger point. Migrating around your existing renewal minimises the risk of running two capacities simultaneously and lets you align the new Fabric capacity commitment with your existing budgeting cycle.

No — your existing Power BI content does not need to be rebuilt to move to Fabric capacity. Existing datasets, reports, and dashboards continue to work once reassigned to a Fabric capacity; this is fundamentally a capacity and licensing change, not a content migration. Where it gets more involved is if you also want to take advantage of Fabric's other workloads, which is a separate decision from the capacity licensing move itself.

No — the assessment does not lock you into using Hopton for the build. The assessment is independent. The output is a written document you can take to anyone, including in-house teams or other consultancies. Several clients have used the assessment to inform a procurement process that we did not win. We are comfortable with that because the assessment work itself is valuable regardless of who does the build. Recommending the path that is right for the client, even if we do not deliver it, builds the trust that earns subsequent work.

Workspace reassignment is designed to be low-disruption, but we schedule it outside peak reporting hours and validate that refreshes, row-level security, and performance are behaving as expected immediately after the switch, rather than assuming a purely administrative change carries zero risk.

The source system does not have to support modern APIs; it helps but is not strictly required. Older systems can be extracted via direct database access, scheduled exports, or custom integration patterns. The work is more involved but it is not a blocker. We have modernised analytics layers on top of source systems older than thirty years. The technique adjusts. The outcome is the same: a modern analytics layer that delivers the visible value without touching the source system.

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.

Layout and interactivity change, generally for the better - Power BI supports filtering, drill-down, and cross-report navigation that a static spreadsheet cannot. We aim to preserve the metrics and structure people already trust and are used to working with, while improving how they are presented and interacted with.

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.

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.

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.

Email hello@hoptonanalytics.com with a short description of your current spreadsheet-based reporting and the specific pain points (version control, a single point of failure, manual effort, trust in the numbers). The first conversation is free and exploratory, and typically leads to a scoped Establish phase.

Email hello@hoptonanalytics.com with details of your current Premium capacity SKU and roughly how many workspaces and reports it hosts. We will review your utilisation, model the right Fabric capacity size, and give you a clear cost and migration plan before you commit to anything.

During a migration, we handle rarely-run reports that still matter by migrating them, but documenting what they are for. Annual audit reports, regulatory reports and similar may run twice a year and matter both times. Execution frequency alone is the wrong test. Combine it with named ownership and sensible judgement. The audit phase is where this gets sorted, not the build.

We know what size Fabric capacity we actually need by analysing your current Premium capacity's utilisation - CPU and memory consumption patterns, peak usage times, and how close to capacity limits you currently run - and mapping that onto the nearest appropriate F SKU, rather than assuming a like-for-like size match is automatically correct given the different underlying compute model.

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.

You know the migration is done when three things have happened. Every report on the active list is live in Power BI, owned, and signed off. Power users are productive in Power BI on their own work. Qlik servers are off, licences cancelled. If any one of those three is missing, the migration is not done. The third one is the one most projects skip if they are not careful.

Three quick tests tell you whether the problem is your source system or your reporting layer. First, does the source system have the data you need, however awkward to get to? If yes, the problem is the analytics layer. Second, are most of the complaints about reports, dashboards, and analyses, or about transactional behaviour? If reports, the problem is analytics. Third, what would change in the business if the same data appeared cleanly in a modern reporting layer? If the answer is 'a lot', you do not need a new core system. The Reporting Modernisation Assessment runs these tests properly.

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 validate that performance is at least as good after moving to Fabric capacity by comparing report load times, refresh durations, and capacity utilisation metrics before and after the move for a representative sample of your most business-critical reports, rather than assuming a comparable SKU size automatically delivers comparable performance.

Cognos prompts and macros are generally replaced with Power BI's native filtering, slicers, and "what-if" parameters, which achieve similar interactive outcomes through different mechanisms. Some highly bespoke macro-driven logic needs custom DAX or Power Query work to reproduce properly rather than a direct equivalent.

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.

We migrate logic out of a complex, years-old spreadsheet by treating the spreadsheet as a specification to be understood and validated, not code to be copied. We work through the existing calculations with the people who use and, where possible, built the spreadsheet, documenting the actual business rules (including workarounds and exceptions) before rebuilding them properly as DAX measures and Power Query steps in Power BI.

We scope an Excel migration before committing to a full project through our standard Establish phase: reviewing your current spreadsheets, understanding the business logic and who depends on it, and agreeing a clear list of what "done" looks like before any rebuild work starts. This produces a written plan and cost estimate you can act on even if you decide not to proceed with the Build phase immediately.

We validate that the new Power BI report matches the old spreadsheet by running both in parallel for at least one full reporting cycle and reconciling every material figure line by line before the spreadsheet is retired. Differences get investigated individually - some will be genuine spreadsheet errors being corrected, and we make sure the client agrees with and understands every one of those before go-live.

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.

Section Access logic gets re-implemented as Row-Level Security in Power BI. The mechanism is different but the intent is usually the same. The harder part is that Section Access often hides business rules that nobody has written down. Surface those rules first, document them, get sign-off, then implement RLS to match. Skipping the documentation step causes most RLS bugs we see.

Synapse-to-Fabric migration works through a defined migration path that Microsoft has documented and tooled. Synapse Workspaces and Pipelines map to Fabric workspaces and Fabric Data Factory. Synapse Dedicated SQL Pools map to Fabric Data Warehouse. Synapse Spark Pools map to Fabric Data Engineering. The migration is incremental: components can be migrated one at a time as the right opportunities arise, rather than as a single forklift project.

A Fabric modernisation engagement progresses into a build phase after the readiness assessment: the build phase usually runs three to six months. We extract source data into Fabric, build certified semantic models, deliver the priority reports, and establish governance. The work is incremental: visible value within the first eight to twelve weeks, full delivery within six months. Continuity is the optional ongoing engagement that maintains and extends the modernised platform after launch.

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 single, well-defined core reporting spreadsheet typically takes four to eight weeks from discovery through to validated go-live. Migrating an entire suite of interconnected spreadsheets across finance, sales, and operations is a larger programme, usually run in phases rather than as one migration.

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.

Forty to sixty per cent on licence cost is typical for mid-market organisations already on M365. Power BI Pro is bundled with most plans. Premium Per User and Premium Capacity scale up from there. The exact saving depends on your current Qlik footprint and your M365 estate. The gap usually pays for the migration project inside the first eighteen months.

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.

Gartner data puts ERP project failure rates at 55 to 75 per cent. Panorama Consulting reports an average cost overrun of 189 per cent in 2025. McKinsey reports digital transformation failure rates above 70 per cent. The pattern is consistent across industry analysts and across decades. Migration is genuinely hard, more often than vendor narratives suggest. The likelihood of going significantly over budget, missing milestones, or delivering less than promised is higher than most boards assume going in.

Workspaces are typically split by function rather than left as one large shared space: a development workspace, a test workspace, and a production workspace at minimum, so a change can be validated before it reaches anything a business user sees, with promotion between them controlled rather than ad hoc. Within production, workspaces are usually split further by domain or department where access genuinely needs to differ, since a workspace is the unit that workspace roles apply to. On residency, Fabric capacity is provisioned in a specific Azure region, and that determines where the underlying data physically sits; for UK organisations this is normally a UK region for data residency and compliance reasons, and it is one of the decisions made explicitly during the discovery week of a migration, not left as a default. Getting workspace structure right before migrating matters more than it looks: restructuring workspaces after go-live, once reports and permissions are already built on top of them, is genuinely disruptive work, so it is one of the few decisions we insist on making correctly the first time.

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.

We design migrations specifically to avoid this: the old spreadsheet process keeps running unchanged until the new Power BI reports are validated and formally signed off, and only then is the spreadsheet retired. Nobody should be without a working report at any point in the transition.

Power BI's learning curve is generally considered gentler for business users coming from an Excel background, partly because DAX (Power BI's calculation language) has more conceptual overlap with Excel formulas than Tableau's calculation approach. Tableau's flexibility can be a double-edged sword for self-service: powerful in trained hands, more of a learning curve for a first-time business user.

The main risk is less about a hard cut-off and more about missing the chance to right-size cost and explore Fabric's additional capability at a natural decision point. We would rather clients make this move deliberately, on their own timeline, with proper sizing analysis, than rush it reactively once a support deadline is imminent.

There is a risk of double-paying during the transition only if the migration is poorly timed against your existing Premium capacity renewal or commitment period. We plan the cutover to align with your existing licensing commitments where possible, to avoid running (and paying for) both a Premium and a Fabric capacity longer than genuinely necessary for validation.

A Qlik to Power BI migration is almost always a redesign rather than a like-for-like rebuild. Qlik apps were built for the associative engine. Replicating them visually in Power BI wastes the chance to simplify, and often produces something less useful than the original. The migration is the moment to ask which reports still serve a purpose, which can be combined, and which can quietly be retired. Most clients end up with fewer Power BI reports than Qlik apps, doing more.

This advice could look biased because Hopton sells analytics rather than ERP migrations - we benefit when clients pick the analytics-first path. We also benefit reputationally when clients succeed, and ERP migrations frequently fail. The argument in the whitepaper rests on industry data (Gartner, McKinsey, Panorama Consulting) showing high failure rates for replacements, and on our experience that most of the value organisations are chasing through migrations is achievable through modernisation. We are happy to put the whitepaper in front of any organisation considering either path and let the framework decide.

The real business case is trust and time, not visual polish. Trust, because a governed semantic model with one definition of each metric stops the "whose number is right" arguments that eat up meeting time. Time, because manually rebuilding and re-checking spreadsheets every reporting cycle is expensive labour that automated refresh removes almost entirely.

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.

Whether to use this migration to adopt other Fabric workloads depends entirely on whether you have a genuine need building elsewhere in your data estate - a data engineering bottleneck, a desire for real-time analytics, or a data science initiative that would benefit from Fabric's other workloads. We would not recommend adopting the wider Fabric platform purely because the licensing migration happens to be a convenient moment; the decision should be driven by an actual business need.

Studies show 50 to 70 per cent of CRM projects produce shareholder value loss. The pattern is similar to ERP: ambitious replacement promises, scope expansion mid-project, integration difficulties, change management gaps, and outcomes that fall short of business case projections. CRM migrations are often easier than ERP technically (smaller estates, fewer dependencies) but no easier in terms of organisational disruption.

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.

Modernisation typically uses Microsoft Fabric with a Bronze, Silver, Gold pattern. Bronze captures raw data from the source system. Silver cleans and structures it. Gold contains business-ready facts and dimensions for reporting. Power BI semantic models point at Gold. The architecture supports current reporting needs and creates the foundation for forecasting, machine learning, and AI work later. The same architecture works whether the source system is BC, NAV, AX, GP, Sage, custom, or anything else.

The biggest risks of staying on Excel for core reporting are version control failures (someone reporting from an out-of-date copy), single points of failure (only one person can maintain the logic), no audit trail on changes, no real access control (anyone with the file can see and edit everything), and silent errors that are extremely difficult to catch in a workbook with thousands of formulas, some copied and subtly modified over years.

Kept historical data can deliver revenue forecasting that learns from cycles you have already lived through. Churn prediction that knows which customer behaviours preceded historical churn. Demand planning that adjusts for seasonal patterns specific to your business. RFM segmentation grounded on the actual customer base, not industry benchmarks. Anomaly detection that recognises what normal looks like in your data. Each of these works better with five years of history than with eighteen months. Replacement projects often cut history at the migration boundary.

With your existing QVDs, audit them, then plan a proper rebuild. Years of layered QVDs and hidden joins usually contain business rules nobody has documented. Lifting the QVDs into a Power BI dataflow is rarely the right answer. Most projects rebuild the data layer in Fabric using a Bronze, Silver, Gold pattern, with the QVDs as reference rather than source. The ETL is the project, not an aside.

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.

A typical migration project runs in three phases, end to end. Discover, where we audit the estate and produce the migration plan, usually two to four weeks. Migrate, where we rebuild the data layer and the reports, typically two to four months. Embed, where we train users and decommission Qlik, usually four to six weeks. Total project duration of three to six months for most mid-market estates.

Modernising the analytics layer involves extracting data from the existing source system into a modern data layer (typically Microsoft Fabric or a similar platform). Building certified semantic models on top. Producing the reports and dashboards the business has been asking for. Establishing governance and adoption practices. The work happens in parallel with the existing system, not as a replacement. The source system continues to run unchanged. The analytics layer becomes a separate, modern, governed environment that delivers the visible value.

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.

The analytics readiness assessment looks at your source data (what is in there, how clean, how accessible). Reporting requirements (what reports the business needs, what is currently producing them). Pain point analysis (where the frustration is concentrated). Modernisation feasibility (whether the analytics layer can deliver what the business is asking for without replacement). Cost and timeline modelling for both paths. The output is genuinely diagnostic. We have written assessments recommending replacement. We have also written many recommending modernisation. The framework decides.

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.

Cost doubles, user confusion grows, and over time both platforms get half-maintained. We see this often in projects without a hard decommission date. The Qlik servers stay on because nobody wants to be the one to turn them off, and Power BI never quite reaches full adoption because users always have the fallback. Set the date, hold to it, and decommission when planned.

Premium-specific features like paginated reports and dataflows continue to work under Fabric capacity, which supports the full set of features Premium capacity supported, alongside the additional Fabric workloads. There is no feature loss in this direction; the migration is additive rather than a downgrade.

Historical data that only exists in old spreadsheet versions is assessed case by case. Where historical figures are needed for trend reporting, we migrate them into the underlying data model so history is preserved and queryable going forward. Old spreadsheet versions themselves are typically archived rather than deleted, in case they are needed for reference.

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.

If no one will sign off on retiring a report during migration, then it stays. The migration is not the moment to force unilateral retirement decisions. Instead, document the lack of an owner and put the report on a watch list. If no one defends it within six months of the migration completing, it can come up for retirement again. The honest position is that some unused reports will survive every migration. That is fine if it is the minority.

Nobody left understanding how your old spreadsheet system works happens more often than clients expect, and it is itself a strong argument for migrating. We reverse-engineer the logic from the spreadsheet's formulas and outputs, cross-checking against known correct historical figures, and flag anywhere the original logic is ambiguous or looks like it may already be wrong.

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.

Modernisation does not fix transactional behaviour problems in the source system. If the issue is that order entry takes too long, or that invoicing has limitations, modernisation cannot help. Those problems live in the system itself. The framework is honest about this: when the diagnosis is genuinely a system problem, modernisation is not the answer. The framework is for the much larger group of cases where the diagnosis was wrong.

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.

Migrating one critical report rather than your whole suite is a common and sensible starting point. We regularly run single-report migrations as a first, lower-risk engagement, which also lets a client see how we work before committing to a larger reporting transformation.

Migrating a workspace from Premium to Fabric capacity mainly involves reassigning the affected workspaces from the Premium capacity to a newly provisioned Fabric capacity through the Power BI admin portal. For a Power BI-only migration with no wider Fabric adoption, this is a comparatively contained technical exercise; the larger work is usually the capacity sizing and cost analysis that should happen before the switch, not the switch itself.

The Reporting Modernisation Assessment is a four-week fixed-price engagement that diagnoses whether your reporting frustration is a system problem or an analytics layer problem. We work with your team to understand the symptoms, audit the source data, and identify whether modernisation would deliver the value you are seeking. Output is a written assessment with a clear recommendation: modernise, replace, or a hybrid path. The assessment is independent of any subsequent build engagement.

A typical ERP migration costs, for mid-market organisations, usually £500,000 to £3 million in software, services, and internal resource. Panorama's 189 per cent overrun average suggests the real cost is closer to £1.4 million to £8.6 million by completion. Add the eighteen-to-thirty-month timeline, the disruption to operations during cutover, and the analytics rebuild that often follows, and the true total is meaningfully higher than the project sponsor signed off. The opportunity cost of internal time is rarely accounted for at all.

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.

Most organisations considering a core system replacement (ERP migration, CRM replacement, similar) are doing so because the reporting and analytics on top of the existing system are inadequate. In most cases, the analytics layer can be modernised without touching the core system, delivering the visible value the migration was supposed to produce, at a fraction of the cost and risk. Four out of five organisations who think they need to replace would get most of what they want by modernising analytics.

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 considering the move, not yet committed is a short discovery conversation reviewing your current Tableau usage and cost, and an honest assessment of whether migration makes sense for your specific situation. We are comfortable telling a prospective client that staying on Tableau is the right call where that is genuinely true.

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.

A Premium P SKU and a Fabric F SKU are structured similarly - both are capacity-based licences sized by compute units rather than per user - but F SKUs unlock the full Fabric workload set (lakehouse, warehouse, pipelines, real-time intelligence, data science) in addition to Power BI Premium features, and F SKUs support pay-as-you-go and pause/resume billing models that P SKUs did not offer in the same way.

The single most common trigger for an Excel to Power BI migration is a key person leaving, or nearly leaving, who is the only one who understands how the master reporting spreadsheet actually works. This "bus factor" problem - where institutional knowledge exists in one person's head and one file's formulas - is the most frequent reason mid-market businesses finally prioritise the move.

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.

Modernising the analytics layer is enough when the source data is fundamentally there, however awkward to extract. When the complaints centre on reporting, analytics, and dashboards. When the cost of replacement would exceed the value the business actually expects to receive. When the change appetite of the organisation is limited. In our experience, this describes four out of five organisations actively considering replacement. The modernisation approach delivers most of the visible value at a fraction of the cost and risk.

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.

You should migrate from Synapse to Fabric when the right opportunity arises: a major refresh, a significant new requirement, an end-of-contract renewal moment. Forced migration without a triggering event rarely produces good outcomes. Opportunistic migration aligned with natural business cycles produces clean results. For Synapse customers running stable production workloads, the migration can wait until the moment is right.

You should start planning a move from Premium to Fabric capacity reasonably proactively, rather than waiting until forced. Microsoft's own guidance and roadmap communications should be checked directly for the latest position on Premium capacity support timelines, since licensing transition dates are the kind of detail that changes and should be confirmed with Microsoft or your licensing partner rather than assumed from older guidance.

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.

Once you are not manually pulling data into Excel, it comes directly from source systems — your ERP, CRM, or finance system — connected through Power Query or, for larger and more complex estates, through Microsoft Fabric pipelines. This is usually the single biggest quality improvement in the migration: removing the manual copy-paste or manual export step that was the main source of both errors and delay in the old process.

Power BI, decisively, because it is built by the same vendor as that ecosystem. Native Excel connectivity, direct integration with Dynamics 365 and Business Central, embedding inside Teams, and shared Azure Active Directory security are all first-party in Power BI. Tableau can connect to these systems too, but through third-party or bridging connections rather than native integration.

Ideally, the reports are not maintained exclusively by the same person after the move. Part of the point of the migration is to move maintenance from one person's personal spreadsheet skill to a documented, centrally owned semantic model that more than one person on your team (or Hopton, under a support arrangement) can maintain and extend.

Migration failure rates are high for several reasons that compound. The full scope is rarely understood until the project is underway. Existing data is messier than the discovery phase suggested. Customisations on the old system have to be rebuilt or worked around. Users resist the change because it disrupts their work. Vendor estimates assume best-case timelines. Internal sponsorship weakens after eighteen months. The single biggest reason is that organisations underestimate the analytics layer rebuild that comes after the core migration finishes.

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 confuse a reporting problem with a system problem because the symptoms feel like a system problem. Reports are slow or unreliable. Numbers do not match across the business. Finance spends a week doing what should take a day. The natural conclusion is that the underlying system is the issue. In a small minority of cases that conclusion is correct. In the majority, the underlying system is fine and the analytics on top of it are the problem. Replacing the core system to fix the reporting layer is a forty-week solution to a four-week problem.

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).

Historical data is important because most organisations underestimate the value of the years of historical transaction data sitting in their existing system. When a replacement happens, this data is often left behind or transferred in a degraded form. Historical data is the asset that makes machine learning, forecasting, and pattern detection possible. Cohort analysis needs years of customer history. Demand forecasting needs years of sales history. Replacement projects regularly throw this asset away because the migration plan cannot afford to bring it across cleanly.

Hopton is a strong fit for modernisation work because we have done many of these projects across mid-market clients on BC, NAV, AX, GP, Sage, and custom systems. The architecture pattern (Bronze/Silver/Gold on Fabric) is the same across source systems. The extraction patterns are different per system, and we have a working library of patterns for the common ones. This is mostly delivery experience, not theory. The whitepaper covers the methodology. The engagements deliver it.

We have done many SSRS migrations and we know which questions to ask. SSRS estates have a lot of accumulated history, and the audit phase rewards experience. We are also not married to a particular outcome: if a report needs to stay paginated, we say so. If a report should be retired, we say that too. Some consultancies push interactive everywhere because it sounds modern. We do not.

Work with Hopton rather than doing this in-house mostly because we have done it many times and your team has not. The audit alone surfaces things in-house teams typically miss because they are too close to the existing Qlik environment. The build phase is technically achievable in-house but the project management of running parallel platforms while maintaining day-to-day reporting tends to be where in-house projects struggle. Some clients use us for the audit only and run the build themselves, and that is a sensible model too.

A business moves from Excel to Power BI because Excel rarely “already works” as well as it appears to. Excel-based reporting typically means several versions of the same report circulating by email, numbers that quietly diverge between departments because someone's copy has a manual adjustment no one else knows about, and a small number of people who understand the spreadsheet logic well enough to maintain it. Power BI replaces manually maintained, single-owner spreadsheets with a governed, automatically refreshing, centrally maintained model that many people can safely consume.

Yes — Hopton will advise on whether you should adopt other Fabric workloads at the same time, honestly and case by case. Where we see a genuine data engineering, real-time analytics, or data science need elsewhere in your estate, we will say so. Where we do not see that need, we will say that too, rather than using the licensing migration as a reason to sell a wider platform adoption you do not yet need.

Power BI Paginated works on Fabric capacity, and increasingly that is the right place to put it. Power BI Paginated runs on Premium and on Fabric. Sizing matters: paginated workloads behave differently from interactive reports and need capacity allowance. The audit covers this. Most mid-market estates fit comfortably on the Fabric capacity tier they already need for interactive reporting, but it is worth checking explicitly.

Whether moving from Premium to Fabric capacity costs more or less depends on your current SKU size and usage pattern. The unit economics between equivalent P and F SKU sizes are broadly comparable, but the ability to pause capacity outside business hours, and the more granular SKU sizing options, mean many organisations can genuinely reduce cost by right-sizing more precisely than Premium's licensing model allowed.

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.

The business logic is not lost, but it is rebuilt, not copied. Excel formulas embedded across cells become DAX measures and Power Query transformations in a proper semantic model. This is deliberate: it is the opportunity to fix logic that has quietly drifted or been worked around in the spreadsheet over the years, rather than faithfully reproducing errors that have accumulated.

Most finance teams adapt quickly, particularly with Power BI's Analyze in Excel feature, which lets them keep working inside the Excel interface they know while querying the governed model underneath rather than a static export. We also run structured training as part of every migration, aimed specifically at the people who will actually use the new reports day to day.