Azure ML Data Import Retires September 30, 2026: Move to Fabric

Verdict: move every Azure Machine Learning Data Import or Data Connection workload to a Fabric-managed ingestion design before September 30, 2026, but do not treat Fabric as a like-for-like connector replacement. Use scheduled Fabric Pipelines when Azure ML needs a controlled copy, OneLake shortcuts when direct access is appropriate, Snowflake mirroring for a Snowflake-centered data estate, and Azure Blob Storage or ADLS Gen2 when existing training jobs already depend on Azure Storage paths.
Microsoft announced the deprecation on March 31, 2026. Azure Machine Learning Data Import (Preview) and Data Connections (Preview) will retire on September 30, 2026; after that date, existing connections will stop working and scheduled refreshes will no longer run. Microsoft’s Learn documentation recommends moving external ingestion to Microsoft Fabric, then exposing the resulting data to Azure ML through datastores.
The immediate task is not “recreate the connection.” It is to preserve the actual contract between source system, refresh cadence, transformed data, Azure ML datastore, data asset, and training job.

1. Inventory every Azure ML Data Import and Data Connection, including source, connection owner, schedule, destination datastore path, consuming data assets, training pipelines, and credentials or secrets.
2. Classify each import by its required freshness and whether Azure ML needs a physical, versioned copy or can safely consume data through a supported direct-access design.
3. Build the selected Fabric path in parallel: a scheduled Fabric Pipeline to OneLake, a OneLake shortcut, Snowflake mirroring, or a Fabric Pipeline that lands data in Azure Blob Storage or ADLS Gen2.
4. Register or reconnect the destination through an Azure ML datastore, then point Azure ML jobs and data assets at the new location.
5. Run the legacy import and Fabric path side by side long enough to compare row counts, partitions, schema, refresh timing, and training-job behavior.
6. Cut over consumers only after validation, retain the old route as a rollback reference during the transition, and remove obsolete secrets and schedules before retirement.

Microsoft’s own documentation is clear about the destination architecture, but it does not make the workload decision for you. Fabric supports more than 170 connectors; that breadth solves source reach, not the harder questions around data movement, governance, capacity, or reproducibility.

Which Fabric migration path fits the training workload?​

The closest replacement for most scheduled Azure ML imports is a Fabric Pipeline that writes a managed copy. Choose this path when a training job benefits from predictable files, when the source can be slow or intermittently available, or when the ML team needs an independently controlled refresh boundary. The old Azure ML import feature cached imported data, stored it as Parquet in Azure Storage, and provided versioning and lineage benefits; a pipeline-based replacement should deliberately recreate the operational outcome rather than merely deliver bytes somewhere.
For an Azure ML workload that already trains from Azure Blob Storage or ADLS Gen2, Fabric Pipelines that copy into that storage are often the least disruptive route. The datastore relationship and downstream job assumptions can remain closer to the current model, while Fabric takes over external ingestion. That does not eliminate migration work, but it avoids coupling a mature Azure ML training estate to a new OneLake access pattern simply because Fabric is now the recommended ingestion layer.
OneLake shortcuts are the better fit when the organization’s primary requirement is access without another copy. They can reduce redundant movement and simplify a data estate already governed around OneLake. But a shortcut is not automatically a substitute for an Azure ML cache: teams should establish whether their training code expects stable partitions, immutable run inputs, or performance characteristics that depended on a materialized copy.
Snowflake mirroring deserves its own lane. If Snowflake is the system where data is governed, curated, and operationally owned, mirroring may be more coherent than building a separate extract-and-copy chain. If Azure ML training simply needs periodic, bounded snapshots from Snowflake, however, a pipeline copy into the storage location already used by the workspace may be easier to validate and operate.
The decision can be reduced to four practical tests:

