Export to Data Lake Migration: Fabric Link or Synapse Link Before the November Cutoff

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Somewhere in your Dataverse environment, or bolted onto Dynamics 365 Finance and Operations through Lifecycle Services, there is probably a data pipeline that has been quietly exporting records to Azure Data Lake Storage for years without anyone touching its configuration. That pipeline stops working for good on November 30, 2026. Microsoft has confirmed there will be no further extensions past that date, which means any architect or BI team still running the legacy Export to Data Lake add-in needs an Export to Data Lake migration plan in motion now, not a vague intention to “look at it before year end.” With roughly eleven weeks left on the clock as of this writing, the practical question is not whether to move, but which of the two supported replacements to move to, and what actually breaks in the schema when you do.

The confusion around this deprecation runs deeper than most Microsoft retirements, largely because the naming has changed twice in the last two years and the marketing language has blurred two genuinely different services into one. It is worth being precise about what is actually going away before touching any configuration.

What Is Actually Being Retired

Export to Data Lake, the LCS-installed add-in that let finance and operations apps write entity data directly into a customer’s Azure Data Lake Storage Gen2 account, was marked deprecated back in October 2023 and stopped accepting new adopters on November 1, 2024. What has not been widely understood is that existing customers were allowed to keep running it on a grace period, and that grace period ends permanently on November 30, 2026. After that date, no further data lands in the lake through that pipeline. Downstream Synapse pipelines, Power BI datasets, and any custom ETL jobs reading from that storage account simply stop receiving updates, with no error thrown anywhere obvious enough to trip an alert.

What is not retiring, despite frequently being confused with the legacy add-in, is Azure Synapse Link for Dataverse itself. Microsoft has stated plainly that Synapse Link is a long-term supported service. The naming has shifted again as of the July 2026 UX refresh: the feature is now presented under a unified “Link data” page in Power Apps, split into “Fabric Links” as the recommended path and “Other Links” covering the Azure Synapse option. If your team has been searching documentation for “Export to Data Lake” and finding nothing current, that rename is why.

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Fabric Link or Synapse Link: The Decision That Actually Matters

Once the rename is out of the way, the real architectural decision is between two genuinely different integration models, and picking the wrong one for your organization’s actual downstream consumers is the most common mistake we see in migration planning.

Link to Microsoft Fabric is a no-copy model. Data stays inside Dataverse’s managed storage and is exposed to Fabric and Power BI through OneLake shortcuts rather than being physically copied into a separate account you control. Setup is fast: a four-step wizard handles workspace identity authentication (now the recommended method over service principals, since Microsoft’s own release notes describe it as removing “the most common Fabric link setup failure mode”), table selection, and initial sync, which typically completes within about sixty minutes for moderate data volumes. The tradeoff is that you do not own the underlying storage account, table selection for non-system tables is largely automatic rather than admin-curated, and any custom pipeline tooling outside the Microsoft Fabric ecosystem has no direct file-level access to the data.

Azure Synapse Link for Dataverse, by contrast, continuously exports data as Delta Parquet files into a storage account your organization owns and controls. If your analytics estate depends on non-Microsoft tools, custom Spark jobs reading raw Parquet, or an existing Synapse workspace with pipelines your team has already built and tuned, this is almost always the correct choice, and it remains fully supported going forward. The tradeoff is that you take on more operational responsibility: managing the storage account, its firewall rules, and eventually a private endpoint migration if your organization needs one (a related but separate deadline, the trusted-services firewall exception for private link configurations, retires August 1, 2027, so build that into planning if it applies to you).

Where the Export to Data Lake Migration Breaks Existing Pipelines

This is the part of the Export to Data Lake migration that catches teams off guard even after they have chosen a replacement path, because the schema produced by Fabric Link and Synapse Link is not a drop-in replacement for what the legacy add-in produced. Several changes will break any downstream job written against the old CSV-based output.

The most disruptive change for finance and operations data is that the primary identifier field, previously exposed simply as ID, is now surfaced as FnO_Id. Any view, stored procedure, or Power Query step that hard-codes the old column name will fail or silently return nulls after cutover, and this is worth grepping for across your entire analytics codebase before you flip the switch, not after. Time zone identifier (TZID) fields, which were largely unused legacy artifacts in the old export anyway, have been dropped entirely. Binary data columns are no longer included in the export at all, and nvarchar(max) fields are truncated at 2,000 characters, which matters if any process was relying on long free-text fields such as notes or descriptions coming through intact. On the positive side, the new format adds a proper isDelete flag for row-level soft-delete tracking, which the legacy CSV export never handled cleanly, so reconciliation logic that used to infer deletions by diffing snapshots can often be simplified.

