Back to Blog

Microsoft Fabric Consulting - What a Good Engagement Looks Like

May 7, 2026•11 min read•Michael Ridland

If you're shopping around for a Microsoft Fabric consultant right now, you've probably noticed something odd. Every firm uses the same words. Lakehouse, OneLake, Direct Lake, medallion architecture, capacity governance. The slide decks are practically interchangeable. But the actual outcomes between a good Fabric engagement and a bad one are night and day.

I want to walk you through what we look for when we scope a Microsoft Fabric project, the milestones that matter, the pricing ranges you should expect in AUD, and the warning signs that should make you pause before signing a statement of work. This is the post I wish more buyers had read before calling us to clean up someone else's Fabric mess.

What Fabric consulting actually covers

Microsoft Fabric is not a product. It's a bundle of products sitting on a shared capacity model. Data Factory, Synapse Data Warehouse, Synapse Data Engineering (Spark), Real-Time Intelligence, Power BI, Data Activator, and the Fabric copilots all live under the same SKU. A good consulting engagement has to be specific about which of these you're actually deploying, because each one has its own quirks.

Most engagements we see fall into one of four buckets:

  1. Greenfield Fabric platform build - new tenant, capacity sizing, OneLake setup, security model, first medallion architecture
  2. Migration into Fabric - moving from Synapse, Databricks, on-prem SQL, or a legacy Azure data factory setup
  3. Fabric expansion - already have Power BI Premium or a small F-SKU, now scaling out workloads
  4. Fabric remediation - the previous build is bleeding money or performance is terrible and someone needs to fix it

The fourth category is growing faster than we'd like. We had a client in Brisbane last quarter who'd burned through almost $180k AUD in capacity costs across nine months because the original consultants set up a single F64 with no workspace governance, no DirectLake optimisation, and no capacity scaling rules. Three weeks of restructuring saved them about $9k a month going forward. The original build looked fine on paper. It just wasn't designed for the workload.

Pricing ranges you should expect in AUD

I'll be more specific here than most posts will be, because vague pricing helps nobody. These are ranges we see in the Australian market for genuine senior Fabric work:

Engagement type Duration Typical cost (AUD)
Fabric discovery and architecture 2-4 weeks $35k - $70k
Greenfield platform build (one domain) 8-12 weeks $120k - $250k
Migration from Synapse or Databricks 12-20 weeks $180k - $450k
Fabric remediation and optimisation 3-6 weeks $45k - $110k
Ongoing managed service Per month $8k - $35k
Fixed-rate senior consultant day rate Daily $1,800 - $2,600

If you're being quoted significantly below the bottom of these ranges, ask hard questions about who's actually delivering. We've seen too many engagements where a brand-name firm wins the work and then staffs it with two graduates and a remote offshore team. The hourly rate looks fine. The output is a Fabric environment that nobody can maintain.

If you're being quoted significantly above these ranges, ask what's actually being delivered. Fabric is genuinely simpler to stand up than the old Synapse + Data Factory + dedicated SQL pool approach. A six-figure cost should map to six-figures of value, not a thick deck and a half-finished medallion architecture.

The five phases of a good Fabric engagement

A well-run Fabric project has a predictable shape. If your proposed engagement is missing any of these phases, push back.

Phase 1 - Discovery and capacity sizing (1-2 weeks)

This is where a good consultant earns their fee before they touch any code. We need to understand your data volumes, refresh patterns, concurrency requirements, and which workloads you're actually planning to run. F-SKU sizing is not a guess. An F32 versus an F64 is a $50k+ AUD per year decision and most clients get it wrong because they were sold on the marketing instead of the workload.

A serious discovery output includes:

  • Capacity sizing recommendation with workload modelling
  • OneLake structure proposal (domains, workspaces, lakehouses)
  • Security and governance model
  • Data ingestion patterns mapped to specific source systems
  • A realistic timeline with named dependencies

If discovery hands you a recommendation that says "F64 with standard medallion architecture" with no workload analysis behind it, that's a copy-paste deliverable. Walk away.

Phase 2 - Foundation build (2-4 weeks)

The foundation is the boring stuff that determines whether you'll be happy in 18 months. Tenant configuration, OneLake structure, domains and workspaces, capacity assignment, security groups, sensitivity labels, deployment pipelines, source control integration with Azure DevOps or GitHub.

We've seen Fabric tenants where every developer has admin access to every workspace, no source control is wired up, and there's no separation between dev, test and production. It works fine for the first six weeks. By month four, three people have made conflicting changes to the same semantic model and nobody can roll back. Foundation work is the cheapest insurance you'll ever buy.

Phase 3 - First domain delivery (4-8 weeks)

Pick one domain. Sales, finance, operations, whatever has the clearest data and the most engaged stakeholders. Build it end-to-end. Ingestion via Data Factory or Dataflow Gen2 pipelines. Bronze, silver, gold tables in the lakehouse. A semantic model in Direct Lake mode. Two or three Power BI reports that actually answer business questions.

The reason to pick one domain is that you'll discover all the patterns and decisions you need to repeat for every other domain. Trying to do three domains in parallel before you've solved the first one is how projects slip from twelve weeks to nine months.

Phase 4 - Handover and capability transfer (1-2 weeks)

This is the phase that bad consultants skip. A good Fabric engagement leaves your team able to extend the platform without us. That means:

  • Documented patterns for adding new pipelines and tables
  • Workshops on Direct Lake, DAX, and Spark notebook patterns
  • Runbooks for capacity monitoring and cost management
  • A clear escalation path if something breaks

If the consultant's commercial model depends on you not being able to maintain the platform yourselves, they're not aligned with you. Ask the question directly during procurement.

