Microsoft Fabric ADBC Migration: Prevent the ODBC Driver Cutover from Breaking Enterprise Workloads

Executive summary

Microsoft is moving supported Power BI and Microsoft Fabric connectors from embedded Open Database Connectivity (ODBC) drivers to replacement drivers based largely on Apache Arrow Database Connectivity (ADBC). The affected list includes Databricks, Azure Databricks, Dremio, Google BigQuery, Impala, Snowflake, and Spark; the embedded Hive connector is being deprecated. As of 29 September 2026, Microsoft plans to begin enabling the ADBC tenant setting by default in phases in October 2026, begin removing the affected ODBC drivers from the service in early Q1 2027, and stop shipping them with Power BI Desktop and the on-premises data gateway in spring 2027. These dates are planned and subject to rollout readiness. Microsoft's transition guidance

This is not merely a driver upgrade. A connection can behave differently depending on its Power Query M code, workspace setting, tenant setting, cloud or gateway execution path, connector version, authentication method, and source-specific options. A refresh that succeeds is not sufficient proof: type coercion, decimal and timestamp precision, query folding, row-level results, memory consumption, source permissions, or performance may still change.

Enterprise technology leaders should govern the transition as a portfolio migration with five controls:

1. Build an owned inventory of every affected connection and its downstream business service.
2. Establish an explicit execution contract for driver, route, identity, permissions, and source options.
3. Compare ODBC and ADBC results with production-shaped data and business-level reconciliation.
4. Roll out by risk tier through pilot workspaces and controlled waves, with time-bound rollback criteria.
5. Retire ODBC dependencies before temporary gateway-based deferrals become unsupported technical debt.

The objective is not simply “ADBC enabled.” It is verified continuity of trusted decisions, within agreed freshness, accuracy, security, performance, and cost boundaries.

The enterprise problem: an invisible dependency is changing

Drivers sit below the dashboards and dataflows that business teams see. They translate Power Query requests into a source system's protocol, expose metadata, map native data types, move result sets, and participate in query folding, where filters and transformations are pushed down to the source. Changing that layer can affect both whether a workload runs and what it returns.

Microsoft describes ADBC as a standard interface for working with Apache Arrow data. Arrow's columnar batches can retrieve large result sets without row-by-row serialization and copying, offering a more modern path for performance and driver security. However, the business risk comes from changing a mature execution dependency across a large, only partly inventoried analytics estate. Microsoft's ADBC connector development overview

The transition affects connections created through the named first-party connectors. It does not change the generic Power Query ODBC connector when an organization supplies a separately installed ODBC driver. That distinction matters during discovery: searching only for the word ODBC will both miss affected unpinned connector calls and include generic connections outside this particular transition.

Why the timing matters now

Microsoft's current schedule creates a narrowing validation window:

These are Microsoft-planned dates, not a guarantee that every tenant changes on the same day. The phased nature of the rollout is a reason to record actual tenant and workspace state, not a reason to wait. Transition key dates and gateway behavior

Representative enterprise scenario

The following scenario is representative, not a YuniQ customer case or a claim of achieved results.

A multinational services group uses Snowflake and Azure Databricks for finance, operations, and customer analytics. Power BI semantic models support executive reporting; Dataflows Gen2 prepare departmental datasets; several paginated reports feed regulated monthly packs; and a small number of Fabric pipelines invoke Power Query-based copy activities. Cloud connections serve most workloads, while selected refreshes use an on-premises data gateway to traverse a private network route.

The platform team enables ADBC in a non-production workspace and a sample dashboard refreshes faster. It is tempted to approve the tenant default. Yet its estate contains four materially different cases:

• An old Snowflake semantic model explicitly pins Implementation="1.0".
• Several unpinned Azure Databricks connections will follow the workspace or tenant default.
• A gateway-routed workload continues to use bundled ODBC even when the pilot workspace is set to ADBC, so the apparent test never exercises the new path.
• A finance query depends on high-precision numbers and a distinct-count control total; the current Snowflake connector documentation flags precision choices, higher memory consumption, and a known count distinct issue for implementation 2.0. Snowflake connector implementation 2.0

The problem is therefore not “Can one report refresh?” It is “Can every material business service execute through its intended future path and produce equivalent, authorized, timely results?”

