Microsoft Fabric May 2026: Power Query Get Data, Copilot Tooling Format, and the Enterprise Migration Playbook

TL;DR

• The Microsoft Fabric May 2026 release introduces a redesigned Power Query Get Data experience (Preview) — unified data-source discovery across Fabric, Power BI Desktop, and Excel with keyboard-first navigation and dark-mode support.
• The Copilot Tooling Format ("Prep Data for AI") is now GA: Git-friendly, text-based storage of Copilot metadata (synonyms, descriptions, sample questions). For enterprises running TMDL-based semantic-model pipelines, the format integrates cleanly into existing repositories.
• Real-Time Intelligence in Fabric continues to mature with deeper Eventhouse integration, KQL Database governance, and Data Activator reflexes that move action triggers out of Power Automate where appropriate.
• OneLake governance enhancements include domain-level RBAC tightening, shortcut audit logging, and improved item-lineage tracing.
• For enterprises on Power BI Premium (P-SKU) considering the migration to Fabric F-SKU, the May 2026 features change the readiness calculus. This guide walks through the migration sequencing, the workspace-by-workspace cutover pattern, and the governance overlays required for regulated industries (HIPAA, SOC 2, FedRAMP).

Executive Summary

Microsoft Fabric crossed a maturity threshold in 2026. The platform is no longer "Power BI plus a data warehouse" — it is the unified intelligence platform Microsoft has been building toward since FabCon 2023. The May 2026 release is not the biggest single Fabric release of the year, but it is the most strategically important for one reason: every feature introduced or generally-available'd in May is a feature that enterprises with active Power BI Premium contracts must now factor into their renewal-or-migrate decision.

This guide is written for enterprise data leaders running Power BI at scale (1,000+ users, regulated industries, 50+ certified semantic models) who are within 12 months of a Fabric migration decision. We cover the May 2026 features that materially affect that decision, the technical architecture for a phased Premium-to-Fabric cutover, the governance pattern that keeps the compliance auditor satisfied across the migration window, and the EPC Group implementation framework refined across hundreds of Fabric implementations.

The themes that run through every section: Fabric F-SKU capacity is fundamentally different from Power BI Premium P-SKU. It is a unit of compute consumption, not a unit of license entitlement. The enterprises that succeed at the migration are the ones that build a capacity-consumption observability practice before they cut over, not after.

Why Microsoft Fabric May 2026 Matters

Three factors converge in mid-2026 that make this release a decision point:

1. Premium P-SKU is on a documented sunset trajectory. Microsoft has not announced an end-of-life date for P-SKUs, but every product investment is going into F-SKUs. P-SKU customers can expect feature parity to drift over the next 18 months in ways that matter for AI workloads (Copilot, Prep Data for AI, AI Skills) and for the new Real-Time Intelligence stack.

2. The Power Query Get Data redesign signals a broader Fabric UX consolidation. Microsoft has explicitly stated that the goal is a unified data-discovery experience across Power BI Desktop, Excel, and Fabric. For enterprises with mixed-tool environments (which is most enterprises), this consolidates the data-source governance surface from three editors to one.

3. Copilot Tooling Format GA matters for AI-ready semantic models. The previous storage pattern for Copilot metadata was awkward for Git-based development pipelines. The new format is text-based, diff-able, and merge-friendly. Enterprises that have held off on broader Copilot rollout because of source-control friction can now move forward.

The Power Query Get Data Redesign (Preview)

What changed

The legacy Power Query Get Data experience has been the same dialog box for nearly a decade — a list of categories on the left, connector tiles on the right, with several hundred connectors organized into nested folders. The discovery problem at enterprise scale was real: a typical Fortune 500 tenant has access to 80+ enterprise connectors across SaaS, on-prem, file, and database sources. Finding the right connector for a specific source took multiple clicks and tribal knowledge.

The May 2026 redesign (in Preview at release) introduces:

• Unified search across connectors, recent sources, OneLake shortcuts, and Microsoft Dataverse tables. Type "Dynamics 365 Finance" and the search returns the connector, the recently-used Dynamics 365 environments, and the existing OneLake shortcuts to Dynamics 365 data — in one ranked list.
• Accessibility-first keyboard navigation. Every action in the new Get Data experience has a keyboard shortcut. This is not a cosmetic change for enterprise tenants with accessibility-compliance requirements.
• Dark mode support. Both Power BI Desktop and Fabric are getting dark-mode treatment across the experience.
• Consistent experience across Microsoft Fabric, Power BI Desktop, and Microsoft Excel. A data engineer who learns the new Get Data in Fabric uses the same experience in Power BI Desktop and Excel. The Excel parity matters more than it might seem — Excel-based analyst populations are still numerically dominant in most enterprises.