• Choose a Fabric Pipeline to OneLake when Fabric is becoming the central data engineering and governance plane, and training can consume a curated OneLake-oriented destination.
• Choose a OneLake shortcut when avoiding a duplicate data copy matters more than creating a separate ML-ready snapshot, and the direct-access scenario is supported.
• Choose Snowflake mirroring when Snowflake remains the authoritative operating center and the wider Fabric estate needs synchronized data.
• Choose a Fabric Pipeline to Azure Blob Storage or ADLS Gen2 when Azure ML jobs, datastores, and operational runbooks are already designed around Azure Storage.

That last option is not a failure to “adopt Fabric fully.” It can be the most disciplined design when the existing ML execution path is sound and the retiring component is only the ingestion mechanism.

---

Start with an inventory, not a migration wizard​

The retirement creates a hidden dependency problem. An Azure ML data import may have looked like one asset in Studio, but it could encode a source query, a workspace connection, a refresh schedule, a target path, a cached output, and multiple downstream consumers. If the team only inventories Data Connections, it can miss data assets and jobs that fail later because their expected location or refresh rhythm changed.
Build a migration worksheet for each workload with these fields:

Capture item	Why it matters at cutover
Source system and source object	Determines whether a pipeline, shortcut, mirror, or storage copy is realistic.
Schedule and required freshness	Prevents an hourly or daily training dependency from silently becoming an ad hoc refresh.
Destination path and datastore	Identifies what Azure ML jobs must be reconnected to.
Data asset and job consumers	Separates a safe connector change from an application-level migration.
Transformations and partition assumptions	Reveals logic that may have been implicit in the prior import flow.
Connection ownership and secrets	Prevents a new Fabric process from depending on an unmanaged personal credential.
Validation measure	Defines what “same data” means before the old path is retired.

This inventory is also where teams discover an important feature-parity gap. Azure ML Data Import created a cache, transferred data as Parquet, partitioned the transfer, and supplied versioning and lineage capabilities for imported data. Fabric can support a stronger overall ingestion architecture, but those exact behaviors are not automatic just because a Fabric connector can reach the source.
A migration should therefore document where version identity now lives, how lineage will be reviewed, how partitions are produced and retained, and where transformations execute. If those answers are vague, the team has selected a connector, not an architecture.

Parallel validation is the only safe cutover​

Do not wait for September 2026 to discover a training job consumed the old cache more directly than expected. Microsoft says existing Data Connections will stop functioning and scheduled refreshes will cease after retirement, so the final deadline is a hard operational boundary rather than a period for experimentation.
During the parallel period, run the Fabric path on the intended production cadence and compare its output with the legacy import. Validate schema and record-level expectations where feasible, then run representative Azure ML training jobs against the new datastore path. The point is not only to prove that Fabric moved the data; it is to prove that the model workflow still receives the intended snapshot at the intended time.
Keep the legacy import available while it remains supported, but make rollback precise. A rollback plan should identify which Azure ML data asset or job reference returns to the previous datastore path, who can make that change, and what happens if the new refresh arrives late or produces an unusable dataset. By the time the old route is removed, rollback should mean restoring a known Fabric output or prior Azure Storage snapshot—not trying to revive a retired preview feature.
For a broader view of Fabric’s expanding role across data engineering and AI workloads, see WindowsForum’s coverage of the Microsoft Fabric June 2025 update and its discussion of Azure Machine Learning’s changing data-integration direction.

---

The cost and governance questions arrive after the connector test passes​

A copy-first migration can add storage and pipeline execution costs. A direct-access design can reduce copying but may shift performance, availability, or source-system load into the training window. Mirroring can simplify a Snowflake-to-Fabric relationship while adding another managed data flow to monitor. Those are architecture tradeoffs, not product defects.
RBAC and network design need the same scrutiny. The team that owns the source, the Fabric process, the Azure ML workspace, and the destination datastore may not be the same team. A migration plan should explicitly assign ownership of credentials, access reviews, failed-refresh triage, and the approval path for schema changes. The retirement is an opportunity to eliminate personal or opaque connection ownership before it becomes the new Fabric dependency.
Fabric capacity is also a planning input, not an afterthought. A pipeline that works during a test refresh may behave differently once it runs on the production schedule alongside other Fabric workloads. Administrators should make the migration team state its expected cadence, data volume behavior, retry expectations, and operational priority, even where exact capacity sizing depends on local usage patterns.

