What it does

Repoints an existing Azure Data Lake Delta tables data source at a Fabric OneLake lakehouse in place, keeping the tables, mappings and every downstream dependency — unification, relationships, enrichments, segments — intact. It's the migration path that avoids deleting the data source and rebuilding everything hanging off it, and it can be reverted.

Key facts

• Scope is narrow and specific: an existing Azure Data Lake Delta tables data source moving to a OneLake lakehouse holding the same tables. It isn't a general-purpose source swap.
• The target lakehouse must hold managed Delta tables. CSV, non-Delta Parquet and Fabric Data Warehouse tables are all unsupported. Delta tables exposed through Fabric shortcuts are supported.
• Table and column names and data types must match what the data source reads today, and the tables must sit inside a single schema (folder) where the lakehouse supports schemas.
• There's a Verify step that generates the target schema and compares it against the data source's configured tables and columns before you commit. It reports missing tables, missing columns with expected type, and type mismatches as table.column.
• Verification runs in one of two modes depending on how the environment is configured. Strict mode keeps Convert disabled until the target matches. Advisory mode warns and lets you proceed at your own risk.
• Changing workspace, lakehouse or schema after a successful verify clears the result — you verify again.
• Revert data source puts it back to the original Azure Data Lake Delta tables location and strips the OneLake connection details. That safety net depends on two things being true: the original Azure location is still being fed and still has its manifests and schemas, and nobody has edited the converted data source.
• Prerequisites are the standard OneLake connection ones, plus a validated workspace-level Private Link where the workspace has Inbound Access Protection enabled.
• Conversion and revert both put the data source into Refreshing. Progress is per-task in the Progress details pane.

When to use / skip

Use it when a client already ingests Delta tables from ADLS and wants to drop the staging layer and read straight from their Fabric lakehouse — that's the case it was built for, and rebuilding the data source by hand would mean reconstructing every mapping and relationship downstream of it. Skip it if you're standing up a new source, where connecting directly to OneLake is simpler and carries none of this risk. Skip it too if the lakehouse doesn't yet hold matching Delta tables in one schema: the conversion isn't a data migration, it assumes the data is already there.

Configuration decisions

• Whether your environment is in strict or advisory verification mode, and whether you'd ever use advisory. Proceeding past a failed verify means errors can surface at the next refresh and unification run rather than during the conversion.
• Whether to keep writing to the Azure location during and after the cutover, and for how many full refresh cycles. This is the decision that determines whether revert is actually available to you.
• Whether the target workspace needs Inbound Access Protection and a Private Link, which has to be created and validated before the conversion, not during it.
• The schema field: named schema, or empty where the data doesn't use one. Getting this wrong is the most common verification failure.

Gotchas

• Editing the converted data source destroys the rollback. Adding, removing or configuring tables after conversion wipes the saved rollback information and there's no way back. That's the single most expensive mistake available here, and nothing stops you making it.
• The revert path also assumes someone kept the Azure side alive. If the client switched off the ADLS pipeline the day after cutover — which is exactly the cost saving they're doing this for — revert becomes theoretical.
• Don't stop the refresh, on either the conversion or the revert. The documentation is unusually blunt about this and offers no recovery guidance if you do.
• An empty or endlessly-refreshing workspace or lakehouse list is a permissions problem, not a loading problem — Customer Insights can't see the workspace. Check external access settings and the Private Link before debugging anything else.
• Verification failing to complete at all (missing target manifest or baseline model) still lets you convert, unverified. Treat that as a stop, not a shrug.
• A successful conversion isn't a successful migration. Check that unification, segments and measures all ran and that profile and segment counts land where you expect, because failures can appear one refresh later.

Consultant notes

• Sequence this as a proper cutover with a dual-run period, not a config change. The revert window is defined entirely by "Azure still being fed and nobody edited the source" — write both of those into the runbook and give the client a date after which they can decommission ADLS. Left implicit, someone turns off the old pipeline in week one to save money and quietly removes the rollback.
• The verify step is the whole value of the feature; insist on a clean verify even where the environment allows advisory mode. A type mismatch that passes as a warning turns into a failed unification run, and by then you're debugging a live environment rather than reading a comparison table.
• Expect the schema requirement to be the sticking point. Clients building a lakehouse organise it by domain across several schemas; this needs the data source's tables in one. That's a Fabric-side change to negotiate before you book the conversion.
• Freeze data source changes for the dual-run window, and say so explicitly to whoever owns the Fabric workspace. The rollback-destroying edit is most likely to come from someone helpfully adding a table, not from the person doing the migration. See [[feature-unification-fabric-onelake-attach]] and [[feature-fabric-onelake-source]].

---

Recheck after the next release wave — verification modes and the revert preconditions are the parts most likely to change, and they're the parts a migration plan depends on.