Home/FAQ/Migrations/Migrating from Excel

Migrations Migrating from Excel - FAQs

36 questions answered by the Hopton Analytics team.

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.

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.

You can import an Excel workbook into Power BI, and for a one-off analysis it is fine, but as a migration it fails because the workbook was an export with logic on top rather than the source, so importing it carries the manual steps, the duplicated lookups and the single person who understands it into the new tool. The migration moves the logic into a semantic model and lands the data from the systems the workbook exported from. See what are the signs a business has outgrown spreadsheets?.

Yes, you do lose some of the flexibility to quickly add a new column or calculation yourself when moving from Excel to Power BI, in the governed, shared reports, and 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.

You do not usually need Microsoft Fabric for an Excel migration, because Power BI alone is enough for the great majority of them. 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.

You do not need Microsoft Fabric to migrate from Excel to Power BI when the spreadsheets export from one system; a Power BI semantic model with dataflows is enough. You do need Fabric, or a warehouse, when the pack combines three or more systems, when budgets and forecasts need governed input tables, or when finance wants self-service over the model. See when Fabric is worth it for Business Central.

Excel does not go away after a Power BI migration: it connects live to the semantic model through Analyze in Excel so analysts can pivot governed numbers without exporting them, and it remains the right tool for one-off analysis and scenario modelling. What goes away is Excel as the place numbers are calculated and the monthly export that fed it. See what is a semantic model?.

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.

To get started migrating from Excel to Power BI, 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.

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.

You keep the numbers matching the old spreadsheets by reconciling every DAX measure to the spreadsheet cell it replaces on a known period before anyone uses it, explaining each difference as a definition change or a timing difference, and closing one month end on both in parallel; differences found this way are usually the spreadsheet being wrong, and the agreed definition is signed by finance. See testing a data pipeline.

You migrate business reporting from Excel to Power BI by landing the source data the spreadsheets were exporting, modelling it once as a star schema, rebuilding the calculations as DAX measures in a semantic model reconciled to the spreadsheets they replace, and building the reports people actually use on that model, with Excel connected live for analysis. It is a four-week Establish phase and an eight to twelve week build for a typical finance pack. Our Power BI page describes how we run it.

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.

A typical Excel to Power BI migration of 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.

An Excel to Power BI migration for a mid-market finance pack takes a four-week Establish phase to inventory the workbooks and agree definitions and an eight to twelve week build to land the data, model it, rebuild the measures and deliver the priority reports, finishing when a month end has been closed on Power BI beside the old spreadsheets. A single-system estate is at the short end; a group with several companies at the long end. See how long a BI migration takes.

Only the Tableau workbooks that are actually opened should be migrated to Power BI, which in most estates is a minority: usage logs show the rest are unused, duplicated or superseded. Migrate the used reports onto a rebuilt model, retire the rest with their owners' agreement, and let owners rebuild genuine one-offs on the new model themselves. Fewer dashboards, more decisions sets out the test for keeping a report.

A spreadsheet-to-Power-BI migration should not disrupt day-to-day reporting, because 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.

Moving from Excel to Power BI is not just about nicer dashboards: 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.

There is no supported tool that converts Tableau workbooks to Power BI automatically with reliable results, because Tableau calculations run inside a worksheet while DAX measures run in a model with filter context, so a literal translation often gives a different number; third-party converters can speed up the visual layout but the model and measures are rebuilt. See should you rebuild or lift and shift your reports?.

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.

Moving from Excel reporting to Power BI costs Power BI Pro licences at £10.80 per user per month plus a fixed-price build; on our published Analytics Acceleration Programme tiers the indicative two-year investment is £52.7k for a business of 25 to 100 people, £73.9k for 100 to 500 and £114.5k for 500 and over, covering the Establish phase, the build and continuity support. See the Analytics Acceleration Programme.

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.

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.

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.

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.

The Tableau workbooks to migrate to Power BI are the ones opened in the last ninety days by someone who makes a decision with them, which in most estates is around a fifth of the total; the rest are retired with their owner's agreement rather than rebuilt, and the inventory in the first weeks of the migration is what identifies them. See how do you turn dashboards into decisions?.

Power BI integrates better with Microsoft technology than Tableau, 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.

A Power BI consultancy that builds semantic models rather than report copies can migrate business reporting from Excel to Power BI; Hopton Analytics does this for UK and Ireland mid-market businesses by inventorying the pack, agreeing the definitions with finance, modelling the data once and closing a month end in parallel before the spreadsheets are retired. See how long a BI migration takes.

The reports should ideally no longer be maintained by the same person alone after moving from spreadsheets to Power BI. 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.

MicroStrategy is easier to migrate than Tableau or Excel because it already has a governed schema layer where attributes and metrics are defined once and reused, which maps closely to a Power BI semantic model, whereas Tableau and Excel hold their logic inside each workbook and the definitions have to be recovered from the visuals. The migration inherits the schema rather than reverse-engineering it. See how do you migrate from Tableau to Power BI?.

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, your current Excel reports will look different in Power BI: layout and interactivity change, generally for the better, because 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.

No, your existing Excel calculations and logic are not lost in the move to Power BI, but they are 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.

Yes, your finance team will be able to use Power BI as easily as Excel in most cases, because 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.

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