File sharing migration is a permissions problem, not a copying one

Moving files between two storage products is not a data problem. The bytes copy reliably and quickly. What does not copy reliably is everything around the bytes: who could see them, where the old links pointed, and which version was the one people trusted.

Plan the move around permissions and links, treat the copy as the easy part, and you will avoid the two failure modes that make these projects memorable.

What to take away

What survives the copy, and what does not

The two rows that cause trouble later are the ones about permissions granted to individuals and links sent to outsiders. Both are invisible in a folder listing and both fail after cutover rather than during it.

Inventory before you schedule

Do not commit to a date until you can answer these with counts rather than impressions.

Question seven is the one that changes the plan. If a third of the estate is dormant, moving it live is wasted effort and wasted money, and an archive that is restorable on request is usually the better answer. Deciding what not to move is the single largest lever available.

Clean up first, and only once

Every hour spent tidying before the move saves several after it. Three tasks are worth doing in this order.

Convert individual grants to group grants. This is tedious and it is the thing that makes the destination maintainable. A permission attached to a person is a permission that has to be found again the day that person changes role.

Expire or revoke external links that nobody needs. You will find some that were created for a single meeting years ago and never closed. The category overview explains why these outlive their purpose so reliably.

Retire the automated jobs nobody can name an owner for. If nothing breaks in two weeks, they were not needed, and if something does break you have found the owner.

Sequence, with the copy in the middle

A workable order looks like this, and the first and last steps take longer than the middle one.

Step six is not optional. Somebody will need a file that did not come across, and a frozen source is the difference between a five minute answer and a restore from backup. Give the period a date and hold it.

Links, and their afterlife

Old links live in mail archives, in work items, in documents, and in systems nobody remembers wiring up. You cannot find all of them, so decide the policy instead.

Three approaches are honest. Leave the source readable at the old addresses for a long period. That is gentlest and costs the most.

Break them at cutover and communicate loudly. That is cheapest and generates the most noise in week one.

Replace the most consequential ones deliberately: search your own mail and work items for the old domain, then reissue those.

Whichever you pick, say it in advance. The failure people remember is not a broken link; it is a broken link nobody warned them about.

Reconcile with numbers

A migration is finished when the counts agree, not when the project meeting says so.

Compare item counts and total size for each top-level space, source against destination, and investigate every difference, not a percentage. List the failed items in full, and decide each one rather than reporting a success rate.

Then check a sample of permissions by signing in as real accounts, including one external account. Confirm that what they can reach matches what the plan said.

This is also the moment to test the fallback. If the reconciliation is bad enough to reverse the decision, you need to know that you can, which is the ordinary discipline of any contingency plan: the plan is not real until it has been exercised.

Once the frozen period ends and the source is decommissioned, remove it properly rather than leaving it dormant. Storage that nobody administers is storage that nobody patches, and the guidance on disposing of data is worth reading before you decide that switching off a service counts as deleting its contents.

Where this sits

The migration overview covers the general sequence, freeze window, and rollback question for any category. The permission and link problems here are storage-specific.

If mail moves at the same time, do not run both cutovers in one weekend. The mail move has its own failure modes and its own week of noise. Lifecycle belongs with the administration console.

Common questions

Can we migrate without any downtime?

Usually you can avoid downtime and not avoid confusion. A period where both sides are writable produces divergent copies, which is worse than an hour of read-only. Prefer a short freeze that people are warned about.

Should we bring the version history?

Only if you can name the situation where you would use it. For most estates the answer is no, and saying so at the start prevents a slow argument in week three.

How long should the source stay readable?

Long enough to cover one full cycle of your work, which for many organizations means a quarter. Set the date, tell people, and remind them a fortnight before it passes.

What is the most common thing that gets missed?

An automated job writing into a folder that nobody realized existed. It fails silently, and it is usually noticed a month later when a report is empty.