There is also a prerequisite that trips up more migrations than the schema differences themselves: only tables with the Track Changes property enabled will appear as selectable in either Fabric Link or Synapse Link. A meaningful number of legacy finance and operations entities were never configured for change tracking, and some cannot have it enabled without developer involvement to extend the entity definition. Audit which tables your current pipeline depends on and confirm change tracking status on each one before you assume the new link will simply mirror what you already have.

Solution architect reviewing a cloud data pipeline migration diagram on a monitor in an office setting

Sequencing the Cutover Without a Data Gap

The safest sequencing we recommend is to stand up the replacement link in parallel with the legacy export while both are still functional, rather than decommissioning the old pipeline first and troubleshooting the new one under deadline pressure. Run both for at least one full reporting cycle, ideally a month-end and quarter-end close if the data feeds financial reporting, and reconcile row counts and key totals between the two outputs before cutting anything over. Microsoft’s FastTrack team publishes two open-source transition tools worth using rather than building your own equivalents from scratch: a SQL Analytics Endpoint tool for validating Fabric Link output against expectations, and a Virtual Data Warehouse tool for Synapse Link migrations. Both are available through the Dynamics 365 FastTrack Implementation Assets repository and can shortcut a meaningful amount of validation work.

Two configuration details are also worth checking before you commit to a path: profiles that were originally set up in CSV format cannot be linked forward to Fabric, and profiles secured with managed identities have the same restriction. Both require a fresh setup rather than an in-place conversion, so factor that into your timeline if either applies to your current configuration. Once the new link is validated and running cleanly, the legacy Export to Data Lake add-in itself should be formally uninstalled through Lifecycle Services rather than simply left dormant, both to avoid confusion for the next person who inherits the environment and to remove a component that will stop functioning anyway once November 30 passes.

Where This Leaves Architecture Teams

None of this is a difficult migration in isolation. A Fabric Link setup for an organization with modest data volumes and no custom storage requirements can realistically be completed in a day, including validation. What makes this deprecation worth taking seriously now rather than in October is the schema drift buried inside it: the ID field rename alone is enough to quietly break a Power BI model or a downstream integration that nobody has looked at closely in over a year. We have walked several clients through this exact transition at Routeget Technologies, and the pattern holds consistently: the technical setup is fast, but finding every place the old schema was assumed to be permanent takes the real time. Start that inventory now, while there are still weeks to spare rather than days.

#ExportToDataLake #AzureSynapseLink #MicrosoftFabric #DataverseIntegration #CloudArchitecture #ERPGovernance

The Power Automate RPA Licensing Math That Breaks Most Finance Automation Rollouts

Finance operations team monitoring automated workflow dashboards in a modern control room

A finance operations director we worked with last quarter had a good problem: her three-bot pilot for invoice matching had worked exactly as promised. Exceptions dropped, the AP team stopped re-keying vendor data, and the CFO wanted it rolled out across the whole shared services center by the next close cycle. Then IT came back with a licensing quote roughly eight times higher than what the pilot had cost per month, and the rollout stalled in budget review for six weeks while everyone tried to figure out what had changed.

Nothing had changed technically. What changed was the license type, and Power Automate RPA licensing is exactly where a surprising number of finance automation programs lose momentum right after they prove themselves.

Power Automate RPA Licensing: Attended Pricing Is the Pilot Price, Not the Production Price

Most Power Automate pilots run attended, meaning a real person is logged into the workstation and the desktop flow executes while they’re at their desk, often triggered manually or from a scheduled prompt during business hours. Attended automation is licensed through Power Automate Premium at $15 per user per month, and that single per-user cost is genuinely all it takes to build and run desktop flows on a registered machine, with access to premium connectors, process mining, and a healthy daily action allowance built in.

That price is why so many pilots clear budget approval without much friction. Fifteen dollars a month per analyst is a rounding error against the labor hours it replaces, and it’s the number finance teams anchor on when they start sizing a broader rollout.

The problem is that production finance operations rarely stay attended. Month-end close doesn’t wait for someone to be logged into a specific machine, and neither does an overnight AP batch or a weekend bank reconciliation run. The moment a bot needs to run unattended, meaning on a schedule or a trigger with nobody present to log in and supervise it, Microsoft requires a Power Automate Process license (the plan formerly marketed as “per flow”), priced at $150 per bot per month if you supply and register your own machine, or a Hosted Process license at $215 per bot per month if you want Microsoft to provision and manage the virtual machine instead. Attended and unattended aren’t tiers of the same product; they’re licensed as genuinely separate capabilities, and a pilot built on the cheap one tells you almost nothing about what the expensive one will cost.

