Export to Azure Data Lake stops on November 30. Is your Finance and Operations close ready?

Microsoft stops the Export to Azure Data LakedefinitionA large, cheap store of files in the cloud. Reporting tools read from it so they don't load the ERP's live database. add-in for good on November 30, 2026, and it won't grant extensions. If Finance and Operations data reaches your reports through that add-in, pick a replacement this week and test it before your November close.

Most outages announce themselves. This one might not. Microsoft says the service won't export new or changed data after the stop and that exported files remain, so a report reading those files can go on loading old rows. Whether any given pipeline fails loudly depends on how your team built it, and that's worth finding out now.

The calendar makes it worse. November 30 is a Monday, the last day of the month, right after Thanksgiving. Microsoft gives a date, no hour. Anything still on the add-in goes into the November close with data that may stop partway through the final day, and finance is who finds out.

The add-in has been retired since November 1, 2024, so this isn't new. At least one partner was writing about a February 2025 deadline back in January 2025. The wording leaves no room now: Microsoft says no further extensions will be provided, so waiting for another reprieve is a bet against its own documentation.

Here's the part that's easy to miss. Microsoft's deprecation notice names Azure Synapse Link for Dataverse as the replacement. Read that alone and you'd build a Synapse workspace with a Spark pool, then write Delta files. But Microsoft's Delta Lake page now says that export option is deprecated. New customers lost it on October 15, 2026, and existing customers must move to CSV output or Link to Fabric by December 2027.

So a team rushing to Synapse Parquet this month could be migrating twice, assuming its organization is even eligible for the opt-in. Eligibility is decided per Dataverse organization ID, so a new environment won't qualify even if another one in the same tenant does. For most organizations, Microsoft now recommends Link to Fabric with low-latency sync, and keeps Synapse Link for those who must export to their own storage.

Fabric is the sensible default, but it isn't a drop-in. Microsoft's own FastTrack team lists what breaks when you move Synapse serverless views across, and that list is the best free checklist you'll find. Lakehouse names and string comparisons are case-sensitive by default, so where dataareaid = 'usmf' only matches that exact case. Metadata arrives in lower case where the add-in used mixed case, which trips Power Query steps that refer to columns by name.

Strings also default to varchar(8000). That's fine inside Fabric, and it can cause performance or compatibility trouble if you copy the schema unchanged into SQL Server. The FastTrack notebook, DVFabricLinkUtil, creates a case-insensitive warehouse and builds views that handle derived tables, soft deletes and collation. Read it before you hand-write any of that.

Keeping your Synapse serverless SQL estate pointed at Fabric data is harder than it sounds. Low-latency sync writes Delta tables with deletion vectors, and Microsoft says serverless pools don't support those in all scenarios. The answers on offer are moving that workload to the Fabric SQL analytics endpoint, or running a notebook that rewrites the tables, which adds processing time and lag.

Then there's change trackingdefinitionA setting that stamps each row with a version so a sync service can tell what changed. Most tables without it don't appear., and this one can eat your month. Tables need row version change tracking to appear, apart from a few system tables. Microsoft keeps enabling actively used tables through application updates, but custom tables are yours to enable, and on older versions some others too. In a build at 10.0.34 or later, the Sql row version change tracking configuration key has to be switched on in maintenance mode, and database sync then adds a rowversion column. Old X++ doing INSERT INTO table2 SELECT * FROM table1 breaks on that read-only column, which is why Microsoft says to validate it in a sandbox first. Custom tables need the property set by a developer too, so get that request in early.

Identity deserves its own line in the plan, because all three routes hand something a lot of access. For Fabric, Microsoft recommends a workspace identity, since it removes secrets and avoids the service principal misconfiguration it calls the most common setup failure. That identity becomes an application user in Dataverse, commonly with System Administrator. Treat it like the privileged account it is: name an owner and review who can touch that workspace.

Synapse Link has its own set. Allow storage account key access is needed only for initial setup, so switch it off afterwards. Keeping storage behind a firewall needs a managed identity and an enterprise policy, and only one policy can attach to an environment. That method isn't available in GCC, GCC High or China. Watch this conflict too: profiles secured with managed identities can't currently be linked to Fabric, so a locked-down profile won't quietly become your Fabric path later.

Those figures come with Microsoft's own warning that they rest on preview customers and that your volume and data will change them, so treat them as a starting point for your own estimate. One practical check: ask your Power Platform admin how much database capacity you have free before the first sync, because storage notifications and overage status are based on tenant-wide use. Copying or restoring an environment also needs capacity to be available, and that's a bad thing to discover mid-project.

If you take the incremental CSV route, two details will bite your pipeline. Read only from older time-stamped folders, since Changelog/changelog.info names the folder still being written. And expect duplicates: without Delta conversion, long-running transactions can repeat records across folders, so your loader has to handle the same ID and version number more than once.

We work on Dynamics 365 Finance and Operations alongside Fabric and Dataverse, and on a clock like this the job is mostly inventory, change tracking and reconciliation. See our Finance and Operations page for what we cover, hire an engineer if your team is short for the cutover, or start with an assessment to list what reads your lake. If Fabric is new to you, our Databricks, Snowflake and Fabric comparison covers how it bills.