Phase 5 - Ongoing optimisation

Fabric capacity costs drift. Refresh patterns change. New use cases get added. A small monthly engagement, typically 1-3 days per month at our end, keeps the platform healthy. This is optional and you should be able to walk away from it without your environment falling apart.

Red flags during the sales process

Some patterns we've noticed when reviewing proposals from other firms on behalf of clients:

"We have a Fabric accelerator"

Sometimes accelerators are great. Sometimes they're a generic template that ships you a workspace called "Bronze" and a notebook with three lines of code. Ask to see the accelerator in action against your actual data before you sign anything.

No named individuals on the proposal

If the proposal says "team of senior consultants" without naming who'll be on the engagement, you'll get whoever is on the bench. Ask for LinkedIn profiles of the actual delivery team. Their backgrounds tell you more than the firm's website.

Vague capacity sizing

"We'll start with F64 and scale as needed" is not a sizing recommendation. It's a way of starting your invoice at $11k AUD per month before any work happens. A good consultant will model your actual workload first.

No mention of governance or source control

If the proposal is all about delivery and nothing about governance, you're buying a sandcastle. Tides come in.

Pricing that's wildly cheaper than competitors

I know this sounds self-serving from someone selling Fabric work. It isn't. We've cleaned up too many cheap engagements where the savings on day one became a six-figure remediation bill in year two.

When Fabric is the right call and when it isn't

Fabric works really well when:

  • You already use Power BI heavily and want consolidated data infrastructure
  • Your team has Microsoft skills more than open-source data engineering skills
  • You want to avoid managing separate services for ingestion, storage, and BI
  • You have predictable workload patterns that map to F-SKU pricing

Fabric is the wrong call when:

  • Your data volumes are tiny and Azure SQL plus Power BI Premium would be cheaper
  • You need very specific open-source patterns that Fabric's Spark doesn't support well
  • Your team is deeply skilled in Databricks already and the migration cost outweighs the consolidation benefit
  • You have spiky, unpredictable workloads that don't fit reserved capacity pricing

We've talked clients out of Fabric in maybe one in eight engagements. Usually the answer is a smaller Power BI consulting engagement plus a Microsoft Data Factory build, not a full Fabric platform. The right answer depends on your data volumes, your team's skills, and your appetite for managing multiple services.

What we actually deliver on a Fabric engagement

I'll be specific about what a Team 400 Fabric engagement looks like, because abstract talk is useless when you're trying to compare proposals.

A typical 10-week build delivers:

  • Production-ready Fabric tenant with workspace governance
  • One domain end-to-end (typically 8-15 silver/gold tables)
  • Direct Lake semantic model with optimisation for your concurrency needs
  • 3-6 production Power BI reports
  • Source control integration and CI/CD pipelines
  • Capacity monitoring dashboard
  • Documented patterns and runbooks
  • Two workshop days for your data team

That's a $140k - $200k AUD engagement depending on complexity. Senior Australian-based consultants throughout. No graduates running pipelines into production.

Common objections we hear

"We can do this ourselves with a smaller internal team."

You probably can. The question is opportunity cost. If your data team spends six months figuring out Direct Lake gotchas instead of building business value, that's a real cost. A focused 10-week engagement that hands over working patterns is usually faster and cheaper than self-discovery. We have clients who started with the DIY approach, spent four months getting stuck on capacity governance, and called us in to get them unstuck.

"Our existing partner says they can do Fabric."

Most Microsoft partners can do something called Fabric. The question is whether they've delivered five or more production Fabric platforms across Australian businesses. Ask for case studies with named clients you can call. Real Fabric experience in Australia is still relatively rare in 2026 because the product hasn't been generally available for that long.

"We need to wait until Fabric is more mature."

This was a reasonable position in 2024. It's no longer reasonable. Fabric is now feature-complete enough for most enterprise workloads, the pricing model is stable, and the migration path from Synapse is well-trodden. Waiting longer just delays value. The exception is very specific real-time streaming workloads where the Real-Time Intelligence side of Fabric still has rough edges.

How to actually pick a Fabric consultant

A practical checklist for procurement:

  • Has the firm delivered five or more production Fabric platforms?
  • Are the named consultants on the proposal genuinely senior with Microsoft backgrounds?
  • Does the proposal include specific capacity sizing based on your workload?
  • Is there a clear governance and source control plan?
  • Is there a defined handover phase?
  • Can you talk to two existing clients about their experience?
  • Is the firm Australian-based with consultants who'll be on the ground?
  • Does the commercial model align with your success or with extending the engagement indefinitely?

If you can tick most of these boxes, you're looking at a serious proposal.

A final note on engagement style

The best Fabric engagements we run feel like extensions of the client's team rather than vendor relationships. We sit in your standups, your business stakeholders talk to our delivery team directly, and decisions get made fast. The worst engagements we see from other firms involve three layers of project management, change request gates for every minor decision, and consultants who never meet the business users they're building reports for.

If you're early in your Fabric journey or trying to fix a build that hasn't worked out, we'd be happy to have a no-pressure conversation about what you're trying to achieve. Our Microsoft Fabric consultants team has delivered production Fabric platforms across financial services, healthcare and manufacturing clients in Australia. We're also happy to review a competing proposal and give you an honest read on whether it's reasonable.

Get in touch with the team if you'd like to talk through your situation, or take a look at our broader data and AI services to see how Fabric fits into your wider strategy. If you're earlier in the journey and still figuring out whether Fabric is the right call versus other Microsoft data options, our AI opportunity planner is a useful starting point.

The right Fabric engagement should leave you with a platform your team can extend, costs you can predict, and reports your business actually uses. Anything less than that and you've been sold something rather than delivered something.