Azure Data Lake Storage Gen1 has reached the end of the road. As of this year it's retired — not deprecated, not discouraged, gone — and every organisation still running on it has been pushed, whether they planned to move or not, onto Gen2 or into OneLake. If you're one of the people who spent the last few months on that migration, you have my sympathy and also, I'd argue, my congratulations. Because a forced retirement is an unwelcome gift, and I want to make the case for the gift part.

Nobody enjoys a vendor sunset. It's work you didn't choose, on a timeline you didn't set, to replace something that — from where you were standing — worked fine. But here's the thing I've come to believe after enough of these: the migration you were forced into is almost always the one you should have done voluntarily two years ago and kept deferring because it was never quite urgent enough. The retirement didn't create the work. It just took away your ability to keep postponing it.

The comfortable trap of "it still works"

Gen1 did work. That's exactly the problem. Working infrastructure is the hardest kind to justify replacing, because the case for moving is all future tense — better security posture, better integration, lower long-run cost — while the case for staying is beautifully concrete: it's running, it's paid for, and touching it is risk.

So it sits there. And quietly, underneath the "it still works", the cost of staying compounds. The platform stops getting new capabilities. The integrations you'd want start assuming the newer thing. The number of people who remember how it was set up shrinks. None of that shows up as a crisis, which is precisely why it never wins the priority argument against whatever is on fire this quarter. Deferred modernisation isn't a decision anyone makes; it's a decision that makes itself, every quarter, by default.

A hard retirement date is the one thing that breaks that cycle. It converts an easy-to-ignore slow cost into an impossible-to-ignore deadline. Unpleasant — and effective.

The trap on the other side: moving without modernising

But there's a failure mode here I care about even more than the deferral, and it's the one that turns a forced migration into wasted effort. It's the temptation, under deadline pressure, to move Gen1 to Gen2 as literally as possible — same structure, same folder layout, same assumptions — just to make the retirement stop being your problem. To relocate the thing without rethinking it.

I've written before, at some length, about why relocating a system is not the same as modernising it — why moving your old decisions to new infrastructure just means you pay rent on a mismatch. A storage migration is that lesson in miniature. Gen1 was shaped by what Gen1 was: a standalone data lake, governed and secured and accessed on its own terms. If your destination is OneLake — Fabric's unified storage layer, the single logical lake that every Fabric workload reads from and writes to — then a like-for-like copy squanders the entire point. OneLake isn't just newer storage. It's storage that's natively part of the analytics platform, discoverable in the catalogue, governed by Purview, readable by a semantic model without a copy. Move your Gen1 structure into it unchanged and you've got modern storage arranged according to obsolete assumptions.

What the migration is actually an opportunity to fix

So if you treat the forced move as the prompt it is, here's what it's an opportunity to finally address — the modernisation you were deferring, now with a deadline to make it happen:

  • Governance you can't bolt on later. Landing data in OneLake means it can be catalogued, classified, and lineage-tracked as a first-class citizen rather than as an afterthought bolted onto a standalone lake. Migrating is the natural moment to decide what's sensitive and label it at the source, because you're touching everything anyway.
  • Structure that suits how the data's actually used. A migration forces you to look at every container and folder and ask whether the layout still reflects reality or just history. Most Gen1 structures accreted over years; almost none would be designed the same way today. You rarely get a sanctioned excuse to fix that. Now you have one.
  • The end of the copy-and-refresh reflex. Because OneLake data can be read directly by Fabric's engines, a lot of the "extract it, copy it somewhere else, refresh the copy" plumbing that Gen1-era designs took for granted simply stops being necessary. Carrying that plumbing across untouched is carrying dead weight to a place that offered to take it off your hands.

None of these are "move the files" tasks. They're "reconsider the design while you happen to have everything open" tasks — and that reconsideration is the actual value hiding inside the chore.

A forced migration only feels like a tax if you do it as a copy. Do it as a redesign and it's the modernisation budget you could never otherwise get approved.

Where this leaves you

If you've finished your Gen1 migration by doing the minimum — a faithful lift into Gen2, structure intact, nothing rethought — you've satisfied the retirement and banked none of the benefit. It'll work, and in two years you'll be having the same deferred-modernisation conversation about something else, having learned nothing from the reprieve.

But if you used the deadline as cover to do the thing you'd been putting off — to land in OneLake properly, govern it from the start, and drop the assumptions that no longer apply — then the retirement did you a genuine favour. It gave you permission, and a timeline, for work that's almost impossible to justify on its own merits precisely because the old thing "still worked."

That's the reframe I'd offer anyone still grumbling about the sunset, and I include my past self in that. The vendor didn't cost you a migration. The vendor finally forced a modernisation you'd been quietly avoiding — and handed you, in the bargain, the one thing that makes overdue work actually happen: a date you can't move.