Migrations Planning & Cost - FAQs
107 questions answered by the Hopton Analytics team.
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.
Yes, NetSuite data can be combined with other systems in Power BI by landing each system in the same lakehouse, conforming shared keys such as customer and item in the silver layer, and modelling them into one star schema, so NetSuite finance sits beside CRM, e-commerce or warehouse data with measures defined once. That is the main reason to build a platform rather than connect Power BI directly to NetSuite. What is Microsoft Fabric? explains the platform we use.
Yes, a BI migration can and usually should be done in stages by business area, finance first because month end is the acceptance test, then sales, operations and the rest, each on the same shared model, with the old platform retired area by area. Large estates with hundreds of reports are only tractable this way, and it keeps reporting running because no area is without a working platform at any point. Our data platform and warehouse page describes how we phase it.
Yes, the old reports keep running during a migration: the existing platform stays live until the first month end has been closed on Power BI with the numbers reconciled, and the old licences are retired on a date agreed with their owners. See how you keep reporting running.
You can migrate to Power BI report by report, and that is almost always better than a big-bang switch. 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. Our case studies show how similar migrations have been delivered.
Yes, you can migrate Azure Synapse to Microsoft Fabric without downtime by moving component by component: Synapse pipelines to Fabric Data Factory, dedicated SQL pools to the Fabric warehouse or lakehouse, Spark pools to Fabric data engineering, one source at a time, with Synapse kept live and reports repointed only once their model has been reconciled on Fabric. See what Microsoft Fabric replaces.
Yes, you can use the NetSuite REST API for Power BI reporting by running SuiteQL queries from a Fabric pipeline or notebook, paging through results, filtering on last-modified timestamps for incremental loads and landing the data in a lakehouse that Power BI reads. It needs no SuiteAnalytics Connect licence but does need engineering for token authentication, paging and NetSuite's concurrency limits. The layered lakehouse explained covers where the data lands.
BI migration conversion tools move report layouts reasonably well, calculations poorly and data models not at all, so they produce Power BI reports that look like the old ones but run slowly and disagree at the edges, and the estate then needs a second project to rebuild the model. They are useful for simple standalone reports or to bridge a hard deadline, and a poor foundation for a platform. How much does it cost to migrate from Tableau or Qlik? explains why rebuild costs less by year end.
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.
You do not have to adopt the other Fabric workloads if you move to Fabric capacity and only use Power BI: you can license Power BI-only usage through Fabric F SKUs without adopting them at all, and 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.
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 do not only deliver Power BI on Fabric: 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 does specialise in this kind of migration rather than treating it as a side offering: it 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.
No, Power BI has no built-in NetSuite connector. You connect through SuiteAnalytics Connect's ODBC driver, the NetSuite REST API, exported saved searches or a third-party connector product, and for anything beyond a proof of concept the extraction should run in a pipeline that lands data in a lakehouse rather than inside each Power BI report. How to automate ETL for Power BI explains that pattern.
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. Our case studies show how similar migrations have been delivered.
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.
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 whether the problem is your source system or your reporting layer by running three quick tests. 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.
You avoid losing reports and logic during a BI migration by taking a full inventory from usage logs and owners before anything is built, extracting every calculated field, load script rule and security rule into a definitions document, keeping the old platform running read-only until the first month end closes on the new one, and reconciling each rebuilt measure to its old value on a known period. Nothing is retired until it is on a list with an owner's agreement. Testing a data pipeline covers the reconciliation checks.
You avoid losing reports and logic during a BI migration by building an inventory in the first week that lists every report, its source, its owner, when it was last opened and the calculations it depends on, written in the words of the people who built it, and by retiring or rebuilding nothing that is not on the list. See how do you migrate from Tableau to Power BI?.
You extract data from NetSuite into Power BI through SuiteAnalytics Connect (Oracle's licensed ODBC and JDBC driver), the REST web services API with SuiteQL queries, saved searches scheduled to export files, or a third-party connector that wraps one of those, because Power BI has no built-in NetSuite connector. The lasting approach lands the data incrementally in a lakehouse, models it into a star schema and has Power BI read the model. Our NetSuite reporting case study shows the result.
You handle NetSuite subsidiaries in Power BI by keeping the subsidiary key on every transaction in the model, building a subsidiary dimension with the group hierarchy, translating currency at the rates NetSuite used for consolidation rather than a spot rate, and eliminating intercompany transactions on a flagged basis, so that subsidiary and group views reconcile. Consolidating multiple Business Central companies applies the same principles to another ERP.
You keep reporting running during a BI migration by running the old and new platforms in parallel through at least one month end, retiring the old tool on a date agreed with its owners only after the numbers have been reconciled and signed off, and timing the migration to the old tool's renewal date so the overlap is planned rather than drifting. See how long a BI migration takes.
You keep reporting running during a data platform migration by leaving the old platform live throughout, repointing reports one at a time once their semantic model has been reconciled on the new platform, retiring no source on the old platform until a month end has closed on the new one, and putting a decommission date in the plan so the licence overlap is bounded. See how you keep reporting running.
You keep reporting running during an ERP migration by extracting history from the old system before it is decommissioned, building one model that holds old-system history and new-system data with conformed accounts and dimensions, connecting the new ERP's test company before go-live, and running old and new reports side by side until the first month end closes on the new system. Starting the reporting workstream at go-live is the usual cause of a quarter spent in Excel. Migrating reporting from NAV to Business Central shows the pattern.
You make sure the numbers match after a BI migration by reconciling every measure to the old tool on a known period before anyone uses it, explaining each difference as a definition change or a timing difference, having finance sign the agreed definition, and closing one month end on both platforms in parallel; most differences turn out to be the old tool being wrong. See testing a data pipeline.
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.
A data platform migration is planned in a four-week phase that produces an inventory of every pipeline, table, model and report with owners and last use, a target architecture on the new platform, a source-by-source sequence with the ERP usually first, and a reconciliation plan that says how each table and measure will be proven to match; unused pipelines and reports found by the inventory are retired rather than moved. See the layered lakehouse explained.
A BI migration project for a mid-market business takes about four months: a four-week Establish phase to inventory reports, extract business rules and agree the target model, then ten to sixteen weeks to build the model and rebuild the used reports, with one to three months of parallel running overlapping the end. A small single-source estate takes six to eight weeks; a large estate with hundreds of reports is a six to twelve month programme migrated by business area. Our free audit gives a timeline for a specific estate.
A data platform migration takes four weeks of planning and twelve to twenty weeks of migration for a mid-market estate with an ERP and three or four other systems, depending on how many pipelines are rebuilt rather than repointed and how much transformation logic was buried in views and stored procedures, finishing with a month end closed on the new platform and decommissioning a month later. See how long a Fabric implementation takes.
It takes about a week to get a first NetSuite report into Power BI from a scheduled saved search, and typically six to twelve weeks to build a lasting platform with incremental extraction through SuiteAnalytics Connect or the REST API, a modelled star schema and the core finance, sales and inventory reports, depending on subsidiaries and custom records. Our free audit scopes it for a specific estate.
You should run old and new BI platforms in parallel for one to three months, long enough to close one month end on the new platform with the old one open for reconciliation, with the old platform read-only from the start of the overlap and a retirement date agreed in the Establish phase. Parallel running that stretches beyond three months usually means the retirement date was never really agreed. Should you rebuild or lift and shift? covers the decisions made before the overlap.
Only the reports that are actually used should be migrated in a BI migration, which usage logs usually show is a minority of the estate: typically a few dozen reports that finance, sales or operations would miss within a week. The rest are retired with their owners' agreement or rebuilt by the owners themselves once the shared model exists. Fewer dashboards, more decisions sets out the test for keeping a report.
A Power BI migration costs a fixed-price build for the model rebuild and report recreation plus Power BI Pro at £10.80 per user per month, against Tableau Cloud from $75 per creator and Qlik's per-user pricing; most mid-market migrations pay back within two years from the licence saving alone. See the cost breakdown.
ERP migrations actually fail more often than not: 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. Our case studies show how similar migrations have been delivered.
CRM migrations are risky: 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. Our case studies show how similar migrations have been delivered.
Fabric workspaces should typically be structured by function during a migration, 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.
You migrate a data platform storage first, copying history into OneLake and reconciling it, then one source at a time through its pipeline, tables, transformations and reconciliation, then the semantic models over that source onto Direct Lake, then the reports, with each source completing all four steps before the next starts so the old platform keeps serving whatever has not moved. The order is by dependency and value: ERP, then CRM, then the rest. See Azure Data Factory vs Fabric Data Factory.
Yes, Microsoft funding is often available for a Fabric migration, usually through programmes that a Microsoft partner applies for on your behalf. The funding typically contributes to assessment and migration work, with the amount tied to the Azure and Fabric consumption the project is expected to generate. Microsoft also publishes free migration kits for Synapse, Azure Data Factory and SQL modernisation, which shorten the assessment phase. Programme names, ratios and thresholds change with Microsoft's financial year, and funding is generally allocated first come, first served. Raise it early, before the budget is set, not after. Funding should lower the cost of the right project, not decide what the project is. As a Microsoft Solutions Partner we check eligibility as part of scoping any migration. Our Synapse to Fabric migration guide explains the work involved, and you can contact us to check what might apply to you.
A data platform migration carries the same seven risks as a BI tool migration plus two more: the pipelines that fed the old warehouse must be rebuilt or repointed, and historical data must move with its grain intact, so it is sequenced component by component with parallel running rather than as a single cut-over. See what is a data platform migration and how is it planned?.
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.
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.
SQL Server 2016 reached the end of extended support on 14 July 2026, and SQL Server 2017 follows on 12 October 2027. After those dates there are no security updates without paid Extended Security Updates. There are four realistic options. You can upgrade in place to a supported SQL Server version. You can move the databases to Azure SQL Managed Instance, which is the closest like-for-like move. You can move to Azure SQL Database Hyperscale for growth and scale. Or, where the database mainly feeds reporting, you can move the analytical workload into Microsoft Fabric and leave the operational database to its application. The right choice depends on what the database actually does. Many reporting databases are really a warehouse that was never named one. Our guide to Fabric versus legacy Azure and our data platform and warehouse page cover the analytical route.
Reporting should be migrated alongside the Business Central implementation, starting with the report inventory and the NAV history extraction while the NAV server is still running, so that the new model is reading the Business Central test company before go-live and the first month end can be closed on both. Starting reporting at go-live is the most common cause of a finance team going back to Excel for a quarter. How long does a BI migration take? sets out the timeline.
No, you should not migrate every report to the new BI tool: migrate the reports opened in the last ninety days by someone who makes a decision with them, usually around a fifth of the estate, and retire the rest with their owner's agreement, because recreating fifty reports with fifty copies of the data recreates the old estate's problems in the new tool. See how do you turn dashboards into decisions?.
You should rebuild the data model once and then rebuild the reports people actually use on top of it, retiring the rest, because the value of a report is in its model and definitions rather than its layout and the old model is usually the source of the problems that prompted the migration. Lift and shift is fine only for simple standalone reports, reports with a short remaining life, or critical reports converted to meet a hard deadline while the rebuild follows. Qlik to Power BI: lessons learned shows why.
You should rebuild the data model and migrate only the reports people use rather than lift and shift, because Tableau, Qlik and Excel embed their logic in each workbook and copying them reproduces every inconsistency; rebuilding once on a semantic model is usually faster than converting every report. See rebuild or lift and shift.
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.
ERP reporting 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 risks of migrating from one BI tool to another are losing business rules buried in undocumented calculations, carrying wrong rules across unchallenged, converted reports that run slowly and disagree, a gap in trust while both platforms show different numbers, and the long tail of one-off reports consuming the budget. They are managed by documenting every rule first, reconciling measures on a known period, parallel running to a month end, and retiring reports deliberately. How long does a BI migration take? covers the safeguards.
The risks of migrating from one BI tool to another are numbers that stop matching between old and new, logic that only existed inside a workbook being lost, a period with no trusted reports, old and new licences overlapping for longer than planned, dependence on the one person who built the old estate, recreating the old estate's bad habits in the new tool, and treating go-live rather than the first month end as the finish. Each has a known control. Our Power BI page describes how we run migrations.
The risks specific to a data platform migration, beyond the seven of any BI migration, are pipelines that fed the old warehouse failing to be rebuilt or repointed correctly, and historical data arriving incomplete or at the wrong grain; both are controlled by migrating storage first with row-level reconciliation and by moving one source at a time with the old platform still live. See the risks of migrating between BI tools.
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 data platform migration costs a fixed-price planning phase and a migration priced by source, and after it the platform licence is a Fabric capacity from £138 a month reserved for an F2 to £4,404 for an F64 with free Power BI viewing, which usually replaces separate Synapse, Data Factory and Power BI Premium bills. See how much Microsoft Fabric costs.
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. Our case studies show how similar migrations have been delivered.
The cost of a BI migration is driven by the state of the data model (an existing warehouse star schema is weeks, workbook-level blends are the bulk of the project), the volume and complexity of calculations that must be re-expressed as DAX, the row-level security that must be redesigned, and the long tail of one-off reports that should be retired rather than moved. The number of workbooks on its own is a poor guide. Should you rebuild or lift and shift? explains the choice that matters most.
If the person who built the old reports leaves during the migration the risk is lost logic, which is why the inventory is documented in their words in the first week, they are paired with the migration team rather than made responsible for it, and ownership of the new semantic model is made a role in the business with a change process rather than one person's memory. See what an ongoing data function looks like.
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. Our case studies show how similar migrations have been delivered.
If part of the problem genuinely is the source system, not reporting, modernisation will not fix that part, because it 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. Our case studies show how similar migrations have been delivered.
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. Our case studies show how similar migrations have been delivered.
SuiteAnalytics Connect is a licensed NetSuite add-on that provides ODBC, JDBC and ADO.NET drivers against the NetSuite analytics data model, exposing transactions, lines, items, customers, periods and custom records as queryable tables with support for incremental extraction on last-modified dates. It is the most complete route into NetSuite data and is designed for a server-side extraction process rather than a direct laptop connection. Our data platform and warehouse page describes how we use it.
A data platform migration is the move of reporting, data models and pipelines from one platform (a legacy BI tool, an old warehouse or an ERP's direct SQL reporting) to a modern one such as Power BI and Microsoft Fabric, and it is planned in an Establish phase that inventories reports by usage, extracts every business rule into a signed definitions document, designs the target star schema and capacity, and sets a retirement date for the old platform before the build starts. How long does a Fabric implementation take? covers the platform build side.
A data platform migration is the move of an analytics estate's pipelines, storage and history, semantic models and reports from one platform to another, most often from an on-premises warehouse, Azure Synapse or a mix of Data Factory and Power BI Premium to Microsoft Fabric, done component by component with the old platform kept live until each part is reconciled and a month end has closed on the new one. Our data platform and warehouse page describes the engagement.
The Fabric Migration Assistant is Microsoft's guided tool for moving an existing data warehouse into a Fabric Warehouse. It assesses the source, converts schema and code where it can, flags what needs manual work, and helps copy the data across. It began with Azure Synapse dedicated SQL pools and SQL Server. At FabCon Europe 2026 Microsoft announced support for Teradata sources and for migrating individual objects instead of everything at once. For a smaller, tidy warehouse it can do most of the heavy lifting. For a large estate with years of stored procedures, it speeds up the mechanical work but doesn't remove the need to test that the numbers still match. Our Synapse to Fabric migration guide covers the full process, and Fabric versus legacy Azure explains when moving is worth it.
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. Our case studies show how similar migrations have been delivered.
The biggest risk in a BI migration is the numbers not matching between the old tool and the new one with nobody able to say which was right, because it turns a board meeting into an argument about tools and destroys trust in the new platform before it has started; it is managed by reconciling every measure on a known period and signing the definitions before go-live. See should you rebuild or lift and shift your reports?.
The first step in a BI migration is the inventory: every report listed from usage logs and owners and sorted into rebuild, convert temporarily, retire, or hand to its owner, followed immediately by extracting every calculation, load rule and security rule from the old platform into a definitions document while it can still be asked what it does. Nothing is built until both exist. Replacing legacy reporting is our briefing on the approach.
A BI migration is finished when the finance team has closed a month end on the new platform with the numbers reconciled to the old one, the old platform has been retired on the agreed date, every report on the retire list has gone with its owner's agreement, and monitoring and alerting are live on the new pipelines. The last converted report being switched off is the usual final milestone. Testing a data pipeline covers the reconciliation that proves it.
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. Our case studies show how similar migrations have been delivered.
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.
A UK mid-market business migrating its BI or ERP reporting, from Tableau, Qlik, QlikView, Excel or Dynamics NAV to Power BI and Microsoft Fabric, can work with Hopton Analytics, which rebuilds the data model as a star schema and certified semantic model, recreates the reports people use, runs both platforms in parallel through a month end, and retires the old licences on a date; typical migrations take eight to sixteen weeks. See how long a BI migration takes and how to keep reporting running and our Power BI page.
A UK Microsoft data and analytics partner with migration experience can help a mid-market business migrate its BI reporting, and the signs of a good one are a fixed-scope approach, a rebuilt model rather than a conversion tool, a report inventory with a retirement plan, parallel running to a month end, and case studies that show the result. Hopton Analytics does this work for UK and Ireland mid-market businesses, and our free audit is the first step.
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. Our case studies show how similar migrations have been delivered.
BI migrations take longer than planned because of undocumented business rules found late, an ERP go-live that moves, security rules that live in someone's head, and a long tail of reports nobody will agree to retire, none of which is technical. A four-week Establish phase surfaces all four before the build, which is why skipping it to save four weeks typically costs eight. Why we deliver analytics in fixed, outcome-based phases explains how we protect the timeline.
A NetSuite Power BI report usually fails to reconcile to the general ledger because it uses transaction date rather than posting period, misses custom segments that drive the real dimensions, or extracts transaction headers without lines. Modelling posting period as its own dimension, decoding custom segments in the silver layer and joining headers to lines once fixes all three. Testing a data pipeline covers the reconciliation checks that catch it.
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.
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.
Still have questions?
Can’t find what you’re looking for?
The first conversation is exploratory and carries no obligation. We’ll give you an honest answer to any question you have.
Book a free audit