Supply Chain Dashboard Migration From Excel to Power BI: Timeline and Fixed-Fee Scope

The monthly supply chain pack works. That is the part most Power BI proposals get wrong. It works because an analyst — usually one, usually your best one — spent four years encoding your business into it: which SKUs count as active, how a depot-to-depot transfer is excluded from sales, which customer codes roll up to which key account after last year's restructure, why OTIF ignores three order types.

The problem is not accuracy. It is that the pack takes two days a month to assemble, only one person can produce it, it slips when that person is on leave, four versions circulate by email before anyone agrees which is current, and when the Operations Director asks why the fill rate dropped in one region, nobody can answer in the meeting.

That is the case for migration — not modernisation. And the migration risk is precisely the thing that makes the spreadsheet valuable: if the rebuild loses the undocumented logic, the new dashboard will be beautiful, fast, governed and wrong — and the analyst will quietly keep running the Excel pack in parallel forever.

An Excel-to-Power BI migration replaces a manually assembled spreadsheet pack with a governed semantic model — data pulled directly from source systems on a schedule, business logic rebuilt as documented measures, and reports published once for everyone. It is a logic-extraction and data-modelling exercise, not a file conversion.

The distinction that decides the budget: you are not converting a file. You are rebuilding a data model that produces the same numbers from a different starting point.

Power BI Desktop will import a workbook's Power Query queries, Power Pivot model objects, measures, KPIs and relationships — genuinely useful if your analyst already built a data model. But hierarchies are skipped, binary columns are dropped, named ranges come across as external references, and external Analysis Services connections are not supported. Treat the import as a head start on a rebuild, never as the rebuild itself.

Any consultant who quotes a fixed fee before doing this has either priced in a large contingency or is about to raise a change request. Discovery is 3–5 working days for a typical pack, and it answers:

• How many reports, honestly — the tabs, not "the supply chain pack"
• How many genuinely distinct data sources (six tabs off one ERP extract is one source)
• Whether each source is an ERP table or a manual export — the single biggest cost driver
• How much logic is in formulas and how much is in the analyst's head — sit with them and rebuild one month while they narrate
• Hidden lookup tables and hard-coded mappings — depot-to-region, customer-to-key-account
• Refresh cadence and its real driver — monthly because the business needs it, or because assembling it takes two days?
• Who the audience is, and how many build versus view versus export
• The data quality you will be exposing once a human stops patching gaps by hand

Rebuild the model; do not lift the shape. A spreadsheet is wide and denormalised because that is what a grid does well. A semantic model wants a star schema with conformed dimensions and a proper calendar.

Agree definitions before building a single visual. Write down what OTIF means, which order types count, what an "active SKU" is, how returns net off — and get it signed by the person who owns the metric.

Run in parallel for one full cycle and reconcile to the row. Produce the Excel pack and the Power BI report for the same period, then reconcile every headline number and drill into every variance until it is explained.

Retire the spreadsheet deliberately, on a date, with a named owner. If the old pack keeps circulating, you have two numbers and a monthly argument. The definitions document you produce along the way is the real deliverable — the thing the spreadsheet never had.

A fixed fee covers work whose shape is knowable after discovery. It cannot cover work that depends on somebody else's system, somebody else's data quality, or a decision that has not been made yet.

Bounded means one pack, one primary audience, an agreed list of sources, no new KPIs — with the analyst and the metric owner available a few hours a week.

Six to eight weeks is realistic. Where it stretches, the cause is almost never Power BI — it is source-system access taking three weeks to approve, or two people disagreeing about what counts as a late delivery.

Most mid-market supply chain packs do not need a lakehouse on day one. Saying so costs me revenue and saves you a year.

Power BI Pro is the default: everyone who builds or publishes needs one, and in shared capacity every viewer needs one too. Premium Per User raises refresh to 48 per day and adds larger models, the XMLA endpoint and paginated reports — but every consumer still needs a PPU licence to see the content. Microsoft Fabric capacity (F SKUs) changes the economics only above a threshold: free users can view content once the workspace sits on an F64 capacity or larger; below F64, viewers still need Pro or PPU.

The practical rule for a pack with 15–40 viewers and monthly or daily data: Power BI Pro, an import model, scheduled refresh through an on-premises data gateway if the ERP is local. Move to a Fabric capacity when viewer count makes F64 cheaper than per-user licences, or when the model outgrows shared capacity. And keep Excel — Analyze in Excel lets planners build connected PivotTables against the published model, with row-level security enforced.

Do not migrate a genuine one-off — an analysis run twice a year for a tender is cheaper in Excel. Do not migrate heavy what-if modelling — scenario work with dozens of adjustable assumptions, goal-seek and manual overrides is what Excel is good at. Do not migrate a report whose underlying data cannot survive exposure — if the analyst patches gaps by hand every month, a dashboard will publish those gaps to twenty people on day one.

Two schedule risks you do not control: access — read access to an ERP production table, gateway installation and firewall rules routinely take longer than the model build; and late data — refresh does not fix it, so if a 3PL sends stock positions on the fourth working day, your dashboard is still four days behind. And expect other departments to ask for their own version the moment finance sees the drill-through.

Answer five questions this week, before you talk to anyone about a fee:

• How many distinct source systems feed the pack — and how many are manual exports rather than connections?
• Which three numbers would cause a serious argument if they changed, and who owns their definition?
• If the analyst were on leave for four weeks, could anyone else produce the pack?
• Which decision would actually change if the pack refreshed daily instead of monthly?
• Who will own the model after go-live, and are they willing to?

If the fourth question has no answer, automate the pack and stop there — that is a real, defensible outcome. If it does, you have a business case. We run these as bounded Microsoft-native scopes: unify the data into a governed model, then extend into prediction and automation once the reporting layer is trusted.