Governance implications

For tenants with strict data-source approval governance (typically managed through a registered-data-source list, sometimes via Microsoft Purview Data Catalog integration), the Get Data redesign does not change the governance model — it changes the experience over the existing governance model. The governance team should:

• Verify the registered-data-source list remains visible in the new Get Data experience (it does, under the "Organizational" search scope).
• Update any internal training materials and recorded demos that reference the legacy Get Data flow.
• Confirm that Microsoft Purview Data Catalog integration continues to function in the Preview experience before broad enablement.

The Preview flag means the legacy experience remains the default during the rollout window. Plan to evaluate the new experience on a pilot group of data engineers before broader enablement.

Copilot Tooling Format: "Prep Data for AI"

The problem this solves

For enterprises adopting Microsoft Fabric Copilot in their analytics platform, the Copilot metadata layer has been the friction point. The Copilot capability depends on three categories of metadata that are not part of the underlying Power BI semantic model:

1. Synonyms. Multiple business terms that should resolve to the same model concept ("Net Revenue" = "Net Sales" = "Topline Revenue").
2. Description overrides. The natural-language description Copilot should use when summarizing a measure or column, which is often different from the technical name in the model.
3. Sample questions. The canonical questions Copilot should be ready to answer for this model, used to guide users and tune the language model.

Previously, this metadata was stored in a format that did not diff cleanly under Git. A change to a single synonym could produce a large, opaque diff that reviewers could not easily approve. Teams that had standardized on TMDL-based source control for their semantic models had to handle Copilot metadata through a separate process.

The May 2026 Copilot Tooling Format ("Prep Data for AI") fixes this. The format is text-based, file-per-concern (synonyms in one file, description overrides in another, sample questions in a third), and merges cleanly under standard Git workflows.

Repository layout for enterprise teams

EPC Group's recommended repository layout for a governed enterprise Fabric environment:

/fabric-tenant/
├── semantic-models/
│   ├── sales-finance/
│   │   ├── definition.tmdl
│   │   ├── model.bim (legacy fallback)
│   │   └── copilot/
│   │       ├── synonyms.json
│   │       ├── descriptions.json
│   │       └── sample-questions.json
│   └── operations/
│       └── ...
├── lakehouses/
│   ├── enterprise-bronze/
│   └── enterprise-silver/
├── pipelines/
│   └── ...
└── governance/
    ├── workspace-policy.yaml
    ├── capacity-allocation.yaml
    └── sensitivity-label-map.yaml

The Copilot metadata files live alongside the semantic-model definition. A change to a synonym goes through the same code-review process as a change to a DAX measure. The repository becomes the single source of truth for "what does this model know and how should it talk about it."

Governance pattern

For tenants where Copilot will be exposed to broad user populations, the Copilot Tooling Format raises three governance questions that should be answered before broad rollout:

1. Who can edit Copilot synonyms? A poorly chosen synonym can change how Copilot summarizes data in ways that the original author did not anticipate. Synonym changes should be peer-reviewed.

2. How are synonym changes audited? Git provides the change history. The auditor's question is "show me the synonym definition for 'Customer' as of January 1, 2026" — which Git answers cleanly with a tag or branch as of that date.

3. How are deprecated synonyms handled? Removing a synonym that users have been relying on can change Copilot's behavior in ways that surprise users. The deprecation pattern should be: mark the synonym as deprecated, monitor usage, remove only after a stable absence-of-use window.

Real-Time Intelligence in Fabric

The stack maturation

Real-Time Intelligence in Fabric is the consolidation of what was historically several separate Microsoft data streaming services (Azure Stream Analytics, Azure Data Explorer, Azure Event Hubs) into a unified Fabric experience. The May 2026 release advances three areas:

1. Eventhouse governance. KQL Database governance now respects domain-level RBAC. A KQL Database belonging to the Operations domain can be governed by Operations admins independently of the Sales domain's databases.

