Migrating old reports into Power BI means rebuilding them, not converting them. There's no button that turns a Tableau workbook, a Qlik app, an SSRS report or a spreadsheet into a Power BI report, and you should be suspicious of anyone who implies there is. The work is a rebuild on a proper shared model, and the test that decides whether it worked isn't how the new report looks. It's whether every figure reconciles with the old report, side by side, before anyone switches over. I charge a published £600 per report for exactly this, with no minimum, and the reconciliation is the part of the price that matters most.
Here's what the work actually involves, what each old report should become, and why the boring validation step is the difference between a migration people trust and one they quietly ignore.
What does a report migration actually involve?
Four jobs, in a fixed order.
An inventory. Every report catalogued: what it shows, who opens it, what feeds it, and how complicated the logic underneath really is. This is where you find the reports nobody has opened since 2023, and the two that the finance director would notice within an hour of them disappearing. I do this as a free one-day assessment that produces the full inventory and a fixed total in writing before you commit to anything.
A shared model, built first. The old estate almost certainly has its logic copied into each report separately. The right way to migrate is to build one semantic model, one agreed set of definitions, and then rebuild the reports as windows onto it. Whether you're migrating one report or thirty, they all sit on the same definitions rather than each carrying a private copy of the logic.
The rebuild. Like-for-like where the original earned it, redesigned where it didn't. Plenty of old reports are a wall of numbers because the tool they were built in made anything better hard work. Rebuilding those faithfully preserves the problem along with the data.
Validation. Every migrated figure checked against the original, in writing. More on why below, because this is the step that gets skipped when a migration is priced to be cheap.
Why do the numbers have to match the old report first?
Because trust doesn't transfer automatically. The old report might be slow, ugly and held together by one person's goodwill, but people believe its numbers. The day the new report shows a different figure for last month's revenue, every hour you spent on design is worthless. The person who spots the difference tells three colleagues, and the new report is dead before its second week.
So the rule is simple: nobody switches until the new report has been reconciled against the old one, figure by figure, and every difference has been explained in writing. Note the word explained, not eliminated. Some differences are the whole point of migrating. Old reports carry wrong logic for years: a filter someone added for one meeting and never removed, a margin calculated before a cost line that was added later, a date boundary that was always off by a day. When the new figure differs because the old one was wrong, you keep the new figure, and you document why. That document is often the first audit those reports have ever had.
I've written before about what happens when a report and its source system disagree, in why Power BI doesn't match Business Central. A migration is the same discipline applied estate-wide: every difference gets a named cause before anyone is asked to trust the result.
Should every report be migrated?
No, and a migration priced per report gives you a real incentive to ask. In my experience the inventory always turns up reports that shouldn't survive the move. Here's the honest decision table I work through with clients, with the cost of each path at my published rate as of September 2026 (source: my report migration page).
| What happens to the report | When it's the right call | What it costs |
|---|---|---|
| Migrated like-for-like | People rely on it daily and the layout is part of how they read it | £600 |
| Migrated and redesigned | The numbers matter but the original buries them | £600, same price either way |
| Consolidated into another report | Two or more reports answer the same question with slightly different logic | £600 for the surviving report |
| Retired | Nobody has opened it in months, or its question is no longer asked | £0, plus whatever its licence was costing |
| Kept on the old platform | Rare, but real: regulatory formats or embedded operational tooling | £0 now, revisit later |
If the honest answer is that half your estate should be retired rather than migrated, a fixed per-report price means you hear that answer, because I'm not billing days against the total. A consultancy quoting a lump sum for "the migration project" has no reason to tell you a third of the work shouldn't exist.
How long should you run the old and new reports in parallel?
Through at least one full reporting cycle that matters to your business, and ideally the scariest one available. For most businesses that's a month end. If your reporting peaks at quarter end, run both through a quarter end.
Parallel running means the old report stays live and people are told, explicitly, that both exist and which one is provisional. Each cycle, the figures get compared and any drift gets investigated while there's still a working reference to check against. The moment the old platform is switched off, every future discrepancy becomes an argument with no referee.
What parallel running is not: a permanent state. Two live versions of the truth is precisely the disease the migration is meant to cure, so agree the retirement date for the old platform before parallel running begins, and put the licence saving in writing next to it. That number tends to keep the project honest.
How much does report migration cost in the UK?
Most firms won't publish a migration price because they quote each project as a mystery. I publish mine so you can work out the total yourself: count your reports, multiply by £600, and that's the number, whether the source is Tableau, Qlik, SSRS or a spreadsheet estate. There's no minimum, so starting with a single report to see how the process feels is a perfectly good plan.
The free one-day assessment turns that arithmetic into a fixed quote: every report catalogued, complexity banded, and the total confirmed in writing before you spend anything. If your estate needs a proper reporting system built underneath it rather than a rebuild of what exists, that's a different job with different economics, and the assessment will say so rather than dressing a build as a migration.
Two things are included at that price that you should demand from anyone quoting for this work: side-by-side validation of every migrated figure, and a written list of the places your current reports disagree with each other. The second one is usually the most uncomfortable document in the pack, and the most useful.
What usually breaks trust during a migration?
Three patterns, all avoidable.
Converting instead of rebuilding. Tools that promise automatic conversion reproduce the old report's structure, including every piece of duplicated, undocumented logic that made the estate untrustworthy in the first place. You get the same problems with a newer logo.
Skipping reconciliation to hit a deadline. The switch-over date arrives, the numbers were "spot checked", and the first month end finds the differences in front of the board instead of in a validation pack. Recovering trust after that costs more than the migration did.
Migrating the mess faithfully. If three old reports define margin three ways, migrating all three preserves the disagreement in a faster tool. A migration is the one moment those definitions are all on the table at once, which makes it the cheapest opportunity you'll ever get to collapse them into one. I've seen what happens when that opportunity is missed, and I wrote about the general disease in six reports, six different numbers.
Common questions
Can Excel reports be migrated to Power BI automatically?
No. Power BI can import Excel data models built with Power Pivot, which occasionally gives you a head start, but an ordinary spreadsheet report is a rebuild: the data connections, the logic and the layout all get recreated properly. That's not a weakness of Power BI. The rebuild is where duplicated logic and quiet errors get found, and skipping it means carrying them forward.
How much does it cost to migrate reports to Power BI?
My published rate as of September 2026 is £600 per report with no minimum, covering Tableau, Qlik, SSRS and spreadsheet estates, with a free one-day assessment that fixes the total in writing first. Firms that don't publish a rate will quote per project, so ask them for the per-report arithmetic behind the quote and what their reconciliation step includes.
How long does a Power BI migration take?
It depends on the report count and how tangled the logic is, which is what a proper inventory establishes before anyone quotes a date. The shape is consistent though: the shared model gets built first, reports follow on top of it, and the end date should sit after at least one full parallel reporting cycle, not before it.
Do the old and new reports need to show identical numbers?
They need to be reconciled, which is different. Every figure gets compared, and every difference gets a documented cause. Where the old report was wrong, the new figure stands and the explanation is written down. A migration that promises identical numbers everywhere is promising to reproduce the old report's mistakes.
Should we migrate every report we have?
Almost certainly not. Inventories reliably turn up reports nobody opens, duplicates answering the same question with different logic, and one-off exports that became permanent by accident. Retiring those is free and makes the migrated estate smaller, cheaper and easier to trust. A per-report price makes it economically safe for your supplier to tell you this.
What is parallel running and how long should it last?
Both the old and new reports stay live, people know which is provisional, and the figures are compared each cycle. Run it through at least one reporting period that matters, usually a month end. Agree the old platform's retirement date before parallel running starts, so it's a phase with an end rather than a second version of the truth that never leaves.
What happens to the old reporting platform afterwards?
It gets retired on a planned date, with the licence saving quantified in writing. That saving is often a meaningful slice of the migration's payback, and leaving the old platform running "just in case" costs real money while quietly inviting people to keep using it.
Can we start with just one report?
Yes, and it's often the smartest way to buy. One report, migrated and reconciled, shows you the process, the validation pack and the quality of the result before you commit the estate. That's exactly why my migration pricing has no minimum.
Migration pricing and inclusions are from my published report migration page, September 2026. All figures exclude VAT where applicable.