How to Choose a Microsoft Fabric Consultancy

Navy Solv Systems title card reading 'How to Choose a Fabric Consultancy' with a checklist motif.

In Short: How to Choose a Microsoft Fabric Consultancy

Choosing a Microsoft Fabric consultancy comes down to three things: evidence they have built this before in a context like yours, clarity about who will do the work, and an engagement designed to end. Partner badges and capability decks narrow the field; they do not choose for you. The questions below are the ones we would want asked of us, and they separate delivery firms from sales firms faster than any slide.

If you are still working out what the role involves, start with what a Fabric consultant actually does. This guide assumes you have decided to bring someone in and now need to pick well.

What a Good Fabric Partner Actually Does

A good partner does more than configure workspaces. They get the business to agree what its core numbers mean, design a platform that will still make sense in three years, build it in a way your team can maintain, and leave that team able to run it.

In practice that covers integration from source systems, a layered lakehouse or warehouse design, semantic models, security and governance, capacity planning, deployment automation and, increasingly, the AI layer on top. A firm that is strong on reporting but vague on pipelines, or strong on engineering but uninterested in definitions, will leave a gap you pay to fill later.

One useful calibration on partner status: Microsoft's Solutions Partner for Data & AI (Azure) designation needs a partner capability score of at least 70 points, measured across performance (net new Azure customers), skilling (certifications, including the Fabric Analytics Engineer and Fabric Data Engineer associate certifications) and customer success. The Analytics on Microsoft Azure specialisation adds an audit, revalidated every other year. Microsoft also lists Fabric featured partners with recent Fabric deployment experience. These are reasonable filters. They measure consumption and certification, not whether the firm will get your finance and sales teams to agree on "revenue".

The Questions to Ask

Delivery and people

Can we speak to a client in our sector whose Fabric platform you built? Not a logo slide - a conversation, ideally with someone who still runs the platform.
Who will actually do the work, and will we meet them before signing? Ask for names, roles and the percentage of each person's time. Pitch teams and delivery teams are not always the same people.
What happens if a named person leaves mid-project?

Architecture

How do you approach medallion architecture - and when would you not use it? A thoughtful answer covers layer responsibilities, where business rules live and when a simpler design is better.
Where does governance sit in the plan? Access, classification, lineage and ownership should be designed in during the build, not scheduled as phase three.
How will you size our capacity? A credible partner talks about workload profiles, smoothing and monitoring before naming an F SKU. Our capacity sizing guide covers what a good answer sounds like.
How is work versioned and deployed? Fabric's Git integration supports Azure DevOps and GitHub. Expect a clear CI/CD approach with Git and deployment pipelines, with separate development, test and production.

Knowledge transfer and exit

What will our team be able to do afterwards that they cannot do now? Ask how that will be tested, not just delivered.
Who owns the code, notebooks, models and documentation? The answer should be "you", held in your own repository from the first day.
How does this engagement end? A partner without a clear answer is describing a dependency.

Commercial Models, Fairly Compared

Most Fabric consultancies offer some mix of three models, and the right one depends on how well defined the work is.

Fixed bid - a defined outcome for a defined price. It forces the supplier to price the risk and think about the work rather than the days. It suits a clear first use case with known sources. The trade-off is that changes cost money, so scope must be written precisely.
Time and materials - you pay for time spent. It suits discovery-heavy or evolving work. The trade-off is that risk sits with you, so insist on weekly reporting of effort against scope.
Managed service - ongoing capacity for support and incremental change. It suits a working platform without a permanent in-house team. The trade-off is dependency, so check notice periods and handover terms.

A sensible proposal often combines them: a fixed-price first phase, then time and materials or a managed service once the platform exists. Be wary of any firm quote given before someone has looked at your source systems. A price offered without seeing the data is a price that will change.

Red Flags

A discovery phase whose only deliverable is a document.
Architecture recommendations before anyone has asked which decisions you want to make differently.
Senior people in the pitch, unnamed "resources" in the statement of work.
Code held in the supplier's repository or tenant, with transfer "on request".
Capacity sized by instinct, with no plan for monitoring consumption.
No mention of testing, deployment or environments.
Reluctance to provide a reference you can actually phone.
Every answer leads to a larger scope.

