{
"title": "Azure ML’s Data Import Is Retiring: Here’s Your Fabric Migration Checklist for 2026",
"content": "Microsoft has set a countdown clock for one of its data integration features in Azure Machine Learning. Starting September 30, 2026, the Data Import and Data Connections previews will stop working, and any scheduled refreshes tied to them will cease to run. The company is urging users to migrate to Microsoft Fabric, its unified analytics platform, well before that date to avoid interruptions to their machine learning workflows.

The retirement, announced on March 31, 2026, gives teams roughly 18 months to identify affected workloads, design replacements, and test them in parallel. But with the complexity of most production ML pipelines, waiting until the last minute could leave you with stale training data and broken models. Here’s what you need to know—and do—now.

What’s Actually Being Retired?

Azure Machine Learning’s Data Import (Preview) and Data Connections (Preview) are features that let you bring external data into your ML workflows on a schedule. Whether pulling from Azure SQL, Snowflake, or a flat file in blob storage, these tools have automated the ingestion step for thousands of data science teams.

After September 30, 2026, both features will be turned off. According to Microsoft’s official migration guide, existing data connections will stop functioning, and scheduled refreshes will no longer run. There is no grace period. If you haven’t moved your imports to a supported alternative, your pipelines will break.

Microsoft’s recommended replacement is Microsoft Fabric, a unified data platform that integrates data engineering, data warehousing, and data science. Fabric supports over 170 data source connectors and offers three migration paths:

  • Fabric Pipelines: Best for scheduled batch ETL; copies data to OneLake, Fabric’s unified data lake.
  • Snowflake mirroring: For near real-time access to Snowflake data, mirroring it into OneLake.
  • OneLake shortcuts: Reference data in place (e.g., from Amazon S3 or Azure Data Lake Storage Gen2) without copying, provided your tools can read directly from OneLake.
Once your data lands in Fabric, you’ll need to reconnect Azure ML to it. Microsoft suggests two routes: create an Azure ML OneLake datastore that points directly to Fabric, or use a Fabric pipeline to copy data to Azure Blob Storage or ADLS Gen2, then create the corresponding Azure ML datastore. The choice depends on your existing storage habits and whether you need data to reside in Azure storage for other services.

Why This Matters for Your ML Workloads

If your team relies on automated data refreshes to keep training data current, the retirement isn’t just an administrative task—it’s a data-freshness emergency waiting to happen. A model that trains on yesterday’s data might be acceptable; a model still using last month’s data when it should have refreshed yesterday can quietly deliver poor results.

The risk isn’t evenly distributed. High-frequency imports (hourly or daily) are obvious and likely to be noticed quickly if they fail. But low-frequency schedules—monthly or weekly—are the silent killers. A monthly refresh job that fails after retirement could go undetected for four weeks, and by then, a business-critical model might be making decisions on stale information.

There’s also the danger of forgotten schedules. Many teams have “set it and forget it” imports that have been running for years. Disabled schedules, in particular, are easy to overlook during an inventory. Yet a disabled schedule might be one that was temporarily paused and still needed later. If you don’t identify it before retirement, you may not realize it’s missing until a quarter-end report doesn’t match expectations.

How We Got Here: Microsoft’s Fabric-First Strategy

The retirement of Azure ML’s data import features didn’t come out of nowhere. Since the launch of Microsoft Fabric in late 2023, the company has been steadily aligning its data and AI services under one roof. Fabric combines capabilities from Azure Data Factory, Power BI, and Azure Synapse Analytics, all built around OneLake, a single data lake that eliminates the need to copy data between services.

Data Import and Data Connections in Azure ML were always preview features, never reaching general availability. They served as a stopgap for bringing external data into ML experiments, but with Fabric now offering a broader, more scalable ingestion engine, Microsoft sees them as redundant. Similar patterns have played out across the Azure portfolio: preview features that overlap with newer, strategic services get retired to reduce maintenance complexity and push users toward the modern stack.

From a user perspective, the shift isn’t all bad news. Fabric’s ecosystem is richer, with more connectors, better monitoring, and native support for data lineage and governance. The OneLake integration means that once data sits in Fabric, it can be used not just for ML but also for reporting, real-time analytics, and even Microsoft’s Copilot-driven experiences. However, the migration requires deliberate planning, especially around schedules, time zones, and authentication—areas where subtle differences can cause painful outages.

Your Migration Action Plan: 7 Steps to a Successful Cutover

A successful migration isn’t just about rebuilding your import in Fabric; it’s about ensuring your ML jobs continue to receive fresh, correct data on the same schedule—without surprises. Based on Microsoft’s guidance and the hard-won lessons of data engineers who’ve already made the jump, here’s a checklist to follow.

1. Inventory Every Schedule Immediately

Start by listing all Data Import and Data Connection schedules across all Azure ML workspaces. The Azure CLI command az ml schedule list will be your best friend. Run it for each workspace, and don’t forget the --include-disabled flag—disabled schedules might still be relevant.

Export the output to a structured format (JSON or CSV) so you can work through it methodically. For each schedule, retrieve its full definition with az ml schedule show. You need to know the trigger type (cron or recurrence), frequency, and time zone. Microsoft’s default time zone is UTC if none is specified, which may not match your local business hours.

2. Document the Full Data Contract

For every schedule, record:

  • The source system (type, connection details, credentials used).
  • The destination in Azure ML (dataset name, datastore).
  • The exact trigger (cron expression or recurrence pattern) and when it’s expected to deliver data.
  • All downstream consumers: training pipelines, scoring jobs, feature stores, reporting scripts.
  • The business owner who knows why this data matters and when it must be fresh.
This inventory becomes your migration workbook and your audit trail. It also helps you spot workloads that aren’t truly time-based but were forced into a schedule because Azure ML lacked event-driven triggers. Those might need a different design in Fabric.

3. Select the Right Fabric Migration Path

For most scheduled batch imports, Fabric Pipelines are the natural replacement. They can connect to over 170 sources and copy data into OneLake on a schedule. If you’re dealing with Snowflake and need near-real-time freshness, consider Snowflake mirroring, which automatically replicates data into OneLake with low latency. If your data already sits in supported storage like ADLS Gen2 and you don’t want to copy it, OneLake shortcuts let you reference it directly.

Don’t pick a path just because it’s the easiest to draw on a whiteboard. Think about your data volume, latency appetite, and whether you’ll need to transform data in flight.

4. Plan Your Azure ML Reconnection

Decide whether you’ll use a OneLake datastore or copy data to Azure storage. A OneLake datastore keeps things simple: Azure ML reads directly from Fabric, and you only manage one copy of the data. But if your organization has compliance rules requiring data in Azure storage, or if other Azure services need to read from Blob Storage, the copy-to-storage route makes sense.

Test both options early with a small dataset. Validate that Azure ML can read the data with the same structure and credentials your jobs expect.

5. Build and Run in Parallel

Create your Fabric pipeline (or mirroring/shortcut), and while keeping the old Azure ML import active, run both side by side for at least a few cycles. Compare the output:

  • Is the data equally fresh?
  • Does it arrive at the same cadence (minute, hour, day)?
  • Are the time zone and boundary alignment correct? For example, a monthly trigger on the first of the month might behave differently between systems.
  • Can Azure ML successfully read the Fabric-sourced data through the intended datastore?
Parallel operation is your only safety net. Once the Azure ML import is gone, there’s no going back.

6. Validate with Actual ML Consumers

A successful data copy doesn’t mean your ML job will work. Execute a representative training or scoring pipeline that uses the new Fabric-backed path. Check that all file naming conventions, partition structures, and schema details are preserved. If you’re using features like MLflow