Finance operations analyst reviewing an automation workflow diagram on a monitor

Concurrency Is the Multiplier Nobody Models in a Pilot

The second gap is even easier to miss, because it doesn’t show up until someone asks how many things need to happen at once. A single Process or Hosted Process license grants one unattended bot capable of one desktop flow run at a time, with a daily ceiling of 250,000 actions. That’s usually plenty of headroom for a single automation running serially through a queue.

Finance operations at scale rarely stays serial, though. During a close cycle, a shared services team might need five invoice-processing automations running in parallel to clear a backlog before a reporting deadline, not one automation running five times faster. Each concurrent execution requires its own license; Microsoft allows stacking up to ten Process licenses against a single flow definition for higher-volume scenarios, but the cost scales linearly with concurrency, not with automation count. A team that budgeted for “the AP bot” as a single line item, based on pilot behavior where one instance handled everything sequentially, will find that peak-period parallelism during close is exactly the scenario that multiplies the bill.

This is worth raising explicitly with finance leadership before the rollout budget goes to the board, because it’s the single most common reason an approved RPA business case comes back for revision. The question to ask isn’t “how many bots do we need,” it’s “how many need to run at the same moment at our busiest point in the month,” and the answer to that question is what actually drives the license count.

Hosted Machines Change Who Owns the Infrastructure Risk

There’s a third decision buried in that $150 versus $215 per bot spread that has nothing to do with automation logic and everything to do with who’s on the hook for infrastructure. A standard Process license assumes your organization registers and maintains the machine the bot runs on: a real or virtual Windows endpoint that someone patches, secures, and keeps available. For an IT team already running a mature VM management practice, that’s a marginal addition to existing work.

For a finance-led automation initiative without dedicated infrastructure support, though, that machine becomes an unbudgeted ownership problem. Microsoft’s Hosted Process model addresses this directly: Hosted Machine Groups run on Azure infrastructure provisioned from a custom VM image through Azure Compute Gallery, with dynamic load balancing across the group and automatic reprovisioning during maintenance windows, and credential management shifts from static usernames and passwords to secrets held in Azure Key Vault rather than a spreadsheet somebody has to remember to update. None of that requires a dedicated RPA infrastructure team to operate day to day.

The sixty-five-dollar-per-bot premium for Hosted Process is, in effect, the price of not needing that team. Whether that trade makes sense depends entirely on whether the automation program is going to stay a handful of finance workflows or grow into a broader shared-services capability that justifies its own operational ownership. Organizations that guess wrong in either direction end up either paying for managed infrastructure they had the staff to run themselves, or trying to bolt VM governance onto a finance team that was never set up to own it.

Budgeting the Rollout, Not the Pilot

None of this means Power Automate is a poor fit for finance automation; the platform’s architecture guidance for scaling RPA operations is specifically built around exactly these production patterns, with capacity planning, committed and maximum bot counts, and utilization thresholds designed for high-volume periods like quarter-end processing and seasonal order backlogs. The issue isn’t the platform. It’s that the pilot’s economics and the production rollout’s economics are different products with different pricing logic, and treating them as the same line item is what turns a successful proof of concept into a stalled budget conversation.

Before a finance automation pilot goes to the board for rollout funding, it’s worth walking through three questions with whoever owns the license budget. First, will production runs actually be unattended, and if so, has the Process or Hosted Process cost been modeled instead of the Premium per-user rate the pilot used. Second, what does peak concurrency look like during the busiest close or reconciliation window, since that number, not the total automation count, determines the license count. Third, does the organization want to own the machine infrastructure or pay Microsoft to manage it, and is that decision being made deliberately rather than defaulting to whichever option the pilot happened to use.

Getting those three answers before the budget request goes out doesn’t just prevent an awkward six-week delay. It’s the difference between an RPA program that scales predictably alongside the finance function’s actual workload and one that keeps getting re-approved a bot at a time because nobody modeled what production would really cost. We’ve walked several finance operations teams through exactly this exercise before their rollout budgets went to committee, and the pattern is consistent: the teams that model concurrency and hosting decisions up front rarely get sent back for revision, and the ones that don’t, almost always do.

#PowerAutomate #RPALicensing #FinanceTransformation #ERPGovernance #DigitalTransformation #EnterpriseAI