A staged, low-risk migration that preserves your existing data model and business logic — no big-bang rewrite, no disruption to users.
The BMD BI portal is a real engineering achievement: a 473 MB Power Pivot model driving 272 active thin Excel reports across 27 divisions. It works. The problem is the foundation it runs on.
The SharePoint server, the SSAS Tabular service, the PortalFront hosting contract — any one of these can fail without a Microsoft-supported recovery path. The system is currently stable, but stability isn't safety. Three years of unpatched vulnerabilities accumulate silently. The cost of a forced migration after a failure is dramatically higher than a planned one now.
Microsoft Fabric + Power BI is the natural successor to this stack — built specifically to absorb SSAS Tabular models and Power Pivot logic without starting from scratch.
A prior Excel 2013 upgrade attempt failed because SSAS version-to-version upgrades were notoriously brittle. Power BI's XMLA import path is fundamentally different — it reads the model directly rather than stepping through compatibility levels. Your existing DAX at compat ~1100 is additive-compatible upward: it runs as-is in modern Power BI. There will be cleanup work in Stage 3, but it's targeted modernization — not a rewrite. Every measure that works today will keep working.
These aren't marketing claims — they're capabilities the current stack structurally cannot deliver, regardless of how well it's maintained.
The current manual SQL → SSAS → Core.xlsx → 272 files cycle is someone's daily job. Power BI replaces it entirely with scheduled, monitored refresh — up to 48× per day if needed. Failures trigger alerts, not silence.
OperationalSales reps can pull live division performance, top customers, and booked orders on their phone before walking into a meeting. The current portal has no mobile story — Power Pivot workbooks don't work on phones.
Sales EnablementDivision managers see their division. Territory reps see their territory. Leadership sees everything. One report, enforced automatically at the model level — no separate file per role, no ACL spreadsheet to maintain.
SecurityBusiness users ask questions in natural language: "What were BP's top 10 customers this quarter?" and get an instant, visualized answer. No DAX, no pivot tables, no IT request. New metrics generate themselves.
AIReports embed directly into Teams channels and meetings. The whole team reviews the same live dashboard in a call, drills into the data together, and comments on specific visuals — without switching tools.
CollaborationDivision leaders build their own views — filtering, drilling, slicing — without filing an IT request. The 272-thin-file model exists because Power Pivot required a separate file per pivot configuration. Slicers eliminate that entirely.
Self-ServiceWe've analyzed every measure in BMD_Core.xlsx — all 403. The model works. But it's carrying 12 years of accumulated complexity that modern DAX eliminates without changing a single business rule.
Every time-period variant (SEL, YAG, YTD, QTD, Per Day, Projected) is a separate hand-written measure. Adding one new metric requires writing eight new measures manually.
Same analytical output. Same numbers. Adding one new metric now costs one measure — the calculation groups give it all nine time comparisons automatically.
Today the model has separate named measures for Sales SEL, Sales YAG, Sales YAG as of Date, Sales YTD, Sales QTD, Sales per Day, Sales Projected — seven measures, written individually, for one concept. That pattern repeats for GM$, GM%, Qty, and COGS. After modernization: five base measures, one Time Intelligence calculation group, and a "Period" slicer on the report replaces seven separate report tabs. The same logic that today requires 403 measures and a 473 MB workbook will be expressed in a model that's leaner, faster to query, and far easier to extend.
Each stage delivers real value independently and decommissions one piece of the old stack. The project can pause after any stage. Stage 4 is optional — the gateway refresh works indefinitely.
First Power BI reports go live, connecting through a gateway to your existing SSAS Tabular server. Zero changes to current infrastructure — runs in parallel. Users can compare numbers side-by-side before anything is decommissioned.
272 active thin files replaced by 20–28 Power BI reports with slicers. Users move to the Power BI App. bmdbi.portalfront.com and SharePoint 2013 decommissioned. PortalFront contract ends.
SSAS Tabular model exported via XMLA and deployed to Microsoft Fabric. Compatibility level upgraded to 1500. Power BI connects to Fabric instead of on-prem SSAS — users see nothing change.
Calculation groups replace the 120+ time-intelligence variants. 403 measures rationalized to ~40 base measures. WINDOW functions, field parameters, and dynamic dimensions unlock new report capabilities.
SQL Server data moved to Fabric Lakehouse via Azure Data Factory pipeline. DirectLake replaces the gateway. Monitored refresh with alerting. Fully cloud-native. Optional — gateway refresh works indefinitely.
The migration modernizes the platform, not the business logic. Everything your users depend on is preserved.
All 64 tables, 67 relationships, and the full measure library migrate intact. The numbers users see today are the same numbers they'll see in Power BI — validated side-by-side in Stage 0 before anything is decommissioned.
The Power BI App mirrors the current portal's report structure — Flash Reports, Category Sales, Booked Orders, Budget. Division-level groupings preserved. Users find the same things in the same places from day one.
Restricted reports (commission data, proprietary) become Power BI row-level security roles. The same people see the same data — enforced automatically at the model level rather than by folder ACLs.
Daily, weekly, and monthly data on the same schedule — just automated. No one triggers the refresh manually. Failures send alerts rather than going unnoticed until someone opens a stale report.
Every DAX measure, KPI definition, and calculation that works today works correctly in Fabric. Stage 3 adds modern capabilities on top — it doesn't replace what's already right.
All 27 division codes (AL, ACT, BMD, BP, BR, BSI, BT, CH, DFB, Dunn, FP…) carry through. Marvin Windows, intercompany actuals, budget tracking — all preserved in the migrated model.
The 60-day Microsoft Fabric F64 trial is free and covers enough capacity to complete Stages 0 and 1 and validate the Stage 2 model migration — before any licensing commitment.
Start the free F64 trial. Complete Stage 0 (first reports live) and Stage 1 (PortalFront decommissioned). Count how many people actually use the new portal during the trial period. If it's under ~40 active users, PPU at $20/user/mo is almost certainly the right long-term answer — no capacity management overhead, scales with actual usage.
A few items came up during the live data audit that need BMD input to scope Stage 1 accurately. None of them block Stage 0.
Are FR, OS, SI, SP, TD distinct business divisions — or are some rep territories or report categories? This determines how we structure the Power BI App navigation and row-level security roles.
Marvin Windows & Doors has 6 dedicated model tables and active reports across Daily + Tabular folders. Dealer tracking, vendor program, or both? Determines the Marvin report set and whether the Hanley Wood market data migrates.
Who runs the current manual SQL → SSAS → Core.xlsx cycle today? How often, and what happens when it doesn't run? This informs gateway placement and the Stage 0 scheduled refresh setup.
Who currently has access to the commission and proprietary data reports (PY Commission, Sales_by_Metro_Region)? Current ACL becomes the Power BI row-level security role definition.
How many people actively log into bmdbi.portalfront.com? The single biggest licensing input — under ~40 active users, PPU ($20/user/mo) is likely the right answer. Over 40, F64 capacity wins on per-user cost.
The SharePoint audit logs (BMD_BI_Audit_Log_*.xlsx) show which of the 272 thin files are actually opened. Pulling these before Stage 1 scope is confirmed lets us build the right 20 reports first and confidently skip the rest.