2. Data Activator reflex maturity. Data Activator (the rules-engine layer that triggers actions on streaming events) has reached the point where enterprises can move some action triggers out of Power Automate flows and into Data Activator. The trade-off: Data Activator is faster and observes streaming data natively; Power Automate is more flexible at the action side (broad connector library). The decision pattern is event volume — for high-volume streams (>100K events/hour), Data Activator wins on cost and latency.

3. Real-Time Hub integration. The Real-Time Hub in Fabric (the central place where streaming sources are registered) now integrates with the broader OneLake catalog and with Microsoft Purview Data Catalog.

When to use Real-Time Intelligence vs. batch Fabric

A common pattern enterprises encounter when evaluating Real-Time Intelligence: should the workload run on streaming infrastructure or on the existing batch Fabric pipeline? The decision matrix:

Workload pattern	Real-Time Intelligence	Batch Fabric (Dataflows / Pipelines / Lakehouse)
Latency requirement <1 minute	Yes	Hard to achieve
Latency requirement 5–60 minutes	Either; cost depends on volume	Typically cheaper at low volume
Latency requirement >1 hour	Usually batch	Yes
Event volume >1M/hour	Real-Time	Possible but expensive
Event volume <10K/hour	Either; batch usually cheaper	Yes
Need for streaming joins	Real-Time	Limited
Need for SCD2 / historical reconstruction	Either; pattern matters	Yes (cleaner)
Stakeholders are SQL-native	Either (KQL is the streaming query layer)	Yes

The hidden cost in Real-Time Intelligence is the capacity consumption of the always-on streaming workload. A small KQL Database serving a low-volume use case can consume 2–4 capacity units (CU) continuously, where the equivalent batch workload might consume the same CU for 10 minutes per hour. Capacity-planning is the dominant cost factor.

OneLake Governance Enhancements

The May 2026 release tightens OneLake governance in three practical ways:

Domain-level RBAC

OneLake domains (the organizational grouping above workspaces) now support more granular role-based access control. The pattern that enterprises typically struggle with — "this finance domain workspace should be visible to finance, but the workspace administrator role should not be available to finance individual contributors" — is now expressible without elevating permissions inappropriately.

Shortcut audit logging

OneLake shortcuts (the mechanism for surfacing data from one workspace into another without copying it) now generate audit log entries. For regulated industries, this closes a longstanding gap: previously, a shortcut to sensitive data could be created without leaving an audit trail. The new audit events are accessible through the Microsoft Purview Audit (Standard) experience and route to Microsoft Sentinel for tenants that have routed Fabric audit logs there.

Item lineage

Item lineage in Fabric (the visual graph showing data flow from source through transformations to consumption) has been enhanced to include OneLake shortcuts as explicit lineage edges. The compliance auditor's question "where did this data in this report come from" now has a clean answer that traverses both copied-data paths and shortcut paths.

The Premium-to-Fabric F-SKU Migration

Why the decision is now

For enterprises holding Power BI Premium P-SKU contracts approaching renewal, the migration decision has three components:

1. Feature parity. F-SKUs have access to features (Copilot, Real-Time Intelligence, OneLake shortcuts, Data Activator) that P-SKUs do not. Some of those features are now business-critical for enterprises that have built workflows around them.

2. Cost model. P-SKUs are a fixed monthly cost; F-SKUs are pay-for-what-you-use with pause-and-resume capability. For a workload with predictable peak hours, F-SKUs can be substantially cheaper. For a workload that is constantly active, P-SKUs can still be cheaper. The actual answer requires modeling against the specific tenant's consumption pattern.

3. Operational model. F-SKUs require active capacity management. A team that has been running P-SKUs without thinking about it will need to invest in capacity-consumption monitoring and tuning before they move to F-SKUs.

The phased migration pattern

EPC Group's enterprise migration pattern, refined across multiple Fortune 500 implementations, sequences as follows:

Phase 1: Capacity-consumption baseline (weeks 1–4).
Before any F-SKU is provisioned, install the Fabric Capacity Metrics app on the existing Premium P-SKU. Run it for a full month to baseline:

• Peak CU consumption by hour of day, day of week.
• Top consuming workspaces and reports.
• Background-operation consumption (refreshes, dataset updates).
• Burst patterns and the frequency of throttling events.

Without this baseline, F-SKU sizing decisions are guesses.

Phase 2: F-SKU pilot (weeks 5–10).
Provision a small F-SKU (F4 or F8 depending on the baseline) in a pilot region. Move 2–3 representative workspaces to the F-SKU. Validate:

