The questions people actually ask.

Straight answers, including the ones where the answer isn't entirely in our favour. If something you need isn't here, ask us on a call and we'll tell you plainly.

The product

What is the Fabric Accelerator?

It's a working Microsoft Fabric data platform that already exists. Rather than designing and building one for you from a blank page, we deploy ours into your Microsoft tenant and configure it to your source systems.

Underneath, it's a metadata-driven framework. The pipelines that move your data aren't written per customer: they read their instructions from configuration held in a database, so connecting a new system means describing it through an interface rather than developing something new. That's why a deployment takes four weeks rather than most of a year.

You can click through the actual interface without booking anything.

How is this different from building pipelines from scratch?

A bespoke build produces one pipeline per source, each written by hand, each needing its own testing and its own maintenance. It works, but the cost lands twice: once when it's built, and again every time something changes.

The Accelerator inverts that. One framework handles every source, and what differs between sources is configuration rather than code. Three consequences follow:

  • It's already tested. The framework has been proven across 60+ Fabric deliveries. A bespoke build is tested for the first time on your project.
  • Improvements arrive automatically. When we improve the framework for another client, you get it. Bespoke code only improves when someone pays to improve it.
  • There's less to maintain. Fewer moving parts, documented in one place, rather than accumulated logic that only its author fully understands.
Running it

How long does onboarding a new data source take?

For a standard source such as SQL Server, Azure SQL, SharePoint, a CSV feed or a Dataverse environment, it's typically a matter of hours rather than days. You define the connection, choose the tables, set how each one loads and how it's keyed, and the framework does the rest.

More involved sources take longer. An unusual API, an on-premises system behind a gateway, or a source needing significant business logic before it's usable will need proper effort. We'd rather say that up front than discover it in week three.

Managed service tiers include a set number of source systems, and continuous improvement days can be spent on adding more. If you're likely to add sources steadily rather than all at once, that's worth raising when we scope the tier.

What happens to our existing Power Platform or Fabric investment?

It stays, and in most cases it gets better. The Accelerator sits underneath your reporting rather than replacing it.

Existing Power BI reports typically point at operational databases directly, which is why they slow down as the business grows and why two reports can disagree. Repointing them at a governed data layer usually makes them faster and more consistent without rebuilding them.

The same applies to Power Apps, Power Automate and Dynamics. They carry on as they are, and they become sources the platform can read from, so the data they hold stops being stranded in one system.

What Fabric capacity do we need?

Less than most people expect. The Accelerator runs identically on F2, the smallest paid Fabric SKU, as it does on the largest enterprise capacities. There's no feature compromise at the small end: dynamic data masking, row-level security, the GraphQL API and Copilot in Fabric are all available.

Two things reduce the cost further. Capacity can be paused outside business hours, which for most mid-market workloads more than halves the effective spend. A one-year reserved commitment takes roughly 40% off the list price.

If you'd rather not manage that at all, we can hold the capacity licensing for you, which also takes 5% off your managed service fee.

What governance and security is built in?

Governance is part of the architecture rather than a phase that gets added later, which matters because the later version rarely gets funded.

  • Identity. Authentication through your existing Microsoft Entra ID, with role-based access. No separate user directory to manage.
  • Personal data. Column-level masking defined in configuration and applied at the query endpoint, so unauthorised users see masked values rather than relying on people remembering which report to avoid.
  • History. Raw data is landed append-only and retained, and changes to dimensions can be versioned, so you can reconstruct what a figure looked like at any point rather than only what it looks like now.
  • Audit. Every configuration change is logged, and every load is tagged so you can trace a row back to the run that produced it.
  • Location. Everything runs inside your own Microsoft tenant. Your data doesn't move to us.

For an ISO 27001, SOC 2 or sector-regulator conversation, that's usually the bulk of what an auditor asks about, and we can walk them through each control.

What do you need from us during the four weeks?

Less than a build project needs, but not nothing, and it's worth being honest about it because this is where deployments slip.

  • Access. A Fabric workspace, an Entra tenant, and credentials or a gateway route to each source system. Getting this arranged is usually the longest lead time, so we start it before week one.
  • Someone who knows the source systems. A few hours across the four weeks, not a full-time secondment. We need to know which tables matter, what the keys are, and where the known oddities are.
  • Someone to make decisions. Definitions need agreeing. If two departments count customers differently, that's a business decision, not a technical one, and we can't make it for you.
  • A couple of sessions. A kickoff, a mid-point review, and a handover, plus training for whoever will run it.

What we don't need is a project team, a steering group, or your IT staff writing anything.

The relationship

What happens if we want to bring this in-house afterwards?

Two separate things sit inside that question, and they have different answers.

Your data is unambiguously yours. It's held as open Delta Lake tables in your own OneLake, in your own tenant. Anything that reads Delta or Parquet can read it, including Databricks, Snowflake or your own Spark environment. There's no proprietary format and no export process to negotiate. If you walked away tomorrow, your data would still be sitting there in a form anyone can use.

The framework itself is licensed rather than sold. It's the product we maintain and improve for every client, so continued use runs alongside a licence in the same way any software would. If a licence ends, we work through the transition with you rather than leaving you to discover it, and we'll tell you what your options look like before you sign anything, not afterwards.

Running it day to day is a different matter entirely, and that genuinely can come in-house. The platform is designed to be operated by your own team through configuration, and we'd rather train them properly than manufacture a dependency. Plenty of clients take the managed service for the first year and step down once their people are confident.

Will we have direct access to the people building this, or will we be handed off to account management?

We're a small team, so the person you speak to is generally the person doing the work. There isn't a layer of account management between you and the platform, and there isn't an offshore delivery team you've never met.

Being straight about the tiers: Elevate includes a named consultant who knows your platform and stays with it. Accelerate gives you priority support and a monthly review with the people who run your environment. Essentials is a helpdesk arrangement rather than a named relationship, which is part of why it costs what it does.

What doesn't change by tier is who's on the other end. It's the same team either way.

How does this compare with engaging a larger consultancy or systems integrator?

The honest answer is that it depends on what you're buying, and the difference isn't really about quality.

A large integrator sells a project. That model needs a project manager, a business analyst, an architect, a technical lead, developers and testers, because a blank page needs all of those roles. It's a legitimate way to work and it suits genuinely bespoke problems. It also means you fund the design, the build and the corrections, and you find out what you bought at the end.

We sell a product that already exists. The design, build and correction phases happened before you arrived, so what's left is configuration. That's why the price is fixed and the timeline is four weeks rather than most of a year.

There's a second difference worth naming. A day-rate business does better when work takes longer. A product business does better when the platform works and you stay. Those incentives point in different directions, and it's reasonable to ask any supplier which one describes them.

Where an integrator is genuinely the better choice: if your requirement is unusual enough that no product fits it, you should build something bespoke. We'd tell you that on the call.

The cost comparison behind this, with published market rates and the working shown, is on the overview page.

Still got a question we haven't answered?

Ask it on a call. If the answer is that the Accelerator isn't right for you, we'll say so then rather than three weeks into a discovery phase.

A client partner first.