Root causes and consequences

1. Connection ownership is fragmented

Semantic models, dataflows, pipelines, and reports are often owned by different teams. Source expressions may have been copied for years, while the business criticality of their outputs is recorded elsewhere or not at all. An administrator can change the default centrally without knowing which month-end, regulatory, or operational process depends on a connection.

2. Driver selection is implicit

For supported connectors, Implementation="2.0" explicitly selects ADBC and Implementation="1.0" explicitly selects ODBC. If Implementation is absent, the workspace or tenant setting determines the driver. An explicit value takes precedence over those defaults. Consequently, identical-looking workspaces can execute different drivers because their M expressions differ. The setting changes selection at run time; it does not rewrite the M code. Microsoft's driver-selection rules

3. Test and production can take different network paths

The ADBC tenant and workspace settings apply to cloud-service execution. Microsoft states that queries routed through an on-premises data gateway continue using the driver bundled with the gateway, currently ODBC for the affected connectors. A gateway-based pilot can therefore produce a false assurance that ADBC was tested. Moving to a cloud connection may also change firewall rules, private connectivity, proxy behavior, credential storage, or data-egress assumptions. On-premises data gateway behavior

4. Compatibility is connector-specific

ADBC is not one uniform behavioral promise across every source. For example:

• Snowflake implementation 2.0 exposes options that affect NUMBER(38,0) and timestamp precision. Microsoft currently documents a known count distinct correctness issue and potentially higher memory consumption despite typically faster load times. Snowflake limitations
• BigQuery's ADBC path uses different APIs from ODBC, which can require additional permissions. Microsoft also documents connector considerations involving proxy support, relationships, result-dataset creation, region selection, and the BigQuery Storage API. Google BigQuery connector guidance
• New Azure Databricks connections have used ADBC by default since February 2026, while existing connections can remain on ODBC unless changed. The connector also documents feature-specific limitations that must be checked against each workload. Azure Databricks connector guidance

5. Technical success can conceal semantic failure

A green refresh proves that an operation completed. It does not prove that row counts, null behavior, decimal precision, timestamps, duplicates, relationship metadata, incremental-refresh boundaries, or business measures are equivalent. A small numeric difference in a financial aggregation can be more damaging than a visible failure because it travels into a trusted report without triggering an alert.

Business consequences

Without a controlled migration, organizations risk:

• failed refreshes and missed service-level objectives;
• silent changes in executive or regulatory metrics;
• new source permissions that exceed least privilege;
• gateway versions frozen to preserve ODBC, creating security and support exposure;
• unplanned source-compute, Fabric-capacity, or network cost;
• duplicated remediation by domain teams working without common evidence; and
• a rushed enterprise cutover when the service-side fallback disappears.

Why common approaches fall short

“Turn on the tenant setting and watch refresh failures”

This treats visible failures as the only risk. It misses semantic drift, report-query behavior, memory pressure, and downstream business controls. It also changes too much at once to isolate connector-specific causes.

“Pin every connection to ODBC”

Explicit pinning can buy time, but it is not a destination. Microsoft says there is no permanent opt-out, and the affected drivers are planned for removal from the service and later from Desktop and gateway distributions. A mass pinning campaign also creates code debt that must be found and removed later.

“Our gateway means we are protected”

A gateway can defer service-side change for some routes, but it can also invalidate an ADBC test by keeping execution on ODBC. Retaining an old gateway release after drivers stop shipping is not a supportable long-term control.

“A successful sample refresh proves compatibility”

A sample rarely covers production data volume, rare data types, incremental partitions, native queries, DirectQuery concurrency, month-end calculations, or source throttling. Compatibility must be demonstrated against the business contract, not just the connector handshake.

“Desktop testing is identical to service testing”

Desktop and the Fabric service can differ in driver version, credentials, network path, settings, and host behavior. Microsoft notes that existing Desktop queries remain on the implementation against which they were authored; there is no file-level toggle that transparently converts them. Testing must include the real service path. Microsoft's Desktop and M-query clarification

A governed Microsoft Fabric solution

The target is an ADBC migration control plane: an inventory, decision record, test harness, release workflow, and operational dashboard that make every material connection's state explicit.

Architecture and control flow

