A finance team called us about what they thought was a reporting problem, and it turned out to be an architecture problem they had been feeding for two years. Their nightly BYOD export into an Azure SQL database had grown to the point where it no longer finished before people arrived. The dashboards that were supposed to show yesterday's close sometimes showed the day before's, because the export was still grinding away when the analysts opened them. Their first instinct was the one we hear most often, which was to ask for a bigger SQL database. The real answer was to stop exporting on a timer altogether.
BYOD, Bring Your Own Database, was a good answer for a long time. F&O pushed your data entities into an Azure SQL database that you controlled, and your Power BI reports and warehouse loads queried that database directly. It worked because it was simple to reason about, and for years we built analytics on top of it without complaint. It has since run out of road, and Microsoft has been signposting the exit for a while. The schedule-based export does not scale, several entities never supported incremental push so they reloaded everything on every run, and the whole direction of F&O analytics has moved to the data lake. Synapse Link is where that direction lands, and the teams who get burned are the ones who treat the move as swapping one connector for another.
Why BYOD eventually fails on you
The thing to understand about BYOD is that its limits are baked into the model, so no amount of tuning gets you past them. Once you have lived with it at scale, the three walls are familiar.
The first is staleness. Your data is only ever as current as the last export that finished, so a nightly job means the business is looking at numbers that can be the better part of a day old. You can run the export more often, but then it competes with everything else for resources, and you are back to trading freshness against load with no setting that satisfies both. There is no continuously-current version of BYOD because the model is batch by design.
The second is the cost of full reloads. Entities that support incremental export send only what changed, which is fine, but the ones that do not re-export the entire table every single run. As those tables grow, the export window grows with them, slowly, until one quarter it stops fitting in the slot you gave it. That is exactly the wall the finance team hit, and they had no idea it had been creeping toward them for months.
The third is subtler and shows up later: BYOD lands your data as relational tables, and every report you build couples itself to that specific SQL schema. The convenience you enjoy on day one becomes the reason a small change to the export ripples out and breaks half a dozen reports two years later. None of this is a problem you tune away. It is the model telling you it is finished.
What Synapse Link does differently
Synapse Link throws out the timer. Instead of F&O pushing entities into a SQL database on a schedule, it tracks changes as they happen and streams them into Azure Data Lake Storage, where they land in an open analytical format that Azure Synapse reads directly.
In practice the difference you feel first is freshness. Because change tracking captures inserts, updates, and deletes continuously, the lake stays close to current without anyone running a reload, and the staleness window shrinks from "since last night's export" to "since the last change came through." The difference you feel second is that a big, slowly-changing table stops being a nightly tax, because Synapse Link moves the changes rather than re-copying the whole table. And the difference that matters most for the long run is that your data now lives in a lake that consumers read through Synapse, rather than in relational tables they are welded to, which loosens the coupling that made BYOD so brittle over time.
This is not a brand-new idea bolted on. It is the same data-lake destination that embedded Power BI through the Entity Store and then BYOD were both steps toward. Synapse Link is simply where F&O analytics was always heading.
The prerequisites are most of the job
People underestimate this part because the data flow looks like the work, when really the setup is. Before a single row moves, both the environment and the Azure side have to be in order.
The environment has to be on update 10.0.34 (PU58) or later, so older ones need updating first. Power Platform integration has to be enabled, and there is a sharp edge worth calling out here, because on cloud-hosted developer environments this can only be set up at deployment time. If a dev environment was provisioned without it, you cannot retrofit it; it has to be redeployed, and finding that out late is a genuinely annoying surprise. The SQL row-version change tracking configuration key has to be switched on, since that is the mechanism that makes incremental capture possible at all. And on Azure you need an ADLS Gen2 storage account, a Synapse Analytics workspace, and a Synapse Spark pool on version 3.1 or later, all provisioned in the same region as the F&O environment. We have watched a region mismatch quietly tax a project, because it does not fail outright; it just shows up later as latency and egress charges that nobody budgeted for.
Get this foundation right and the rest is straightforward. Get it wrong and you will be unpicking it after data is already flowing, which is the worst time.
Cut over in parallel, and turn BYOD off last
The way these migrations go wrong is always the same. Someone treats it as a swap, switches BYOD off and Synapse Link on, and then spends the next week discovering which reports were quietly depending on the old SQL database. The way to avoid that is to refuse to swap anything until you have proven the replacement, report by report.
Start by standing Synapse Link up next to the BYOD export while BYOD keeps running. Both targets fill in parallel and nothing downstream changes yet, which buys you the room to migrate calmly. Then move your consumers across one at a time. For each Power BI report, warehouse load, and integration, repoint it from the BYOD SQL database to reading the lake through Synapse, and check it on its own before touching the next one. This is where the relational-to-lake difference surfaces in earnest, because queries written against SQL tables and joins have to be reworked to read the lake through Synapse, and doing it one consumer at a time keeps each of those reworks contained instead of facing all of them at once.
The step teams are tempted to skip is reconciliation, and it is the one that saves you. For every report you move, reconcile its row counts and key totals against the BYOD output over a real period, so you are certain the lake is telling the same story the old database told. Pay closest attention to deletes, because a delete that change tracking failed to carry through is an invisible discrepancy that no one notices until someone reconciles a total by hand and the numbers do not match. Only when every consumer has been moved and checked do you switch off the BYOD export. Until then it is your safety net, and it costs almost nothing to leave it running a little longer.
What you are left with
When the migration is done properly, you end up with an environment on PU58 or later with Power Platform integration and row-version change tracking enabled, the Azure resources sitting in the right region, and Synapse Link streaming incremental changes into the lake with deletes verified. Every Power BI report, warehouse load, and integration reads the lake through Synapse and has been reconciled against the output it used to trust, and BYOD was only retired after all of that was confirmed. You also walk away with a written map of which consumer reads which entity, so the next schema change has a blast radius you can actually see rather than discover.
The lesson we keep relearning is that the connector is the easy part. Synapse Link is the better architecture and it is where you want to be, but the value only arrives if every report that leaned on the old SQL endpoint makes it across intact. Spend your effort on the cutover, not the setup screen.
