On 30 November 2026, Export to Data Lake stops exporting. Microsoft retired the service in November 2024 and has been running it in a wind-down since, and the documentation is unusually blunt about what happens next: "No further extensions will be provided."
That is twelve weeks from today. If your Dynamics 365 finance and operations data reaches a lake through that add-in, something you depend on has a date on it now, and Microsoft offers you two doors out.
What is actually ending
The internet will tell you Azure Synapse is dying. It isn't, and believing that will send you into a migration you may not need.
Dedicated SQL pools, Synapse Spark and Synapse pipelines are supported. There is no announced end-of-life for any of them. Microsoft has also said, in writing, that it has no plans to retire Azure Synapse Link for Dataverse: "we want to enable you to export data well into the future." A team happily running Synapse Link today is not on a countdown.
What is ending is narrower and older. The Export to Data Lake environment add-in, installed through Lifecycle Services, which uses change data capture to write CSV files into a lake you own. That is the thing with twelve weeks left. Files already exported stay where they are; new and changed data simply stops arriving.
One more correction worth having, because a lot of blog posts have it wrong. The trusted-services retirement, where a Synapse workspace reaches its own storage account or Key Vault through a firewall exception, was scheduled for 1 August 2026. Microsoft moved it. The date is now 1 August 2027, to give organisations time to test private endpoints and managed virtual networks. If you read somewhere that this already happened, check the source's date.
So the shape of the problem is smaller than the panic suggests, and sharper. One legacy export path is closing on a fixed date, and the decision it forces is worth making deliberately.
The two doors
Microsoft's guidance names two replacements, and they are genuinely different things.
Link to Microsoft Fabric is a no-copy, no-ETL integration. Your Dataverse data becomes readable in Fabric without you building or running a pipeline, and it stays inside the Dataverse governance boundary. If your reporting is Power BI and your organisation has already bought Fabric capacity, this is the shortest path from where you are to working reports, and it is a real reduction in moving parts.
It also has consequences worth knowing before you pick it. Every non-system table with change tracking enabled is selected automatically and you can't deselect them, because Dynamics and partner applications may depend on tables you didn't think you needed. That data lives in Dataverse managed storage, so your Dataverse storage consumption goes up. You are choosing a managed experience, and the price of a managed experience is that the knobs are gone.
Azure Synapse Link for Dataverse keeps the old bargain. Data is exported continuously into a storage account you own, in Delta Parquet, and you decide which tables. You manage the storage, the access and whatever you build downstream. Microsoft's own comparison is fair about the trade: your storage, your compute, your integration tools, your problem.
Both doors are reasonable. Both are also Microsoft's doors, and the guidance is written by the party that benefits when you walk through one of them.
The third answer
There is a version of this decision that Microsoft's documentation will not raise, and it is the right one more often than people expect.
Point Synapse Link at storage you control, and put a lakehouse on top of it.
The export mechanism stays Microsoft's, supported, and not going anywhere. The Delta Parquet that lands in your storage account is an open format, readable by anything. What you build above it is then a choice you can revisit, rather than a property of which vendor's link you picked in a hurry in November.
This matters most when Dynamics is not the only system you care about. Finance data is interesting on its own, and it is considerably more interesting joined to the operational systems, the warehouse telemetry and the customer records that live somewhere else entirely. A Fabric-linked Dataverse answers questions about Dataverse. A lakehouse answers questions about the business, and Dynamics becomes one governed source among several instead of the boundary of what you can ask.
It also puts the permission model in one place. Unity Catalog grants over the exported tables, the same grants over everything else, and one answer when somebody asks who can see the payroll extract.
When you should not do this
We migrate estates onto Databricks for a living, so treat the following as the part we have an incentive to leave out.
If Power BI is the whole of your analytics, your data is Dataverse and nothing else, and you already hold Fabric capacity, then Fabric Link is very likely the right call and a lakehouse is overhead you will resent. Take the short path.
If you have no data engineering capacity and no plan to build any, don't buy a platform that assumes it. A managed link that works is worth more than an architecture you cannot staff.
And if your only driver is the November date, the smallest honest move is to upgrade to Synapse Link, keep the export shape you already have, and decide about the platform in your own time rather than the deadline's. Microsoft's FastTrack team publishes a transition tool that reproduces the Export to Data Lake data shapes on a Synapse workspace, which exists precisely so this can be a small change.
What actually breaks in the move
Whichever door you take, the schema shifts underneath you. These are the changes Microsoft documents, and they are the ones that quietly break reports:
- SQL reserved words are renamed, so
LevelbecomesLevel_andResourcebecomesResource_ - The
IDfield in Export to Data Lake tables becomesFnO_Id - Deleted rows now arrive as soft deletes, flagged with
isDelete, so anything that assumed a row disappearing meant a deletion needs a filter - TimeZoneID fields are gone, having been legacy in finance and operations for some time
- Binary columns are dropped entirely
nVarChar(max)columns arrive truncated at 2,000 characters
That last one is the one to check first. A description or notes field that has always been complete will start arriving cut, and nothing errors. The report just gets quietly less true.
There is a further trap for anyone with finance and operations entities. Synapse Link and Fabric Link both work from tables with change tracking enabled, and change tracking cannot be turned on for every entity, particularly older ones created for data migration. When an entity won't validate you have to rebuild its shape from the underlying tables, which is work nobody scopes at the start.
Twelve weeks, spent well
If we were handed this in September with a November date, the sequence would be roughly this.
Inventory what actually consumes the export. Not the pipelines you know about, the reports and spreadsheets and downstream loads that quietly read the lake. That list is always longer than the first answer, and it decides how much of the deadline is real.
Then pick the door, on the analytics you need rather than on the export mechanism. Then move, in waves, with both paths running until the new one has produced numbers somebody has actually reconciled against the old ones.
Our Synapse readiness sprint is two weeks and exists for the first of those steps. It inventories dedicated SQL pools, serverless, Spark and the Data Factory pipelines separately, because they don't convert as one thing, and it ends with a written scope and the exclusions agreed. If the answer at the end is that you should take Fabric Link and we shouldn't build you anything, that is a finding we're happy to deliver.
The date does not move. What you build to meet it can be a decision or an accident, and there is still time for it to be a decision.
Sources
Every date and schema detail above comes from Microsoft's own documentation, checked on 7 September 2026:
- Transitioning from legacy data integration services, FAQ, which carries the 30 November 2026 stop date, the no-extensions statement, the revised 1 August 2027 trusted-services date, and the schema changes
- Export to Azure Data Lake overview