• Performance parity with the original P-SKU.
• Capacity-consumption tracking against expectations.
• Copilot enablement for the pilot users (Copilot requires F-SKU).
• Audit-log routing to Microsoft Sentinel or wherever the regulated tenant routes them.

Phase 3: Governance overlay (weeks 11–14).
Before broader rollout, update the tenant's governance documents to reflect F-SKU operational patterns:

• Workspace-to-capacity assignment rules.
• Capacity pause/resume policy.
• Throttling response runbook.
• Capacity expansion approval process.
• Cost-allocation chargeback model.

Phase 4: Workspace-by-workspace cutover (weeks 15–24).
Move workspaces from P-SKU to F-SKU in a defined sequence. The sequence we recommend:

1. Lowest-risk, lowest-traffic workspaces first (typically governed-finance workspaces with scheduled refreshes).
2. Operational workspaces next.
3. Self-service / business-unit workspaces last.

For each workspace, the cutover is a workspace-administrator setting change in the Fabric admin portal. The cutover is fast (seconds); the validation window is longer.

Phase 5: Decommission P-SKU (weeks 25–26).
After all workspaces have been migrated and a stable validation window has passed, the P-SKU can be decommissioned. Plan for the contract renewal calendar — most P-SKU contracts have a notice period that needs to be coordinated.

Common migration pitfalls

Across the migrations we have guided, the patterns that cause problems:

1. Skipping the consumption baseline. Teams that provision F-SKUs based on their P-SKU size are usually wrong. P-SKUs are typically oversized; F-SKUs should be right-sized. The baseline is the only honest way to size.

2. Underestimating Copilot consumption. Once Copilot is enabled and promoted, CU consumption shifts. Capacity-planning should factor in Copilot from day one.

3. Not adjusting the chargeback model. If business units have been paying a flat allocation against the P-SKU, the move to F-SKU exposes the actual consumption variation. Some business units will pay substantially more under a consumption-based model. The conversation with finance and the business units needs to happen before the migration, not after the first bill.

4. Mixing P-SKU and F-SKU in production for too long. Workspaces moving between capacity types during a migration are normal. Workspaces staying split for months are a symptom of incomplete migration planning. Set a target end date and hold to it.

5. Forgetting Power BI Report Server (PBIRS). PBIRS is not part of the Fabric migration story. Any reports still on PBIRS need a separate decommissioning plan as part of the overall cloud-analytics modernization.

Governance for Regulated Industries

For enterprises in healthcare, financial services, or government with regulated-data scope, the Fabric migration adds compliance overlay work on top of the standard pattern.

Healthcare (HIPAA)

The HIPAA Privacy Rule and Security Rule continue to apply across the Fabric environment. The Fabric-specific overlay includes:

• Sensitivity label coverage on every semantic model serving certified reports, with PHI-containing models labeled Confidential or higher.
• Microsoft Purview audit log routing to a HIPAA-aligned SIEM (typically Microsoft Sentinel with a HIPAA-mapped analytic rule library).
• Workspace-level segregation of clinical, claims, and operational data with capacity-level access controls.
• Business Associate Agreement (BAA) coverage extending to Fabric (Microsoft's BAA does cover Fabric — verify the specific tenant's BAA includes the relevant services).

Financial Services (SOC 2 + SOX)

For financial services tenants, the SOC 2 Trust Services Criteria apply to the Fabric environment as a system supporting financial reporting:

• Change management around semantic models and reports must produce an auditable trail (Git-based development pipelines satisfy this when properly configured).
• Logical access controls (workspace roles, RLS, OLS) must be documented and reviewed periodically.
• System availability monitoring on capacities supporting SOX-relevant reporting.
• Capacity-level audit logging to a SIEM with appropriate retention.

Federal (FedRAMP)

For federal-sector tenants requiring FedRAMP-aligned hosting, Microsoft Fabric is available in Microsoft 365 GCC and GCC High tenants subject to the appropriate FedRAMP authorization scope. Verify the specific tenant's compliance posture before migrating workloads that require FedRAMP-aligned hosting.

EPC Group's Fabric Implementation Framework

For enterprises adopting Microsoft Fabric (whether greenfield or migrating from Power BI Premium), our standard implementation pattern:

Weeks 1–2: Discovery and architecture.

• Current-state assessment of existing Power BI / Azure Synapse / Azure Data Factory environments.
• Target-state architecture for Fabric.
• Capacity-consumption baseline (if migrating from Premium).
• Governance framework gap analysis.

