Microsoft has set a hard date for the retirement of a critical data import feature in Azure Machine Learning: September 30, 2026. Come that day, any existing Data Import or Data Connection workloads will stop functioning, and all scheduled refreshes will cease. The deprecation, announced on March 31, 2026, affects the preview features that allowed direct ingestion from Amazon S3, Azure SQL, and Snowflake into cached, versioned Parquet data in Azure Storage. While the tools won’t disappear overnight, the clock is already ticking for data scientists, ML engineers, and platform admins who rely on them to feed training pipelines.

The migration path Microsoft recommends—shifting external ingestion to Microsoft Fabric and reconnecting via Azure ML datastores—is more than a configuration change. It demands a deliberate re-architecture of how data flows into your machine learning workspaces. This guide breaks down exactly what’s being retired, why a simple connector swap won’t suffice, the four distinct Fabric-based migration patterns you can choose from, and the non-negotiable inventory and validation steps you must take before the deadline.

What Exactly Is Being Retired?

Azure Machine Learning’s Data Import (Preview) and Data Connections (Preview) were designed to simplify and accelerate training data ingestion. According to Microsoft’s documentation, a successful data import automatically created and registered an Azure ML data asset, then transparently built a cache of the source data stored as partitioned Parquet files in Azure Storage. Under the hood, the service orchestrated Azure Data Factory (ADF) pipelines, handling compute pool sizing, provisioning, and tear-down without you ever touching an ADF interface.

The cached data was versioned to support reproducibility, provided data lineage for auditing, and sidestepped network or connection timeouts during training. For teams working with large, external datasets—particularly from Snowflake, Azure SQL, or Amazon S3—this feature delivered faster, more reliable job runs while reducing training compute costs compared to querying sources directly each time.

The trouble was that both features remained in public preview, meaning they carried no service-level agreement and were never recommended for production workloads. Yet many organizations quietly wove them into critical pipelines, attracted by the convenience of built-in scheduling and the abstraction from raw ADF configuration. With the retirement announcement, Microsoft makes clear that after September 30, 2026, “existing connections will stop working and scheduled refreshes will no longer run.” In other words, the safety net is gone.

The Hidden Complexity Behind a Simple Deprecation

On the surface, the message looks straightforward: move your data ingestion to Fabric, then point an Azure ML datastore at the new location. But a Data Import object in Azure ML often encoded far more than a source connection. You might have a single asset that bundled a specific query, a workspace connection, a refresh schedule, a target path within a managed datastore, and a dependency assumed by multiple training jobs and downstream data assets. Simply rebuilding the connection in Fabric risks breaking the contract those downstream consumers expect.

Consider what went into a typical import: the source system and query (often tuned for performance), a schedule that might align with business-critical freshness requirements, the partitioning scheme applied during transfer, the exact Parquet output location used by training scripts, and the assumptions baked into code about schema stability or data volume. When the import retires, so does the orchestration that ensured all these pieces played together. A Fabric Pipeline can certainly pull the same data, but unless you deliberately reproduce the operational outcome—not just move bytes—you’ll end up with errors in training jobs that you won’t notice until after the cutoff.

The retirement also surfaces a dependency chain that many teams haven’t mapped. A Data Connection defined in Studio might be referenced by a Data Asset, which in turn is consumed by multiple jobs. If you only inventory connections, you’ll miss the downstream jobs that will suddenly fail when the old path dries up. Microsoft’s own guidance in the Learn documentation suggests using Fabric for ingestion and Azure ML datastores for registration, but it does not give you the architectural blueprint: it shifts the burden of designing a reliable, reproducible ingestion pipeline onto your team.

Four Paths to Fabric: Choosing the Right Migration Strategy

Microsoft Fabric supports over 170 connectors, so reaching your data source is rarely the hard part. The real decision is what Fabric pattern best preserves the specific behaviour your old Azure ML import provided. Based on the available Fabric capabilities and the nature of typical ML ingestion workloads, four distinct migration patterns emerge. They are not equally suited to every scenario, and the wrong choice can quietly undermine reproducibility or operational efficiency.

