Migrations Planning & Cost - FAQs

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

To get started on a Premium to Fabric capacity migration, 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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 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 you leave both platforms running, 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.