Weeks 3–6: Foundation.

• OneLake tenant configuration and domain structure.
• Workspace structure and capacity allocation model.
• Source-control repository setup.
• CI/CD pipeline for Fabric items.
• Sensitivity label catalog (if regulated industry).

Weeks 7–12: Data platform.

• Lakehouse or Warehouse design depending on workload pattern.
• Pipeline implementations for the priority data sources.
• Bronze / Silver / Gold layer construction.
• Initial semantic-model implementations on the new platform.

Weeks 13–18: Analytics platform.

• Power BI reports rebuilt or migrated onto the Fabric semantic models.
• Copilot Tooling Format implementation for the priority models.
• Real-Time Intelligence implementations for the streaming workloads (if applicable).
• Data Activator reflexes for the alert use cases (if applicable).

Weeks 19–22: Adoption.

• User training across business-user, report-author, and developer personas.
• Change-management communications.
• Office-hours and support model launch.

Weeks 23–26: Optimization and handover.

• Capacity-consumption tuning based on production data.
• Performance optimization on the priority reports.
• Documentation handover.
• Center-of-Excellence stand-up if not already in place.

The 26-week timeline is for a Fortune 500 tenant with substantial existing Power BI estate. Smaller tenants and greenfield implementations run shorter; multi-region global implementations run longer.

Common Fabric Misconceptions

Across the implementations we have guided in 2026, the misconceptions that cause the most trouble:

1. "Fabric is just Power BI with a new name." Fabric is the unified intelligence platform. Power BI is one experience within Fabric. The architecture, capacity model, governance model, and operational patterns are different.

2. "OneLake is just Azure Data Lake Storage Gen2 with a new name." OneLake is the unified data layer for Fabric. It is built on Azure Data Lake Storage Gen2 but adds the OneLake catalog, shortcuts, domain governance, and direct compatibility with all Fabric experiences. Treating it as ADLS-G2 misses the integration value.

3. "We can just turn on Copilot and it will work." Copilot quality depends heavily on the metadata layer (synonyms, descriptions, sample questions). Without that investment, Copilot summaries are mediocre. With it, they are competitive with anything else in the market.

4. "F-SKU is just a license SKU change." F-SKU is a capacity-consumption model. The operational pattern is different from P-SKU. Teams need to learn the new pattern.

5. "Real-Time Intelligence is for high-volume streaming workloads only." Real-Time Intelligence is also valuable for low-latency operational reporting where the volume is modest but the freshness requirement is high.

Frequently Asked Questions

What is Microsoft Fabric?

Microsoft Fabric is Microsoft's unified intelligence platform, combining data ingestion, transformation, storage (OneLake), data science, real-time intelligence, and Power BI under a single SaaS experience and shared capacity model. It is the successor architecture to the Power BI Premium and Azure Synapse Analytics combinations that enterprises previously assembled separately.

Is Microsoft Fabric replacing Power BI Premium?

Power BI Premium (specifically the P-SKU offering) is not formally end-of-life, but Microsoft's product investments are concentrated on Fabric F-SKUs. Enterprises with Premium contracts should plan a migration to F-SKUs over a 12–24 month horizon. Power BI as a product experience remains and is delivered through Fabric F-SKU capacity going forward.

What is OneLake?

OneLake is the unified data layer for Microsoft Fabric, built on Azure Data Lake Storage Gen2 but with a unified catalog, shortcuts (zero-copy data sharing between workspaces), and domain-level governance. OneLake is the storage layer that all Fabric experiences (Power BI, Data Factory, Synapse Data Engineering, Real-Time Intelligence) read from and write to.

What is the Copilot Tooling Format ("Prep Data for AI")?

The Copilot Tooling Format is the May 2026 GA storage format for the metadata that makes Power BI semantic models work well with Copilot — synonyms (alternate business terms for model concepts), description overrides (the natural-language descriptions Copilot uses for measures and columns), and sample questions. The format is text-based, Git-friendly, and integrates cleanly into existing TMDL-based development repositories.

Do I need Fabric F-SKU to use Copilot in Power BI?

Yes. Copilot in Power BI requires Fabric F-SKU capacity (or Premium with an attached F-SKU Copilot capacity in some scenarios). The May 2026 Copilot Summarize feature is gated to F-SKU customers.

What is Data Activator in Fabric?