Fabric tenant inventory
  |-- pq-adbc-advisor workspace scans
  |-- Admin Scanner API for tenant-scale metadata
  |-- ownership, lineage, refresh history, gateway binding
  v
Connection register in governed OneLake tables
  |-- item + workspace + business owner
  |-- source connector + M implementation value
  |-- cloud/gateway route + identity + permissions
  |-- criticality + data classification + rollback owner
  v
Pilot workspace(s)
  |-- controlled ADBC workspace override
  |-- production-shaped credentials and network route
  |-- ODBC baseline versus ADBC candidate runs
  v
Automated evidence
  |-- schema/type/row/count/hash reconciliation
  |-- KPI and financial control totals
  |-- duration, memory, source compute, Fabric CU, egress
  |-- negative access and failure-recovery tests
  v
Release gate -> migration wave -> observation -> ODBC retirement

Microsoft provides pq-adbc-advisor, a read-only Fabric notebook that scans workspaces for migrating connector calls across semantic models, Dataflows Gen2, and data pipelines. It classifies items as “Will fail,” “Needs review,” or “Ready,” and tracks progress across scans. Microsoft explicitly describes it as a starting-point diagnostic rather than a final audit. For tenant-scale discovery, administrators can use its Scanner API option; detailed metadata and mashup expressions require the relevant Fabric admin settings. ADBC advisor guidance Metadata scanning setup

1. Create the connection register

Use the advisor output as the discovery seed, then enrich it with operational and business metadata. At minimum, record:

Do not publish raw M expressions, endpoints, or credential details into a broadly accessible dashboard. Keep sensitive technical evidence in a restricted workspace and expose only the status fields needed by program stakeholders.

2. Define an execution contract for every critical connection

The contract should state:

• the intended future driver and explicit or inherited selection method;
• the supported Fabric item types and client or gateway versions;
• cloud or gateway path, including DNS, firewall, proxy, private-link, and egress assumptions;
• non-person identity, authentication mechanism, and least-privilege source grants where supported;
• connector options for precision, billing project, query timeout, native SQL, or storage API use;
• expected schema and type mappings;
• refresh, DirectQuery, and concurrency objectives;
• business reconciliation rules and tolerated variance; and
• rollback trigger, rollback action, owner, and deadline for re-entry.

An explicit contract prevents a tenant default from silently becoming architecture. It also lets security, data owners, and platform engineers approve the same future state.

3. Build a production-shaped dual-run test

For each risk class, run the ODBC baseline and ADBC candidate against the same logical source snapshot or a time-bounded stable period. Validate at four layers.

Connectivity and security

• Prove the intended driver from mashup logs or equivalent diagnostics.
• Confirm the intended cloud or gateway route.
• Test authentication renewal, denied access, secret or certificate rotation, and least-privilege permissions.
• Verify that no new public route or unintended region is used.

Data semantics

• Compare column names, order where relevant, native and Power Query types, nullability, and precision.
• Reconcile row counts, distinct keys, duplicates, null counts, min/max timestamps, sums, and checksums by partition.
• Exercise high-precision decimals, dates at boundary ranges, nested data, Unicode, empty result sets, and late-arriving records.
• Recalculate material KPIs and regulated control totals independently of the visual layer.

Workload behavior

• Test full and incremental refresh, Dataflow Gen2 execution, pipeline invocation, Import and DirectQuery modes where used, paginated output, and scheduled concurrency.
• Inspect query folding or source-query patterns so that a fast small test does not become an expensive production scan.
• Include failure injection: timeout, throttling, source unavailability, credential expiry, and partial retry.

Performance and cost

• Compare p50 and p95 duration, rows and bytes moved, peak memory, source warehouse consumption, Fabric capacity units, gateway load, retry volume, and network egress.
• Run at representative data volume and concurrency, including peak business periods.
• Require a performance gain to be demonstrated, not assumed. ADBC can improve transfer efficiency while a particular query still uses more memory or source compute.

4. Use workspace overrides as release rings

Microsoft's workspace override enables side-by-side validation without changing every connection individually. Organize the rollout into rings:

1. Engineering ring: disposable copies and synthetic or masked data; validate tooling and test logic.
2. Low-criticality pilot: real service path, representative volume, named owners, and reversible changes.
3. Business-critical non-regulatory wave: complete dual-run evidence and a staffed observation window.
4. Financial, regulatory, or 24/7 operational wave: change-window approval, independent reconciliation, rehearsed recovery, and business sign-off.
5. Tenant default: enable only after the residual untested and ODBC-pinned populations are understood and accepted.

Keep the implementation choice stable during a test. If an unpinned connection inherits a changing setting, the evidence is not reproducible. Record the effective driver, driver version, host version, workspace setting, gateway version, and source configuration with every result.

5. Establish release gates

An item should advance only when:

• it has an accountable business and technical owner;
• the future execution path is proven to use ADBC;
• all required data and KPI reconciliations pass;
• authentication, least privilege, network controls, and negative-access tests pass;
• performance and cost stay within agreed guardrails;
• source-specific known issues have been assessed;
• downstream owners approve the result;
• monitoring and support runbooks are active; and
• any rollback uses a mechanism that will remain available for the planned rollback window.

A rollback to ODBC is time-bounded risk treatment, not closure. Each rollback must create an exception with an expiry date, product-issue reference if applicable, compensating controls, and a new test date.

Phased implementation roadmap

Phase 0: Mobilize and freeze uncontrolled change (days 1-3)

• Name an executive sponsor, platform owner, source-system owners, security lead, and business validators.
• Publish the affected connector list and planned Microsoft milestones.
• Require review for new Implementation="1.0" pins, new gateway dependencies, and new production connections using affected sources.
• Define criticality tiers and evidence standards.

Exit criterion: ownership, scope, and decision rights are documented.

Phase 1: Discover and classify (week 1)

• Run pq-adbc-advisor per workspace and, where authorized, use the tenant-scale Scanner API route.
• Join the technical inventory to ownership, lineage, refresh, gateway, sensitivity, and business-service records.
• Manually investigate raw DSN strings, custom functions, unsupported or unclear connector patterns, and orphaned items.
• Classify each connection as ready, test required, remediation required, retire, or approved time-bound deferral.

Exit criterion: every material affected item has an owner, risk tier, and disposition.

Phase 2: Design and prove (weeks 1-2)

• Define the execution contract and source-specific test pack.
• Create isolated pilot workspaces with equivalent security and network conditions.
• Capture ODBC baselines before changing defaults.
• Validate the ADBC path with current clients, cloud connections where required, and production-shaped data.

Exit criterion: pilot evidence proves correctness, security, operability, and acceptable economics.

Phase 3: Remediate and migrate in waves (weeks 2-6)

• Remove or replace ODBC pins only through controlled releases.
• Adjust connector options, queries, permissions, identities, or network paths based on documented source behavior.
• Run dual comparisons and obtain owner sign-off.
• Observe each wave through at least one representative business cycle before expanding blast radius.

Exit criterion: all high-criticality workloads run on ADBC or have an approved, expiring exception.

Phase 4: Enable the default and burn down exceptions (before service-side removal)

• Enable the tenant default after reconciling workspace overrides and explicit pins.
• Re-run discovery to find drift, newly created ODBC dependencies, and missed items.
• Track gateway-based deferrals separately with gateway upgrade and ODBC retirement dates.
• Remove temporary duplicate artifacts and legacy test credentials.

Exit criterion: no unowned ODBC dependency remains, and exceptions have funded remediation plans.

Phase 5: Operate continuously

• Add driver state and connector version to the platform service catalogue.
• Reconcile inventory after workspace creation, deployment, or material M-code change.
• Monitor refresh success, duration, semantic controls, memory, capacity, and source cost.
• Review Microsoft connector limitations and milestone updates on a defined cadence.

Exit criterion: the transition becomes part of normal release and reliability governance rather than a one-time campaign.

Governance, security, adoption, and cost considerations

Governance

Assign accountability at two levels. The Fabric platform owner controls tenant defaults, workspace exception policy, tooling, and evidence standards. The data-product owner accepts business correctness and downtime risk. A source-system owner approves permissions and source-cost impact. No single admin toggle should substitute for all three decisions.

Store the connection register and test evidence as governed data products with retention rules. Record who approved a release, which effective driver ran, which controls passed, and which exception remains. This creates an audit trail without exposing secrets.