1. Scheduled Fabric Pipeline to OneLake

This is the closest functional replacement for most scheduled Azure ML Data Imports. You create a Fabric Data Pipeline that connects to your source, executes the query or copy activity, and lands data in a OneLake location (a lakehouse or warehouse). The pipeline’s schedule replicates the old refresh cadence—hourly, daily, or whatever your training demands. OneLake then becomes the new curated layer that your Azure ML datastore points to.

Choose this path when:
- Fabric is emerging as your central data engineering and governance hub.
- You need predictable, materialised copies for training.
- The source may be slow or intermittently available, and you want a boundary between ingestion and consumption.
- You need to independently version and audit datasets outside of Azure ML.

Be warned: the old Azure ML import cached data as Parquet, managed partitioning, and provided versioning and lineage automatically. A Fabric pipeline can do all of that, but you have to configure it. Simply writing to OneLake doesn’t guarantee that your downstream code will find the same partition structure or that lineage is captured in a way similar to what Azure ML provided. Explicitly set output options, enable Lakehouse table maintenance, and consider using Fabric’s built-in shortcuts or views to present the data in the form your training jobs expect.

2. OneLake Shortcuts

Shortcuts in OneLake provide a live reference to data stored elsewhere—in ADLS Gen2, Amazon S3, or even other OneLake locations—without copying. For ML workloads that can tolerate direct access and don’t require a separate snapshot, this can eliminate duplicate storage and latency.

Choose this path when:
- Avoiding a duplicate copy is important, either for cost or governance reasons.
- The source data is already in a location that supports OneLake shortcuts and is performant enough to serve training jobs directly.
- You’re willing to accept that training runs will depend on the source’s availability and consistency at runtime.

But a shortcut is not automatically a substitute for the Azure ML import cache. The old import created a frozen copy that could be versioned and held stable across training runs. A shortcut points to live data that may change between runs, breaking reproducibility. If your ML workflows rely on immutable inputs for experiment tracking, you’ll need to add your own snapshotting or versioning layer on top of the shortcut—perhaps via Fabric’s table maintenance or a periodic “sync” pipeline that creates a time-stamped copy.

3. Snowflake Mirroring

If your organisation has already standardised on Snowflake as the source of truth, Fabric’s Snowflake mirroring feature can keep a OneLake copy synchronised automatically. This avoids building and maintaining a separate extract-and-copy pipeline.

Choose this path when:
- Snowflake is where data is governed, curated, and operationally owned.
- You need fairly current data in OneLake for multiple consumers, not just Azure ML.
- The mirroring latency and cost model fit your freshness requirements.

Be mindful that mirroring adds a managed data flow to monitor, and the synchronised data in OneLake may not be partitioned identically to what your old import produced. Validate that the mirrored tables can be consumed efficiently by your training jobs. Where mirroring introduces too much latency or rigidity, consider a Fabric Pipeline that extracts bounded snapshots from Snowflake directly into the Azure Storage account your Azure ML workspace already uses (see path 4).

4. Fabric Pipeline to Azure Blob Storage or ADLS Gen2

Perhaps your Azure ML training estate is already mature, with datastores, data assets, and runbooks all built around Azure Blob Storage or ADLS Gen2 paths. The retiring feature was merely the ingestion trigger—the copy mechanism. In such cases, the least disruptive migration is to replace the old import with a Fabric Pipeline that writes to that exact same storage, keeping the destination path and format unchanged.

Choose this path when:
- Training scripts, pipelines, and operational processes already depend on storage URIs.
- You want to minimise code changes and avoid retesting the entire ML workflow.
- The existing storage location has the necessary performance, cost, and governance controls.

This isn’t a “failure to fully adopt Fabric.” It’s a pragmatic move that decouples the ingestion mechanism from the consumption architecture. Fabric takes over the external copy, but Azure ML continues to work exactly as before. Over time, you can evolve toward a OneLake-based approach, but you remove the retirement risk immediately.

