How Do You Move Excel Reporting into a Cloud Data Warehouse?

Few finance or operations teams decide to run reporting in Excel. It happens one workaround at a time, and by the time anyone asks how to migrate Excel reporting to a data warehouse, the spreadsheet is doing a job it was never designed for. This guide covers how to recognise that point, where the sources and rules are hiding, the order of work and what should stay in a spreadsheet.

How do you know month-end spreadsheets have become a system of record?

A spreadsheet has become a system of record when a figure in it cannot be rebuilt from the source systems without the spreadsheet. The test is blunt: if the file were deleted, could anyone reproduce last month's numbers from the systems alone?

The usual signals:

• Typed-in adjustments. Someone overwrites a cell each month because the source is known to be wrong, and the correction exists nowhere else.
• Versioned filenames. A file called report_final_v3.xlsx is a change log without the log.
• Lookups into other spreadsheets. A VLOOKUP into a file on a shared drive is a dependency on an undocumented table.
• Two numbers for the same thing. The dashboard says one figure, the board pack another, and the spreadsheet is the one people believe.

Each is a reason to treat the spreadsheet as a legacy system with an undocumented data model.

Where are the sources and the rules hiding?

The sources are usually a handful of systems behind the export buttons, and the rules are in the formulas, the pivot filters and the adjustments people apply by hand. More of this discovery happens in conversation than in a database catalogue.

• Trace each tab backwards. Who pastes into it, from which system, with which filters and date range.
• Read the formulas as transformation rules. Nested IFs that map codes to categories, SUMIFS with hard-coded dates. Each needs a name, an owner and a test.
• Collect the rules in people's heads. "We always exclude the intercompany entities." Write them down verbatim, then make them precise.
• Find the mapping tables hiding in tabs. Cost-centre hierarchies, region lists, owner assignments. These become dimension tables, each with an owner.

The output is a rule register: one row per rule, where it lives today, what it does, who decides it and a worked example from a recent month. Both sides sign it off before anything is built.

What order should the work happen in?

One report first, then source discovery, rules written down, warehouse layers, reconciliation against the last months of manual figures, and only then the dashboard repointed. The order matters because each step produces the acceptance test for the next.

Raw holds the exports as they arrived, so you can prove where a number came from; staging conforms types, keys and dates; curated holds the facts and dimensions, where the rule register becomes code; reporting holds the shapes a BI tool reads. When a reconciliation fails, the layers show which step introduced the difference.

Reconciliation is the step teams are tempted to cut, and the step that decides whether anyone trusts the result. Compare row counts, control totals and every reported figure with the spreadsheet versions, and investigate each difference: some will be defects in the new pipeline, some defects in the spreadsheet found for the first time. Dashboards are repointed last, once the semantic model carries the definitions.

What does a reconciled migration of manual reporting look like in practice?

It looks like a layered warehouse, a written mapping for every object and automated checks against every system that already reports the figures. In a previous engagement at Volvo Cars via Toptal, MV.tech's founder migrated legacy and manual reporting into a Snowflake warehouse with raw, staging, curated and reporting layers, designed fact and dimension models for Power BI with source-to-target mappings, and built validation and reconciliation checks across source systems, Snowflake, Salesforce CRM Analytics and BI reports. Checks of that breadth are what let a manual process be retired on evidence rather than on a date.

What should stay in a spreadsheet?

Analysis, scenarios and anything one person needs for a week. A spreadsheet is the right tool for a question nobody has asked before and the wrong tool for a figure that has to be the same every month.

Keep in Excel: what-if models built on a governed extract, board-pack commentary written next to figures pulled from the reporting layer, and inputs that genuinely originate with a person, such as budget assumptions, provided they are loaded into the warehouse with a timestamp and an owner. Move into the warehouse: any mapping table more than one report depends on, any adjustment applied every month, and any formula behind a figure reported to the board, the auditors or a regulator. The aim is not to ban Excel but to stop a spreadsheet being the only place a rule exists.

What is a sensible first milestone?

One report, reproduced from the warehouse, reconciled against the last three months of manual figures and signed off by the person who used to build it. It gives an estimate for the rest of the pack based on your sources and rules rather than a template.

Pick a report with few sources and a clear owner, agree in advance what "matches" means, run both versions in parallel for at least one close, and insist that handover includes the rule register, source mapping, reconciliation results and refresh schedule. We quote after a scoping call, because the cost depends on the number of sources and rules, not on the size of the file.

Frequently asked questions

Plan the move with MV.tech

Our data warehouse migration service covers source discovery, the rule register, raw-to-reporting layers, reconciliation and the repointed dashboard, starting with one report. Bring the month-end pack, the list of systems behind it and the person who builds it today to a scoping call. We quote after a scoping call.