Information estates
Why file migrations fail before they start
Most file migrations do not go wrong during the move. They go wrong months earlier, when nobody can say what the estate contains, who owns it, or what the target should look like.
Every large organisation eventually decides to move its files. Into SharePoint, into a new tenant, off a legacy file server, or into whatever platform follows the current one. The tooling for the move itself is mature and mostly reliable, yet a striking number of these projects run late, cost more than planned, or quietly deliver the old mess into a newer, more expensive home.
The failure is rarely in the migration weekend. It is in the assumptions made months earlier, before anyone booked it.
The inventory nobody has
Ask for a list of what is in scope and you will usually be given a storage report: total volume, file counts, perhaps a breakdown by departmental share. That is not an inventory. It tells you how much there is, not what it is.
The questions that decide whether a migration succeeds look more like this:
- Who actually owns each area of content, and does that person still work here?
- How much of the estate is duplicate, stale, or migrated once already and forgotten?
- Which folders are load-bearing, referenced by shortcuts, links, scripts and scheduled jobs?
- What is sensitive, regulated or subject to retention, and does its location reflect that?
- Which permissions are deliberate, and which are historical accidents?
None of these can be answered from a storage report, and none of them answer themselves. They need discovery: read-only analysis of content, ownership, age, duplication and access, done before dates are promised to anyone.
Structure debt compounds quietly
File estates accumulate structure debt the way codebases accumulate technical debt. A folder tree that made sense in 2012 gains a decade of exceptions: acquisition leftovers, personal areas used as team areas, archives inside archives, and copies made because nobody was sure the original was safe to touch.
What good preparation looks like
Preparation does not need to take months, but it does need to happen in the right order.
The preparation sequence
- 01InventoryContent age, duplication, ownership, access and usage, gathered read-only before anything is promised.
- 02ClassifyCurrent, stale, duplicate, sensitive, unknown. Plain categories beat elaborate taxonomies.
- 03Design the targetAround how the organisation works today, not around the accidents of the old tree.
- 04Map source to targetExplicitly, including what will not move and why.
- 05Agree sign-offWith the people who own the risk, before anything moves.
Decide the target before the tooling
Tool selection is the most enjoyable early decision and the least important one. A clear target structure, agreed ownership and an explicit exclusion list will survive a change of migration tool. The reverse is not true.
“The migration is the easy part. Knowing what deserves to be migrated is the work.”
Ready to migrate when
- Every in-scope area has a named owner who has confirmed what it is for.
- Content is classified, and stale or duplicate material is marked for archive or disposal.
- The target structure is agreed and written down, not implied.
- The exclusion list exists, with a reason recorded against every entry.
- Sign-off points are booked with the people who own the risk.
Preparation at this scale is also where AI-assisted analysis genuinely earns its keep, provided the judgement stays human. I have written separately about where AI genuinely helps in platform engineering and where it does not.
