Microsoft Fabric
Microsoft FabricMicrosoft Fabric consulting
One platform for engineering, warehousing and BI on the Microsoft estate you already pay for. We build the architecture around it, and build it to be operated after we hand it back. For a company that has never had a real data platform, Fabric is the affordable way to get a complete one, with governance and security included from the start.
Start where you are
Your starting point shapes the platform
Not every Fabric implementation begins with a sophisticated data estate.
- Reporting
We have Power BI everywhere and the reports argue with each other.
The problem is upstream of the dashboard, so that is where we start.
Start with: sources, reporting needs and ownership.
- Modernizing
We have years of ADF, SSIS, Synapse or Data Explorer and somebody still babysits it.
This is the hard part, so we map what runs today before anything moves.
Start with: the current architecture and a migration sequence.
- Evaluating or scaling
We are not sure Fabric is the right move, or it is in and the bill keeps climbing.
We’ll tell you whether Fabric is the shortest path for your estate, and when it isn’t.
Start with: the constraints around performance and operations.
Fabric delivery
SAP into Fabric, checked against SAP
Six operating entities of a global industrial group share one SAP ECC 6.0 system, under strict rules on how data leaves SAP. We built a repeatable path from SAP into Microsoft Fabric that fits the group’s own BI standards, with entity-level security on the sensitive data.
The client’s Basis and SAP teams found the process much easier than they expected.
- Microsoft Fabric
- SAP ECC 6.0
- OneLake shortcuts
- Extracted through the Microsoft SAP connector and its ABAP add-on, over the on-premises data gateway
- Landed as CSV through the corporate ingestion framework
- Loaded into Bronze, one workspace set per operating entity
- Row counts checked against SAP
- Record spot checks
- Closed-period comparison against SAP
- Wages and project financials kept inside each entity
Next phase: production, the shared Gold layer and the first project P&L reports.
Most Fabric problems start in the architecture
Capacity design, workload isolation, data modeling, governance and CI/CD decide how well it runs.
Talk to us about scopeMicrosoft Fabric services
Microsoft Fabric services
We design, implement and operate Fabric as an enterprise data platform, with Power BI as one workload on it. We select the services each workload needs, in an architecture that stays maintainable as adoption grows.
Architecture3 services
Architecture and readiness
Choose the platform structure and delivery sequence around your workloads and the Microsoft environment you already run
Strategy, readiness and architecture
Whether Fabric is the shortest path for your estate, and the architecture if it is.
Data platform and medallion design
Raw, validated and business-ready layers, so a transformation is built once.
Capacity planning and workload isolation
One heavy workload can’t slow the others on a shared capacity.
- Platform evaluation
- Medallion architecture
- SKU and region
- Roadmapping
Build and migrate3 services
Build and migrate
Bring sources, pipelines and models into a maintainable environment, with the business logic carried forward
Implementation and migration
ADF, Synapse, SSIS and Data Explorer workloads moved across.
Lakehouse, Eventhouse and data engineering
OneLake storage and Spark, with Eventhouse for real-time and IoT telemetry.
Data ingestion and transformation
Data Factory pipelines that land sources raw and conform them.
- OneLake
- Lakehouse
- Spark
- Data Factory
Secure and govern2 services
Security and governance
Build data ownership, identity, access and quality into the platform from the start
Security, identity, networking and governance
Entra ID, role-based access, managed identities, Key Vault, private networking and Purview.
Data residency and multinational architecture
Region and residency settled before anything is provisioned.
- Microsoft Entra ID
- Purview
- Key Vault
- Workspace boundaries
Operate and improve3 services
Operate and improve
Make the platform understandable to the people who will run and change it
Power BI and semantic-model modernization
Semantic models and Direct Lake rebuilt upstream of the dashboard.
CI/CD and Infrastructure as Code
Source control, testing and deployment pipelines, so the platform can be safely changed after it reaches production.
Monitoring, optimization and production support
Utilization monitored and capacity right-sized.
- Direct Lake
- Semantic models
- Deployment pipelines
- Monitoring
Power BI and analytics on Fabric
Power BI is part of Fabric, so build it that way
Reports sit on shared semantic models over one copy of the data in OneLake, so finance and operations read the same number. We modernize the Power BI estate you have and connect it to the platform underneath.
Semantic models built once
Business definitions agreed upstream, so two reports stop arguing.
Direct Lake where it pays
Reports read OneLake tables directly, without import copies to refresh.
Security set once
Row-level security and sensitivity labels set in Fabric, not in every report.
How data moves
Designed around how data moves through the organization
Each transformation is built once in the platform, and every report, alert and model reads from it.
Sources
- SaaS applications
- SAP via gateway
- Files and feeds
- Device telemetry
Raw source data
Landed as it arrived, before any checks, with nothing discarded.
Lakehouse · OneLake
Validated and conformed
Cleaned and joined into consistent business entities, so every team works from one definition of each number.
Spark · Data Factory pipelines
Business-ready
Semantic models and Direct Lake serving Power BI, dashboards, alerting and feature engineering.
Direct Lake · Semantic models
Consumers
- Executive reporting
- Self-serve Power BI
- AI and agents
- Operational apps
Our process
How our Fabric engagements work
The phases adjust to where you are starting from. The first settles the decisions that are expensive to reverse.
Phase 01Discovery and architecture review
Decision point · Written plan
We settle capacity topology and SKU, data residency and region, which source systems land where, and whether production data is permitted in non-production.
Deliverable: an architecture decision record and a capacity and region plan.
Phase 02Build and parallel run
Working solution · Measurable outcome
We build the medallion architecture in Fabric, move existing workloads across and rebuild the semantic models reporting reads from.
Deliverable: a working environment and a parallel-run report showing the numbers match.
Phase 03OngoingOngoing support and optimization
Expand what works · Embed into operations
After go-live there are usually more domains to bring in and capacity to right-size. We can stay on through managed services with P1 to P4 response times, or enable your team to run and extend it independently.
Deliverable: a runbook your team can operate from.
Migrating to Fabric
Fabric does not always start from a blank slate
We assess what should migrate, what should be redesigned and what should stay where it is, and sometimes a workload is best left alone.
Where you are
- Azure Data Factory
- Synapse and Data Explorer
- SSIS, SSAS and SSRS
- SAP through the on-prem gateway
- Power BI on extracts
- 01Inventory
- 02Dependency map
- 03Rebuild
- 04Parallel run
- 05Cutover
Parallel run exists so that when something is wrong you find out on a Tuesday instead of at quarter close.
Where you land
- OneLake
- Lakehouse
- Eventhouse
- Direct Lake
- Data Factory pipelines
- Semantic models
- Purview
Industries
Industries we work in
Healthcare
Patient, pharmacy and clinical data systems held to HIPAA, including where AI is allowed to touch them.
- Medicaid programs
- Pharmacy services
- Clinical documentation
Clients include
See healthcare work
Manufacturing and industrial
ERP, shop-floor and supplier data on one platform, so plant reporting and finance reporting reconcile.
- SAP and ERP reporting
- Shop-floor integration
- Supplier portals
Clients include
See manufacturing work
Retail and distribution
Order, inventory, credit and customer data connected across portals, branches and the platforms behind them.
- Vendor and customer portals
- Order and credit systems
- Data platforms
Clients include
See retail and distribution work
Financial services
Bank data platforms, reporting that holds up to an audit and managed support for the financial systems the business runs on.
- Bank data platforms
- Managed ERP support
- Legacy migration
Clients include
See financial services work
Insurance
Claims, member and policy systems for health plans and insurers.
- Health plans
- Claims data
- Member apps
Clients include
See insurance work
A few practical questions
Work through the decisions
Common questions about Fabric consulting, migration, capacity planning and governance.
Ask us about your situationWhat does the capacity actually cost us?
Workload shape and audience size set it more than data volume. Below an F64 capacity every report viewer needs a paid Pro license; at F64 and above, viewing is included. Sizing is part of the scoping work rather than a number on a web page.
Should we be on Fabric or Databricks?
If you run on Microsoft, start on Fabric and bring Databricks in when your data work outgrows it, for heavy machine learning or streaming. The two work together, so what you’ve built carries over. If machine learning is the main workload, or you are genuinely multi-cloud, start on Databricks. We build on both.
Does Fabric replace Synapse?
Where the workload fits. Synapse pipelines, dedicated SQL pools and Data Explorer clusters have direct landing places in Data Factory, the Fabric warehouse and Eventhouse. Some should remain where they are, and the assessment says which.
We still run on spreadsheets and Power BI extracts. Is Fabric too much for us?
No. Not every Fabric implementation begins with a sophisticated data estate. We bring data from the systems you already use, from ERP and CRM to timekeeping and invoicing, into one governed architecture, and build toward what your team can run.
Can Fabric handle real-time and streaming data?
Yes. Eventhouse and KQL take streaming data from devices, applications and logs alongside the batch data in the Lakehouse, so operational dashboards, alerting and historical analysis run on one platform. We size that ingestion against capacity from the start, because streaming workloads are the easiest way to crowd out everything else.
How do you keep one workload from slowing down another?
Shared capacity means a poorly planned workload can hurt everything else running on it, so we treat capacity as architecture. That can mean separating critical workloads, setting workspace and environment boundaries, monitoring utilization and designing ingestion and transformation to use resources efficiently.
How are security and governance handled?
We design them into the platform from the first workspace, and you can reuse the Entra ID security groups you already have. Our work covers Microsoft Entra ID, role-based and workspace security, service principals and managed identities, Azure Key Vault, private networking, Microsoft Purview and regional data-residency requirements.
Do you use a medallion architecture?
Yes. Land the raw data, clean it once and publish the version people and AI models can rely on. The pattern works the same on Fabric, Databricks or Snowflake, and it keeps the evidence, so a mistake in your logic doesn’t become a permanent mistake in your history.
Do we have to move everything at once?
No. Fabric coexists with Azure Data Factory, Synapse and Data Explorer during a migration. Pick one use case, land it, then move the next.
Who runs it after you leave?
Your team, if that is the plan, and we build toward it from week one: source control, deployment pipelines and a named owner on your side for every service principal and secret. If you would rather we ran it, managed services covers that.
How do changes get made once it is in production?
Through the same discipline as any production software: source control, CI/CD and deployment pipelines, automated testing, Infrastructure as Code, separate development, test and production environments, and monitoring.
What should we have ready before the first conversation?
A rough list of the systems that feed your reporting today, the reports people argue about, who owns the data and what Microsoft licensing and capacity you already have. If data has to stay in a particular region, say so early. The first call works from whatever you have.
How long before we see anything?
One useful thing in ninety days is the target, not a full platform. If a proposal promises a finished warehouse in that window, read it twice.
Keep exploring
Other platforms and related services
We build on Fabric, Databricks and Snowflake, so we recommend the engine that fits your estate.
Platforms we build on
- Microsoft Fabric
- Databricks
- Snowflake
Databricks
SnowflakeWorking through a larger migration or an engineering-heavy estate?
Explore our Databricks practiceNext step
What should your Fabric platform make possible?
Settling capacity, residency and sequencing at the start costs less than correcting them later. Here is what happens after you reach out.
A short call about your Microsoft estate
What runs on Azure and Power BI today, what Fabric should change and what is driving the timing.
An engineer looks at what’s running
Scope comes from your systems as they are, before anything is priced.
You get a written proposal
Covering scope, team, approach and price.