From spreadsheets to one Power BI suite: a migration checklist
To move from spreadsheets to Power BI, first list every spreadsheet and the questions it answers, then agree one definition for each KPI. Connect Power BI to the original data sources rather than the spreadsheets where possible, build one shared data model, design an overview page around the questions people ask, run old and new reports side by side until the numbers match, and only then retire the spreadsheets.
Why move from spreadsheets to Power BI?
Spreadsheets are flexible and familiar, which is why reporting starts there. Problems appear as the business grows: each team keeps its own version, numbers differ between files, monthly packs take days to prepare, and nobody is sure which formula changed. Moving to Power BI replaces copies with one model, one set of definitions and reports that refresh themselves.
What is the migration checklist?
- Inventory: List every spreadsheet, who owns it, who reads it and what question it answers.
- Group by question: Combine files that answer the same question; that is where duplicates hide.
- Agree definitions: Write down each KPI, how it is calculated, and who owns it.
- Find the true sources: Trace each column back to the system it came from.
- Design the overview first: Build the page people will open every morning.
- Build the shared model: One model that every report reads from.
- Run in parallel: Compare old and new numbers for at least one reporting cycle.
- Retire the files: Set a date, archive the spreadsheets and redirect people.
Why do definitions matter so much?
Most differences between spreadsheets are not errors but different rules. One team counts an incident as closed when the engineer finishes; another when the customer confirms. One excludes duplicates; another does not. If you migrate without agreeing these rules, Power BI will faithfully reproduce the disagreement. Write each definition in plain English, get the business owner to sign it off and add it as a description on the measure in Power BI.
| Question to settle | Example |
|---|---|
| When does the clock start and stop? | Logged time to resolved time, business hours only |
| What is excluded? | Duplicates, test tickets, cancelled requests |
| Which date is used? | Created date or resolved date for monthly totals |
| Who owns the number? | Head of service operations |
Should Power BI read the spreadsheets or the source systems?
Where possible, connect to the source system: the service desk, ERP, CRM or database. Spreadsheets add a manual step that can break or be edited. Some data only exists in spreadsheets, such as targets or manual adjustments. Keep those in one controlled file, ideally in SharePoint or OneDrive with an owner, and load it into the model. For larger setups, a Fabric lakehouse can hold cleaned data from several sources; see Microsoft Fabric explained.
What did this look like for Omantel?
Omantel’s service teams had five spreadsheets behind every answer, covering incidents, service levels, customer satisfaction and workload. We replaced them with one Power BI suite and one set of filters. Everyone now reads the same numbers through the same filters, so reviews move straight to decisions, and new reports can be added in the same layout and style.
Read the full Omantel case study for the before and after.
How do you get people to switch?
- Involve spreadsheet owners: They know the edge cases and become the report’s champions.
- Match the old numbers first: Trust comes from seeing the same figure in both places.
- Train with real questions: Show people how to answer their own weekly questions.
- Keep an export option: Allow export to Excel for analysis, but not as the source of truth.
- Set a retirement date: Without one, people keep updating the old files.
What mistakes should you avoid?
Rebuilding each spreadsheet as its own report page, skipping the definitions step, connecting Power BI to a personal spreadsheet on someone’s laptop, and switching off the old files before the numbers match. Another common mistake is designing for the analyst rather than the reader; our guide to Power BI report design covers how to avoid that.
What happens after go-live?
Name an owner for the model and for each report. Review usage every quarter and remove pages nobody opens. Add new reports in the same layout so the suite stays familiar. Put access rules in place before sharing widely; see Power BI governance and row-level security.
What does a migration involve in effort?
Most of the effort goes into the first three steps: inventory, definitions and tracing sources. Building pages is usually quicker than people expect once those are settled. Plan time for the parallel run too, because each mismatch needs investigating with the spreadsheet owner. A realistic plan for one department covers discovery, model build, report design, a parallel run of one reporting cycle and training, with a named business owner available throughout.
How UIUX Studio helps
We move teams from spreadsheets to Power BI, from definitions and data models to report design and training. See our Technology Advisory service or read what a Power BI dashboard project costs.
Frequently asked questions
How long does a migration take?
From a few weeks for one team to several months for a whole department.
Can Power BI read Excel files?
Yes, but connecting to source systems is more reliable.
Should we keep Excel?
For analysis and exports, yes; not as the source of truth.
What if numbers do not match?
Find which definition differs, agree the rule and document it.
Who should own the reports?
A named business owner plus a technical owner in the BI team.