In all four paths, the common thread is that you must re-establish the connection between the ingested data and the Azure ML workspace. After building the new ingestion route, you register or update a datastore in Azure ML that points to the new location (OneLake, storage account, etc.), then update any data assets and job references accordingly.

Your Pre-Migration Inventory: The Non-Negotiable First Step

Before you touch Fabric or rewrite a single pipeline, you must build a complete inventory of every existing Data Import and Data Connection in your workspaces. This is the only way to surface the hidden dependencies that will break after September 2026. A migration wizard or automated tool can help discover connections, but it won’t tell you which training jobs rely on a specific cached partition path or which validation step expects a certain refresh cadence.

For each import or connection, capture at least:
- Source system and object: Determines whether a pipeline, shortcut, mirror, or direct copy is even feasible.
- Schedule and required freshness: How often does the data need to update? Is it tied to a business event?
- Destination path and datastore: The exact Azure ML datastore and folder where the cached data lands.
- Consuming data assets and jobs: Which Azure ML data assets, training pipelines, and batch inference jobs reference this data?
- Implied transformations or partitioning: Did the old import apply any filters, projections, or custom partitioning that your code now expects?
- Connection ownership and secrets: Who owns the credentials, and what authentication method is used?
- Validation criteria: What does “the data is correct” mean—row counts, schema, sample values, or something else?

This inventory serves two purposes. First, it becomes the specification for your new Fabric design. Second, it lets you classify each workload into one of the four migration patterns based on objective criteria, not intuition. Only when you know exactly what each import does can you decide whether a shortcut’s live reference is safe or whether a pipeline-managed copy is essential.

Validating the New Pipeline: Don’t Wait Until the Deadline

Start building and running the new Fabric-based path as soon as possible, running it in parallel with the old import. Because existing Data Imports will continue to function until September 30, 2026, you have a window for side-by-side comparison. Use it.

During the parallel period:
- Run the Fabric pipeline on the same production schedule as the old import.
- Compare output row counts, partition files, schema, and a sample of values.
- Execute representative Azure ML training jobs against the new datastore path and verify that model performance, data loading time, and pipeline completion behave as expected.
- Check that versioning and lineage artifacts (if you maintain them) are correctly produced.

The goal is to prove not just that Fabric moved the data, but that the entire ML workflow still receives the intended snapshot at the intended time. Keep the legacy import active as a rollback reference. Document a precise rollback plan: which Azure ML data asset or job reference must revert to the old datastore path, who can make that change, and what happens if the new refresh arrives late or produces an unusable dataset. Once you’re confident, cut over consumers gradually, removing the old secrets and schedules before the retirement date.

What to Watch as the Deadline Approaches

The retirement of these preview features is part of a broader Microsoft push to consolidate data integration workloads onto Fabric. As the June 2025 Fabric update demonstrated, the pace of change in the platform is high, and new connectors, mirroring features, and governance capabilities will continue to appear. Your Fabric migration isn’t a one-time event—it’s a move onto a modern governed data plane that will evolve.

Between now and September 2026, monitor these areas:
- Fabric capacity and cost: Pipeline execution in Fabric consumes capacity units. A test refresh may behave differently once it runs alongside production workloads. Work with your Fabric administrator to allocate capacity and set up budgeting alerts.
- RBAC and cross-team ownership: The team that owns the source, the Fabric workspace, and the Azure ML workspace may not be the same. Clarify who is responsible for credentials, refresh failures, and schema-change approvals.
- Deprecation of related services: Azure ML isn’t the only service affected. Keep an eye on other preview features that might follow a similar retirement path.

Above all, start now. The hard stop on September 30, 2026, leaves no room for last-minute experimentation. By investing in a thorough inventory, selecting the right Fabric pattern for each workload, and running a disciplined parallel validation, you can ensure that your Azure ML training jobs emerge from the retirement unscathed.