Frequently Asked Questions​

Does Azure ML Data Import stop working before September 30, 2026?​

Microsoft says the preview features can continue without disruption until retirement, but after September 30, 2026, Data Connections will stop functioning and scheduled refreshes will no longer run.

Is OneLake always the preferred Azure ML destination?​

No. OneLake is one Fabric option, but Azure Storage may be the better destination when Azure ML datastores and training jobs already consume Blob Storage or ADLS Gen2.

Can a shortcut replace the Azure ML import cache?​

Not automatically. A shortcut addresses direct access; teams must separately validate reproducibility, performance, partitioning, and how their Azure ML jobs consume the resulting data.

What should be completed first?​

Complete the inventory of schedules, connections, assets, consuming jobs, and secrets first. Without it, a successful Fabric ingestion test can still leave a broken Azure ML training dependency behind.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Import data (preview) - Azure Machine Learning | Microsoft Learn

   Learn how to import data from external sources to the Azure Machine Learning platform.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Machine Learning 2025: Revolutionizing Data Integration for AI | Windows Forum

   Azure Machine Learning is setting the stage for a data revolution in 2025, promising to extend its support far beyond traditional databases to encompass a...

   windowsforum.com

 

[ChatGPT]

Azure Machine Learning Data Import and Data Connections retire on September 30, 2026, and teams should treat the deadline as a data-freshness incident waiting to happen—not a routine portal cleanup. Microsoft says existing connections will stop functioning and scheduled refreshes will no longer run after retirement, so every production import needs a Fabric replacement that has been proven to deliver usable data back to Azure ML before the cutoff.
Microsoft’s migration guidance points customers to Microsoft Fabric, with Azure ML consuming the resulting data through a OneLake datastore or through Azure Blob Storage or Azure Data Lake Storage Gen2. That is the destination architecture; the harder operational task is ensuring that the timing, credentials, data contract, and ownership behind each old refresh job survive the move.

The clock is really a 10-week validation window​

From July 20 to September 30, there are just over 10 weeks to find imports, build replacements, and observe them long enough to trust their output. A team that waits until September to create Fabric pipelines may technically “migrate” but still discover after retirement that a morning training run is using yesterday’s—or last month’s—data.
The most dangerous workloads will not necessarily be the most visible ones. An Azure ML Data Import schedule can run by minute, hour, day, week, or month, using either recurrence or cron triggers. A low-frequency monthly refresh is especially easy to misjudge: a successful pipeline test is not proof that the production schedule will hit the intended calendar boundary, time zone, or downstream training window.
Microsoft Learn’s retirement notice is unambiguous: scheduled refreshes will no longer run after September 30. The immediate priority is therefore to identify which production ML datasets depend on a schedule rather than a manually initiated import.

---

Start with a defensible inventory, not a migration workshop​

Azure ML administrators should create one migration record per affected workload. The record should describe the source system, the existing Azure ML Data Connection or Data Import, the schedule, its consumers, and the intended Fabric design. Do not use a list of workspaces alone as evidence that the estate has been assessed.
Microsoft documents az ml schedule list as the Azure CLI command for listing schedules in an Azure ML workspace. Start with a workspace-by-workspace export, including disabled schedules so an apparently dormant job is not rediscovered during an incident.

az ml schedule list \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --include-disabled \
  --output json > <workspace-name>-schedules.json

For each returned schedule, inspect the full definition rather than relying on a table view:

az ml schedule show \
  --name <schedule-name> \
  --resource-group <resource-group> \
  --workspace-name <workspace-name> \
  --output json

The schedule export is only the first pass. The retirement applies to both Data Import and Data Connections, while a generic workspace schedule inventory can include jobs that are unrelated to importing external data. The migration owner must correlate each schedule with its job definition, imported destination, and the underlying connection. That is where silent dependency risk usually surfaces.
Build the inventory around these fields:

• Record the workspace, resource group, schedule name, enabled state, and named owner.
• Record whether the trigger is cron or recurrence, its frequency, its declared time zone, and the next expected business-use window.
• Record the external source, the current connection identity or credential owner, and the destination data location used by Azure ML.
• Record every downstream training, scoring, feature-preparation, or reporting workflow that expects the refreshed data.
• Record whether the job is truly time-based or is standing in for an event-driven requirement.

That final point matters because Azure ML v2 scheduling does not support event-based triggers. A job that looks like “every 15 minutes” may actually be a workaround for “when a file arrives” or “when an upstream system publishes data.” Moving that workload to a scheduled Fabric pipeline without recognizing the original business requirement preserves the schedule but may preserve the wrong behavior.

Build the Fabric replacement around the data contract​

Microsoft’s recommended migration options are Fabric Pipelines for scheduled batch movement, Snowflake mirroring for near-real-time Snowflake access, and OneLake shortcuts for directly referencing supported storage without copying data. For scheduled Azure ML Data Import replacements, Fabric Pipelines are the natural starting point, but they are not automatically the right answer for every source or freshness target.
The decision should be made on the data contract: where the source lives, whether data must be copied or referenced, when the result must be ready, and where Azure ML expects to read it. Microsoft recommends two paths back into Azure ML:

1. Create a OneLake datastore so Azure ML references Fabric data directly.
2. Use a Fabric pipeline to copy data to Azure Blob Storage or ADLS Gen2, then use the corresponding Azure ML datastore.

The OneLake datastore path reduces the number of locations teams must reason about. The Azure Storage path can be more practical when downstream tools already require data in Azure storage. Neither choice should be made solely because it is the faster diagram to draw; the consuming Azure ML jobs, data paths, and operational ownership need to be checked first.
Before creating production pipelines, establish four readiness gates with the people who operate Fabric and Azure ML:

• Confirm that the required Fabric licensing and capacity arrangement is available for the intended design.
• Confirm that the chosen Fabric and Azure ML data locations meet the organization’s regional and data-placement requirements.
• Confirm the identity that will authenticate to the source and the identities that will read the destination from Azure ML.
• Confirm who will own failures, credential changes, schedule changes, and cost review after the legacy Azure ML feature is gone.

These are not paperwork details. A technically successful test using a developer’s access is not proof that a production pipeline has durable credentials or a supported operational owner.
For broader planning around Azure ML’s evolving data and MLOps direction, see WindowsForum’s related coverage of Azure Machine Learning 2025: Revolutionizing Data Integration for AI.

---

Run old and new schedules in parallel before changing consumers​

A useful cutover is a controlled comparison, not a date on a project plan. The following sequence gives teams enough evidence to switch Azure ML readers with confidence.

1. Freeze the baseline. Export the Azure ML schedule definitions, capture the current Data Import and Data Connection configuration, and retain examples of the most recent successful output. Record expected file, table, or partition conventions without assuming the Fabric destination will reproduce them automatically.
2. Create the Fabric ingestion design. Select the pipeline, mirroring, or shortcut approach that matches the source and required freshness. Configure the planned destination in OneLake, Blob Storage, or ADLS Gen2, then create or prepare the Azure ML datastore that Azure ML jobs will use after cutover.
3. Match the schedule deliberately. Translate the current cron or recurrence behavior into the Fabric design. Validate minute-, hour-, day-, week-, or month-based behavior, as appropriate. Time-zone interpretation must be explicit: Microsoft’s Azure ML guidance notes that an omitted time zone defaults to UTC, so teams should not assume a local-business-time schedule will remain aligned merely because the expression looks similar.
4. Run in parallel. Keep the Azure ML import active while the Fabric replacement produces comparison outputs. Do not immediately repoint production training jobs. Compare freshness, expected arrival timing, and whether Azure ML can read the new destination through its datastore.
5. Validate the actual consumer. Execute the Azure ML training or pipeline job that depends on the refreshed data, using the Fabric-backed path. A successful ingestion run proves only that data moved; it does not prove that the ML job resolves the location, recognizes the expected structure, or starts with fresh input.
6. Collect rollback evidence. Save the schedule exports, successful run records, output comparisons, and the tested Azure ML job result. Until the retirement date, the old configuration remains the practical rollback path. After September 30, it is not a fallback: the legacy Data Import and Data Connection workloads are retired.
7. Cut over one consumer group at a time. Change the Azure ML datastore reference or consuming job configuration only after the replacement has passed the agreed validation window. Keep an explicit change record that identifies the last old-path output and the first accepted Fabric-path output.
8. Disable only after acceptance. Once consumers have been switched and validated, disable the old import schedule as a deliberate change. Retain the evidence package, because it explains how freshness and lineage changed when troubleshooting begins later.

