Business Professionals
Power BI | Power Pivot | Power Query | DAX
Cloud Flows | RPA | AI Builder | Copilot
60+ Formulas | Data Stories | Advanced Reporting & Modeling
VB Programming | Report Automation |
MS-Office Automation
Techno-Business Professionals
Power BI | Power Query | Advanced DAX | SQL - Query &
Programming
Microsoft Fabric | Power BI | Power Query | Advanced DAX |
SQL - Query & Programming
Power BI | Power Apps | Power Automate | Copilot Studio | Power Pages | Dataverse
Microsoft Power Apps | Microsoft Power Automate
Power BI | Adv. DAX | SQL (Query & Programming) |
VBA | Python | Web Scrapping | API Integration
Power BI | Power Apps | Power Automate |
SQL (Query & Programming)
Power BI | Adv. DAX | Power Apps | Power Automate |
SQL (Query & Programming) | VBA | Python | Web Scrapping | API Integration
Power Apps | Power Automate | SQL | VBA | Python |
Web Scraping | RPA | API Integration
Technology Professionals
Power BI | DAX | SQL | ETL with SSIS | SSAS | VBA | Python
Power BI | SQL | Azure Data Lake | Synapse Analytics |
Data Factory | Databricks | Power Apps | Power Automate |
Azure Analysis Services
Microsoft Fabric | Power BI | SQL | Lakehouse |
Data Factory (Pipelines) | Dataflows Gen2 | KQL | Delta Tables | Power Apps | Power Automate
Power BI | Power Apps | Power Automate | SQL | VBA | Python | API Integration
Power BI | Advanced DAX | Databricks | SQL | Lakehouse Architecture
Business Professionals
Power BI | Power Pivot | Power Query | DAX
Cloud Flows | RPA | AI Builder | Copilot
60+ Formulas | Data Stories | Advanced Reporting & Modeling
VB Programming | Report Automation |
MS-Office Automation
Techno-Business Professionals
Power BI | Power Query | Advanced DAX | SQL - Query &
Programming
Microsoft Fabric | Power BI | Power Query | Advanced DAX |
SQL - Query & Programming
Power BI | Power Apps | Power Automate | Copilot Studio | Power Pages | Dataverse
Microsoft Power Apps | Microsoft Power Automate
Power BI | Adv. DAX | SQL (Query & Programming) |
VBA | Web Scrapping | API Integration
Power BI | Power Apps | Power Automate |
SQL (Query & Programming)
Power BI | Adv. DAX | Power Apps | Power Automate |
SQL (Query & Programming) | VBA | Web Scrapping | API Integration
Power Apps | Power Automate | SQL | VBA |
Web Scraping | RPA | API Integration
Technology Professionals
Power BI | DAX | SQL | ETL with SSIS | SSAS | VBA
Power BI | SQL | Azure Data Lake | Synapse Analytics |
Data Factory | Azure Analysis Services
Microsoft Fabric | Power BI | SQL | Lakehouse |
Data Factory (Pipelines) | Dataflows Gen2 | KQL | Delta Tables
Power BI | Power Apps | Power Automate | SQL | VBA | API Integration
Power BI | Advanced DAX | Databricks | SQL | Lakehouse Architecture
LEARN THIS HANDS ON
Microsoft Fabric & Power BI
Most analytics teams still run on shared Excel workbooks, even when Fabric is already licensed. This guide shows a concrete, low‑risk path from "monster workbooks" to Microsoft Fabric, step by step, without breaking your current reporting.
We’ll move from raw files to a Lakehouse, then to semantic models and Power BI reports, and close with patterns for scheduling, governance, and performance that feel familiar if you already build serious Excel models. If you want to go much deeper on end‑to‑end patterns, the same approach underpins modern Fabric‑based BI projects.
The biggest mistake is trying to recreate your workbook exactly as it is, just in the cloud. Fabric is not “Excel Online Pro” — it’s a different shape of solution.
Think in terms of layers:
In Excel, these are usually all jammed into one file. Your migration path is basically: tease these layers apart without disrupting your users.
Before you touch Fabric, map what you actually have. You don’t need a formal audit, but you do need a clear picture.
Create a simple list of critical files and label each one:
You’ll migrate these roles differently.
For each key workbook, note:
These “sacred outputs” will guide where you keep Excel in the loop versus where you move to Power BI.
First goal: stop treating Excel files as the system of record. Make Fabric the source of truth, Excel the client.
Typical path:
SalesAnalytics_LH)./raw/erp_exports//raw/crm_exports//raw/manual_inputs/Upload existing Excel/CSV files into raw. For recurring files, plan to automate ingestion (next section).
Use a Data Pipeline (or Dataflow Gen2 if you prefer Power Query) to pick up Excel files and land them into delta tables.
High‑level pattern:
Files area.Example: simple PySpark notebook to convert an Excel file to a delta table:
from pyspark.sql import SparkSession
spark = SparkSession.builder.getOrCreate()
# Read Excel from OneLake Files
input_path = "abfss://workspace@onelake.dfs.fabric.microsoft.com/lakehouse/Files/raw/erp_exports/sales.xlsx"
df = spark.read.format("com.crealytics.spark.excel").options(
header="true",
inferSchema="true"
).load(input_path)
# Write as delta table in Lakehouse
output_path = "Tables/sales_raw"
df.write.mode("overwrite").format("delta").save(output_path)
Schedule this notebook in a pipeline to keep your sales_raw table up to date.
If you’re already comfortable with Power Query in Excel, Dataflows Gen2 is the easiest on‑ramp.
Typical steps:
Sample Power Query (M) to clean an Excel export:
let
Source = Excel.Workbook(File.Contents("sales.xlsx"), true),
Sales_Sheet = Source{[Item="Sales",Kind="Sheet"]}[Data],
PromotedHeaders = Table.PromoteHeaders(Sales_Sheet, [PromoteAllScalars=true]),
ChangedTypes = Table.TransformColumnTypes(PromotedHeaders,{
{"OrderDate", type date},
{"Amount", type number},
{"Region", type text}
}),
FilteredRows = Table.SelectRows(ChangedTypes, each [Amount] > 0)
in
FilteredRows
Once your raw data is in the Lakehouse, the next step is to relocate transformation logic.
For workbooks that already use Power Query:
This keeps your logic almost identical, but runs it centrally.
Look for heavy formula sheets used purely to reshape data (e.g., OFFSET, INDEX/MATCH, TEXT, LEFT/RIGHT, SUMIFS chains). These usually become either:
Example: a SUMIFS‑based aggregation in Excel:
'Simplified example in Excel
=SUMIFS(Sales[Amount], Sales[Region], "West", Sales[Year], 2024)
Equivalent DAX measure in a Fabric semantic model:
Sales West 2024 =
CALCULATE(
SUM(Sales[Amount]),
Sales[Region] = "West",
Sales[Year] = 2024
)
The key move: aggregation logic lives in DAX, not scattered SUMIFS across sheets.
With clean tables in your Lakehouse/Warehouse, create a semantic model (dataset) that mirrors how you wish your Excel model looked.
From your tables, aim for:
FactSales, FactBudget, FactInventory.DimDate, DimCustomer, DimProduct, DimRegion.In Fabric (via Power BI experience):
Start with the measures that drive your reports today.
Examples:
Total Sales = SUM(FactSales[Amount])
Total Budget = SUM(FactBudget[BudgetAmount])
Sales vs Budget % =
DIVIDE(
[Total Sales] - [Total Budget],
[Total Budget]
)
Sales LY =
CALCULATE(
[Total Sales],
DATEADD(DimDate[Date], -1, YEAR)
)
Keep measure names business‑friendly. These will show up both in Power BI and in Excel pivot tables connected to the model.
You don’t have to push everyone into Power BI on day one. Excel can sit on top of Fabric models quite comfortably.
In Excel:
Now your users can:
This is a big psychological win: data is centralised, but Excel still feels familiar.
Where you previously had hidden sheets with intermediate calculations:
Example cube formula in Excel:
= CUBEVALUE(
"ThisWorkbookDataModel",
"[Measures].[Sales vs Budget %]",
SLICER_MEMBER("DimRegion[Region]", "West"),
SLICER_MEMBER("DimDate[Year]", 2024)
)
This lets you keep a highly formatted Excel dashboard while the logic lives in Fabric.
Once the data and logic are centralised, moving from Excel dashboards to Power BI is mostly a UX decision.
Prioritise:
For each candidate, rebuild the key visuals in a Power BI report using your existing semantic model.
A pragmatic pattern:
You can:
Once your first migrated flows are live, stabilise them with a few key practices.
Instead of:
SalesReport.xlsx, refresh all, save, email.”Do:
Basic rules that work well in Fabric:
If you’re used to fighting slow workbooks, the same ideas apply:
To make this real, here’s a simple 4‑week plan you can actually follow:
Week 1
Week 2
Week 3
Week 4
If you do just this for one workbook, you’ll have a repeatable pattern for the rest of your Excel estate: Fabric as the source of truth, transformations centralised, models shared, and Excel demoted from “database” to a flexible front‑end.
Don’t try to migrate all your workbooks at once. Choose a single, high‑value Excel report, move its data and transformations into Fabric, connect Excel back to the new semantic model, and only then start rebuilding the visuals in Power BI — that sequence keeps users productive while you quietly modernise everything underneath.
Microsoft Fabric
New
Next Batches Now Live
Power BI
SQL
Power Apps
Power Automate
Microsoft Fabrics
Azure Data Engineering