How to Compare Proposals

Proposals are hard to compare because each firm frames the work differently. Normalise them before comparing prices:

Map every proposal to the same outcomes. List the use cases, sources and reports you expect and check each proposal covers them. Gaps are often where the low bid came from.
Compare named effort, not totals. Days by role and seniority tell you more than the headline figure.
Check what is excluded. Data quality remediation, testing, security design, training and hypercare are common silent exclusions.
Look for something in production early. A first phase that ends with a report people actually use is worth more than one that ends with a roadmap.
Read the assumptions. They show you where the price will move.

Then score against criteria you set before the pitches, weighted to what matters to you. It keeps the decision about delivery rather than presentation.

Boutique vs Global SI: The Honest Trade-Offs

Both can be the right answer, and it is worth being fair to each.

Global systems integrators bring breadth and bench depth. If your Fabric work is one workstream in a wider programme - an ERP replacement, a multi-country transformation, a large Azure AI build with heavy compliance and procurement requirements - their ability to staff many teams at once, absorb contractual risk and cover many technologies under one agreement is valuable. The trade-offs to probe are how senior the delivery team is, and how much of the price is overhead.

Boutiques tend to put senior practitioners on the work, decide quickly and cost less. The people who scope the work usually build it. The trade-offs are thinner bench depth, less capacity to scale a programme suddenly and narrower technology coverage. Ask what happens if a key person is unavailable.

For a single-platform Fabric build, the named team usually matters more than the size of the firm. For a sprawling multi-vendor programme, scale can matter more. The same questions apply to both.

What It Typically Costs

Costs vary by scope, region and seniority, and we would rather point you to proper ranges than quote a number out of context. Our regional guides set out typical budgets by implementation profile, alongside the Fabric capacity costs that sit on top: the UK Fabric implementation cost guide, the US Fabric implementation cost guide and the South Africa Fabric implementation cost guide.

When you are ready to name names, our shortlists of Fabric and Power BI consultancies in the United Kingdom, the United States and South Africa are a starting point for the questions above.

Where Solv Systems Comes In

We are a boutique Microsoft Partner specialising in Fabric, Power BI and AI, with 147+ projects delivered. Our teams are in the UK and South Africa and we deliver remotely into the UK, the US and South Africa. Engagements run as fixed bid, staff augmentation or an ongoing managed service, and the senior people you meet are the people who do the work.

The honest limitation: we are not a global SI, and if your programme needs dozens of consultants on site across several countries, we are not the right fit. If you want a straight answer on your situation - including whether you need a consultancy at all - our Microsoft Fabric consulting page explains how we work, and a free 30-minute consultation costs nothing but the time.

Sources and Further Reading

Frequently asked

Ask for delivery references in your sector, who will actually do the work, how they approach medallion architecture, governance and capacity sizing, how code is versioned and deployed, how knowledge transfer is measured, which commercial model they propose and why, and who owns the code and documentation when the engagement ends.

It is a useful filter, not proof. The Solutions Partner for Data & AI (Azure) designation is scored on Azure customer growth, certifications and customer success metrics, with a minimum of 70 points. Specialisations such as Analytics on Microsoft Azure add an audit. Neither replaces a conversation with a client whose Fabric platform the firm built.

Fixed bid suits a defined first outcome with known sources, because it makes the supplier price the risk. Time and materials suits discovery-heavy or evolving work, provided you have weekly visibility of burn against scope. Managed service suits a platform that already works and needs ongoing care.

It depends on scope. Global SIs bring breadth, bench depth and the ability to run large multi-workstream programmes. Boutiques tend to offer senior people doing the work, faster decisions and lower cost. For a single-platform build, the named team usually matters more than the size of the firm.

It depends on scope, region and seniority. Our regional guides for the UK, the US and South Africa set out typical budgets by implementation profile. Fabric capacity is billed separately by Microsoft and should be costed alongside consulting fees.

You should. Agree in the contract that code, notebooks, pipelines, semantic models and documentation are yours, stored in a Git repository in your own Azure DevOps or GitHub organisation from day one, so an exit does not depend on the supplier's goodwill.