Microsoft Fabric Adoption Guide for Indian Enterprises: Capacity, Skills and a 90-Day Plan
How Indian enterprises adopt Microsoft Fabric: capacity SKUs and cost control, India data residency, OneLake and the medallion lakehouse, which teams need DP-600, DP-700 or PL-300, and a 90-day rollout plan.
What Fabric is, in one paragraph
Microsoft Fabric is a software-as-a-service analytics platform that brings together the workloads enterprises used to buy separately: data integration, data engineering with Spark, data warehousing, real-time intelligence, data science and Power BI. They share one storage layer, OneLake, which stores data once in an open format so every workload reads the same copy. Power BI can read that storage directly through Direct Lake without importing or querying through a warehouse. Licensing is by capacity rather than by workload.
If your organisation already runs Microsoft 365 and has Power BI in use, Fabric is less a new platform than the platform your reports already live on, with the data engineering added.
Why Indian enterprises are looking now
- Consolidation. Banks, manufacturers, pharma companies and IT services firms in India commonly run Power BI alongside a separate warehouse, a separate ETL tool and a growing pile of dataflows. Fabric collapses the licensing and the integration work.
- Existing footprint. Identity in Microsoft Entra ID, data in SharePoint and Dynamics, and a Power BI tenant are already there. The adoption cost is capacity and skills, not a new vendor.
- Residency. Azure regions in India make it possible to keep data in-country, which matters for regulated sectors. Confirm current Fabric region availability before creating the capacity; see the FAQ below.
- Skills supply. DP-600 and DP-700 have become recognisable in Indian hiring, and the training ecosystem for them has matured. See DP-600 vs DP-700 for how the two fit together.
Capacity planning without surprises
Fabric is bought as capacity, in F SKUs that scale from very small to very large, either pay-as-you-go or reserved through Azure. A few rules that save money:
- Start small and measure. The Capacity Metrics app shows what each workload consumes. A pilot on a small capacity teaches you more about your real usage than any estimate.
- Understand smoothing and throttling. Fabric smooths bursts of usage over time, and a capacity that is consistently over its limit will throttle or reject jobs. Spark jobs and heavy refreshes should be scheduled, not run ad hoc during business hours.
- Pause what you are not using. Pay-as-you-go capacity can be paused outside working hours during a pilot. Reserve capacity only once the usage pattern is known.
- Separate dev from prod. Two small capacities are cheaper than one large one that a development notebook can bring down.
- Use the trial deliberately. A Fabric trial is available for evaluation; check the current terms. Treat it as a timed pilot with an exit plan, not as a free production tier.
The architecture that works first time
The medallion lakehouse pattern, Bronze for raw data, Silver for cleaned and conformed data and Gold for business-ready tables, is the right default for most Indian enterprises because it separates ingestion problems from modelling problems. Our medallion architecture guide explains the layers in detail. Two decisions to make early:
- Lakehouse or warehouse for Gold? Teams with strong SQL skills and transactional reporting needs often prefer the warehouse; teams with Spark skills and semi-structured data prefer the lakehouse. Both can serve Power BI through Direct Lake.
- One workspace per domain, not per report. Finance, sales, operations and HR get their own workspaces and their own Gold layer, with a shared Silver where the conformed dimensions live.
The skills map
Fabric adoption fails on skills more often than on technology. Map the roles before the capacity is created:
- Data engineers: pipelines, notebooks, Spark, Dataflows Gen2, real-time ingestion. Certification: DP-700.
- Analytics engineers: semantic models, Direct Lake, performance, security, the Gold layer. Certification: DP-600.
- Analysts and report builders: reports, DAX measures, workspaces, apps. Certification: PL-300.
- Architects and leads: all three at the concept level, plus capacity management and governance.
Train the platform team before the pilot, not during it. A team learning Spark on production data in week three of a pilot makes expensive mistakes.
A 90-day plan
Days 1 to 30: foundation. Create the capacity in the right region, set up the admin settings, dev and prod workspaces, and the domain structure. Train the platform team (DP-700 and DP-600 tracks run in parallel over the month). Choose one business domain with a visible problem and a friendly sponsor as the pilot.
Days 31 to 60: the pilot lakehouse. Ingest the pilot domain's sources into Bronze, conform them in Silver, build the Gold tables and one semantic model over Direct Lake. Rebuild the two or three reports the sponsor uses weekly on the new model, side by side with the old ones, and reconcile the numbers until they match.
Days 61 to 90: production and governance. Move the pilot to the production workspace with scheduled pipelines and alerts. Write the standards that came out of the pilot: naming, workspace structure, refresh windows, security model, cost monitoring. Train the analyst community on the new model. Pick the second domain.
At the end of ninety days you have one domain in production, a trained team, standards written from experience rather than from a template, and a cost figure from real usage. That is the point at which a wider rollout becomes a decision rather than a hope.
Common failure modes
- Migrating every report at once. Pick the reports that matter and let the long tail retire.
- Treating Direct Lake like Import. Semantic model design and data types in the Gold layer determine whether Direct Lake performs; a model built as if it were Import falls back to DirectQuery and nobody knows why.
- No Centre of Enablement. Someone must own standards, capacity and the backlog of requests. Without that, every domain reinvents the lakehouse.
- Skipping the Power BI migration plan. Our Power BI to Fabric migration guide covers what to move, in what order, and what to leave.
Training your platform team
CertTulen Academy India delivers DP-600 and DP-700 as live, instructor-led courses for enterprise teams, on-site anywhere in India or online in IST, taught by Microsoft Certified Trainers who hold both certifications. Programmes are quoted in INR with GST-compliant invoices, and can be scheduled around your adoption plan so the team trains before the pilot rather than during it. See the corporate training page, download the Fabric brochures, or contact us to scope it.
Frequently asked questions
Do we need to move off Power BI to adopt Fabric?
No. Power BI is part of Fabric, and existing reports and workspaces carry on working. Adoption usually means adding Fabric capacity, creating a lakehouse or warehouse for the data that is currently scattered across dataflows and spreadsheets, and progressively pointing the semantic models at it. Our migration guide covers the sequencing.
Can our data stay in India?
Fabric capacity is created in an Azure region, and Microsoft operates regions in India. Confirm the current Fabric availability for the India regions and your sector's residency requirements with your Microsoft account team before you create the capacity, because the home region of a tenant and the region of a capacity are set at creation time.
Who on the team should be certified, and in what?
The people who build the lakehouse and the pipelines take DP-700. The people who design the semantic models and own the analytics layer take DP-600. Report builders and analysts take PL-300. A platform team of five or six typically needs two of each of the first two and the rest on PL-300, with one architect across all three.