Security

Treat the driver change as a new client path. Reassess source permissions, outbound endpoints, proxies, private connectivity, certificates, and credential rotation. BigQuery is a useful warning: Microsoft notes that ADBC uses different APIs and may require additional permissions. Grant only the missing operations to the workload identity; do not solve the cutover with a broad source-admin role.

Where supported, prefer durable workload identities over employee credentials. Microsoft documents Microsoft Entra ID, workspace identity, key-pair authentication, and service-principal options for current Snowflake scenarios, but support varies by experience and source configuration. Validate the exact item type and authentication path rather than assuming one method works everywhere. Snowflake authentication types

Adoption and operating model

Give domain teams a standard test pack, a clear escalation route, and a dashboard showing what they own. Train report developers to recognize Implementation values and understand that a gateway-routed test may not exercise ADBC. Business validators should receive reconciled measures and exception explanations, not driver logs.

Change communications should name the affected business services, validation window, expected user impact, support contact, and rollback criteria. “Infrastructure maintenance” is too vague for a change that can alter decision data.

Cost

Budget for temporary duplicate refreshes, source warehouse consumption, test capacity, engineering time, and extended observation. Measure both platforms: an ADBC query that moves data faster can still change source execution plans or use more Fabric memory. Stagger large validation runs to avoid confusing migration overhead with steady-state demand.

Gateway retention can appear cheaper than remediation but carries hidden costs: extra infrastructure, operational support, constrained upgrade options, and eventual forced change. Put an expiry and total-cost estimate on every gateway-based deferral.

Success metrics

Use a balanced scorecard rather than a single completion percentage.

Targets should be set per criticality tier. For a regulated financial output, zero unexplained reconciliation variance is more important than a percentage performance improvement. For a high-volume operational dashboard, latency and memory guardrails may carry more weight after correctness is established.

How YuniQ can help

YuniQ's published Microsoft Fabric services align with the work required for a controlled ADBC transition without turning the engagement into a generic platform program.

• Fabric Strategy & Readiness: YuniQ describes current-state platform and workload diagnostics, capacity planning, workspace topology, security and governance design, and pilot scoping. These activities can frame the affected estate, criticality tiers, decision rights, and migration waves.
• Data Integration & Engineering: YuniQ lists Fabric Data Factory pipelines, Dataflows Gen2, data-quality observability, and exception handling. Those capabilities are relevant to remediating affected flows and automating comparison evidence.
• Governance, Security & DevOps: YuniQ publishes services for Microsoft Entra ID least-privilege design, Dev/Test/Prod separation, CI/CD, auditable logging, and automated monitoring. These controls support repeatable releases and durable exceptions.
• Validation and operations: YuniQ's delivery framework explicitly includes automated reconciliation, access testing, dual-run comparisons, user acceptance, cutover, performance monitoring, and optimization. Its managed-services description includes pipeline and refresh monitoring, capacity optimization, and DevOps release management.

Those statements are grounded in YuniQ's Microsoft Fabric consulting and implementation services . The practical starting point for this issue is a bounded assessment: inventory affected connections, select representative high-risk workloads, prove the future execution path, quantify remediation, and establish a rollout backlog with owners and dates.

Practical next steps for technology leaders

1. Ask the Fabric administrator for the current tenant setting, rollout availability, workspace overrides, and gateway paths; do not infer them from documentation dates.
2. Run pq-adbc-advisor in a controlled workspace and plan the tenant-scale scan if the initial findings justify it.
3. Select three pilots that expose different risks: one cloud semantic model, one Dataflow Gen2 or pipeline, and one gateway-routed or high-precision workload.
4. Capture ODBC baselines before changing driver selection, including business totals, memory, source cost, and execution route.
5. Test ADBC with current clients and production-shaped data, then prove the effective driver in logs.
6. Create an executive dashboard for coverage, correctness, exceptions, milestone exposure, and cost.
7. Set an internal ODBC retirement date ahead of Microsoft's planned service removal, leaving time for product issues and source-team remediation.

The leadership question is no longer whether ADBC is a better modern driver architecture in principle. It is whether the organization can demonstrate, connection by connection, that the new path preserves the truth, access, performance, and reliability on which the business depends.