Move Fabric ISVs from demo to governed delivery

Independent software vendors can add ingestion, governance, analytics, and industry workflows to Microsoft Fabric. A polished demonstration, however, does not show how a product will behave inside your data estate.

Treat every ISV solution as an architecture decision. The product must fit the workload, access model, operating team, and evidence required by the business.

Start with the job, not the catalogue

Describe the problem before comparing products. A useful brief states:

• the decision or process the solution supports
• the source and destination data
• required freshness, scale, and recovery targets
• the people and services that need access
• the result that will justify keeping it

This prevents a feature comparison from replacing the business case. It also gives technical and commercial teams one set of acceptance criteria.

Inspect the integration boundary

An extension may run inside Fabric, call Fabric APIs, or copy data to its own service. Those patterns create different risks.

Ask the vendor to show:

1. where code and data execute
2. which identities and permissions are required
3. what data leaves your tenant or region
4. how deployment and configuration are versioned
5. how monitoring, support, and incident ownership work
6. how you export data and remove the product

Microsoft’s Fabric permission model is a useful reference, but the vendor must document any additional control plane.

Test governance through the real path

Do not infer production behaviour from a sample dataset. Use representative identities and non-sensitive test data to confirm:

• workspace and item access
• OneLake and SQL access paths
• audit and lineage visibility
• failure handling and retry behaviour
• capacity use under expected concurrency

If the product depends on a preview API or Fabric item, record that dependency and an exit plan. A roadmap is not a support commitment.

Measure the change

Choose a baseline before the pilot. Useful measures include processing time, manual corrections, failure recovery, data freshness, or the time required to answer a defined question.

The measure should match the original job. A faster pipeline is not enough if reviewers cannot trace the data or the operating team cannot support it.

A delivery lesson from DCCEEW

Data-Driven’s work with the New South Wales Department of Climate Change, Energy, the Environment and Water shows why the platform foundation matters. The project replaced separate file, SSIS, warehouse, and reporting steps with a Fabric medallion architecture, scheduled pipelines, and curated Power BI reporting.

That case does not prove that every Fabric ISV will work. It does show the value of mapping sources, processing stages, and reporting responsibilities before adding more technology. Read the DCCEEW case study for the verified implementation detail.

An ISV earns a place in the platform when it improves a named workload without hiding access, cost, or support obligations.