The key distinction is between a rollback plan and rollback evidence. The plan says which legacy schedule remains available before retirement. The evidence shows why the new workflow is safe to operate when the old feature is no longer available.

Schedule parity is more than the cron string​

Cron syntax creates a false sense of equivalence. Microsoft’s Azure ML documentation flags important schedule behavior: Azure ML v2 supports recurrence and cron, but does not support event-based triggers. It also notes that some calendar-like cron fields are not supported as users may expect, and that complex recurrence patterns can be visible in the studio without being editable there.
That means migration validation should compare outcomes rather than only definitions. Ask whether the Fabric replacement produces data before the Azure ML job begins, whether it handles the intended time zone, and whether monthly or weekly boundaries behave as the business expects.
This is also where monitoring, lineage, and cost deserve attention. Document where operators will see a failed ingestion, how they will trace a Fabric output back to its source and schedule, and which team will investigate unexpectedly frequent runs or data movement. Those are operational design decisions, not properties that should be assumed to transfer from Azure ML automatically.
WindowsForum’s earlier guide, Azure ML Data Import Retires September 30, 2026: Move to Fabric, covers the broad migration direction. The immediate project-management test is narrower: can each named production ML consumer prove that its input remains fresh on the required schedule?

Frequently Asked Questions​

Does every Azure ML schedule need to move to Fabric?​

No. az ml schedule list can return schedules unrelated to Data Import. The urgent population is every workload depending on Azure ML Data Import or Data Connections, including scheduled refreshes that feed production ML workflows.

Can teams wait until September 30 to switch?​

They should not. September 30, 2026 is the retirement date, and Microsoft states that existing Data Connections and Data Import schedules stop functioning afterward. Parallel operation before that date is the only practical way to retain a legacy fallback while testing the replacement.

Is a Fabric Pipeline always the replacement?​

No. Microsoft also identifies Snowflake mirroring and OneLake shortcuts for particular source and latency needs. Fabric Pipelines are the primary option for scheduled batch ETL, but the right choice depends on the source, required freshness, and whether the data must be copied.

Can Azure ML read Fabric data after migration?​

Yes. Microsoft recommends connecting Fabric data back to Azure ML through a OneLake datastore, or copying it to Azure Blob Storage or ADLS Gen2 and creating the corresponding Azure ML datastore.
The September 30 deadline is fixed, but a rushed cutover is not inevitable. Teams that complete inventory now, validate a Fabric-backed Azure ML consumer in parallel, and preserve cutover evidence will arrive at retirement with a tested data-freshness path rather than a hope that a replacement schedule fires when production needs it.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Migrate Data Import to Microsoft Fabric - Azure Machine Learning | Microsoft Learn

   Migrate from Data Import and Data Connections in Azure Machine Learning to Microsoft Fabric Pipelines, Shortcuts, or mirroring.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure ML Data Import Retires September 30, 2026: Move to Fabric | Windows Forum

   Verdict: move every Azure Machine Learning Data Import or Data Connection workload to a Fabric-managed ingestion design before September 30, 2026, but do...

   windowsforum.com