Data Activator is the rules-engine in Fabric Real-Time Intelligence that observes streaming data and triggers actions (email alerts, Power Automate flows, Teams notifications) when defined rule conditions are met. It is positioned for cases where the latency between event and action matters and where the action volume is non-trivial.

When should I choose Real-Time Intelligence over a batch Fabric pipeline?

Real-Time Intelligence wins when latency is <5 minutes and event volume is high (>10K events/hour). Batch pipelines win when latency tolerance is >1 hour or when the workload is intermittent and a capacity can be paused. Both can coexist on the same Fabric tenant.

Is Fabric available in Microsoft 365 GCC and GCC High?

Fabric availability in GCC and GCC High tenants depends on the specific region and the workload type. Verify the current availability matrix in the Microsoft Fabric documentation for the relevant GCC tier before committing to a federal-sector migration plan.

How does F-SKU capacity sizing work?

F-SKU capacities are sized in capacity units (CU). F2 is the smallest production F-SKU and consumes 2 CU. F-SKUs can be scaled up or down on demand and paused when not needed. Sizing requires a consumption baseline from the existing environment (typically captured via the Fabric Capacity Metrics app).

How does workspace-level access control interact with capacity-level access control?

Workspace roles (Admin, Member, Contributor, Viewer) control what a user can do within a workspace's contents. Capacity admin role controls who can administer the capacity itself (pause, resume, scale, assign workspaces). The two roles are independent. A user can be a workspace Member without having any capacity-level permissions.

What happens to my existing Power BI Premium reports during a Fabric migration?

Reports continue to function during the migration. The cutover is at the workspace-to-capacity assignment level — a workspace moves from Premium capacity to Fabric F-SKU capacity, and the reports within it use the new capacity. No report-level rework is required.

Can I run a Premium capacity and a Fabric F-SKU capacity simultaneously?

Yes. Most enterprise migrations run both in parallel for the cutover window (typically 6–12 weeks). The tenant's Fabric admin assigns workspaces to either capacity type as the migration progresses.

How do sensitivity labels work in Fabric?

Microsoft Purview sensitivity labels apply across the Fabric experience. Labels can be applied to semantic models, reports, lakehouses, warehouses, and individual files in OneLake. Labels propagate through derived items (a report inherits its model's label). Labels can also gate Copilot behavior — labeled Highly Confidential content typically blocks Copilot summarization.

How does EPC Group typically support a Fabric migration?

EPC Group works with Fortune 500 and regulated-industry enterprises across the full Fabric implementation lifecycle — discovery and architecture, migration sequencing, governance overlay, Copilot enablement, and post-launch optimization. The standard pattern is a 26-week engagement for a substantial existing-Power-BI tenant. The team includes senior architects with direct Microsoft Fabric implementation experience across hundreds of engagements, and our delivery pattern is compliance-native for HIPAA, SOC 2, and FedRAMP-aligned tenants.

What is the relationship between Microsoft Fabric and Azure Synapse Analytics?

Azure Synapse Analytics is the previous-generation unified analytics service that combined data integration, data warehousing, and Spark-based data engineering. Microsoft Fabric is the SaaS-first successor. New customers should start on Fabric. Existing Synapse customers have a documented migration path to Fabric that varies by workload (Synapse Pipelines → Fabric Data Factory; Dedicated SQL Pool → Fabric Warehouse; Spark Pools → Fabric Spark).

Next Steps

If your enterprise is running Power BI Premium and approaching a renewal decision, or if you are starting a greenfield Microsoft data platform build, the May 2026 Fabric features change the readiness calculation. The practical next steps:

1. Run the Fabric Capacity Metrics app against your current Premium capacity for at least 30 days.
2. Inventory your current Power BI estate (workspaces, semantic models, reports) and categorize each by migration complexity.
3. Run the Copilot data-readiness check on your top 20 certified semantic models.
4. Establish a Fabric source-control repository and stand up the CI/CD pipeline.
5. Engage a partner with hundreds of Fabric implementations in your industry segment to compress the planning timeline.

EPC Group has been delivering enterprise Microsoft analytics implementations for 29 years. We are Microsoft Solutions Partner with the core designations, and were historically the oldest continuous Microsoft Gold Partner in North America from 2016 until the program's retirement. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct Fabric implementation experience and a compliance-native delivery pattern refined across hundreds of regulated-industry engagements. To discuss your Fabric migration or greenfield implementation, contact EPC Group for a 30-minute discovery call.