Information management
From network drive to SharePoint Online
Moving the Z drive is not the problem. The problem is what is on that drive, who may reach it, and whether people will still find what they need afterwards.
We guide that journey from the first measurement to the moment the old drive is actually switched off. With an assessment everyone agrees on, a structure that holds up and permissions that stay explainable.
A drive that has been running for years usually holds more than what is still in use. Exactly what is on it, we measure first.
Our approach in
six phases
We work department by department. Assess first, then set up, and only then move. Every phase stays readable and you can decide after each one whether to continue.
The first department doubles as the pilot. What it tells us about pace, resistance and surprises is what we use to plan the rest realistically.
Baseline and inventory
We scan the drive and also map your existing SharePoint sites and teams. Without that second step you end up building next to the environment that is already there.
What you have after this phaseAn analysis report per department and an inventory of what already exists, with figures everyone agrees on.
Clean up and decide
Empty folders, duplicates, files from people who left and old archives are mapped out and put on the table. That way you can see, with the figures attached, what you take along and what you leave behind.
What you have after this phaseA settled migration scope, plus an archive route for everything that does not move but may not be deleted either.
Target architecture
What the new layout looks like depends on how you work. We look together at which bodies of information exist, who shares what with whom and what has to stay shielded. The layout follows from that, with a workable mix of folders and metadata.
What you have after this phaseThe blueprint, the naming conventions and the metadata, validated with the departments involved.
Redesign the permissions
Permissions are redesigned at site level, not copied from the drive. Exceptions get their own library rather than an exception on a folder.
What you have after this phaseA permission model you can explain to an auditor, and that stays manageable as the organisation changes.
Migrate in waves
A pilot first, then the rest in manageable batches. The migration runs in the background while everyone carries on working. Just before the switch we run a final pass that only picks up the changes.
What you have after this phaseThe content in its new place, with the right dates and authors, and a report of what could not come along and why.
Adoption and closure
Training per role, a point of contact in every department, and an announced date on which the old drive is actually switched off. Without that date two versions of the truth keep existing.
What you have after this phaseA team that can find its way in the new environment, and an agreed date on which the network drive goes off.
The report you receive
The analysis report is the heart of phase 1. It is deliberately objective: figures, charts and tables, without judgement and without having already decided where anything should go. The conclusion and the migration proposal sit right at the end, so you read the facts first.
The register, as a pdf
A readable document per department, built in eight fixed parts:
- Overview: files, folders, volume, depth, longest path
- Volume per top level folder, with the largest folders listed separately
- Age, both on last modified and on last accessed
- Structure: depth, path length and the ten longest paths
- Activity over the last three, six and twelve months
- Technical checks, each with a clear verdict
- Detail per top level folder
- Conclusion and migration proposal
The dashboard, to drill down
The same figures, as an interactive page, to go through together with the department:
- Every chart bar is a filter that recalculates the rest
- Active filters sit at the top and clear with one click
- A table shows which folders sit behind your selection
- A full folder tree you can expand
The file works without an internet connection and without external libraries, so it also opens on a locked down workstation.
The checks we run up front
These are the things that trip a migration halfway through. We look for them before we start, not afterwards.
- Path length. SharePoint stops at four hundred characters for the full path, including site name, library, folders and file name. Deep folder trees reach that faster than you would think.
- Forbidden characters and names. A handful of characters is refused, as are spaces at the start or end of a name and a few old system names. We rename those beforehand, not during the migration.
- Views that grow too large. A view that returns more than five thousand items is blocked. The library itself keeps working, and it is solved with filtered views and column indexes, but you need to know about it in advance.
- Unique permissions. Fifty thousand exceptions in one library is the hard limit, five thousand the sensible maximum. Above those fifty thousand, everything that follows fails.
- OneNote notebooks. With Migration Manager they do not come along from a file share. They travel through OneNote itself, and that is a separate task on the plan.
- File size. Up to 250 GB per file is technically possible. In practice it is more useful to know which files come close, because those determine your lead time.
- Dates that mean nothing. After a server move, folders often all carry the same creation date. We then report on last modified and last accessed, and say why.
- Personal and system files. Temporary files, mail archives and database files do not belong in a document library. We take those out beforehand.
Permissions get redesigned, not copied
This is the most important choice in the whole project, and at the same time the one most often skipped.
A migration tool can translate full control, modify and read into SharePoint roles. But advanced NTFS permissions disappear, and an explicit deny does not come along. That last one is the dangerous case: a folder that was shielded for a group on the drive can open up after the migration.
On top of that, permissions set folder by folder are simply not sustainable. There is a hard limit to the number of exceptions a library can carry, and whoever hits it watches the rest of the migration fail.
So we start from the question of who needs to see what, not from what is configured today. Permissions at site level through groups, a separate library where something genuinely has to be shielded, and exceptions only where there is no other way. That requires decisions from the business, so we schedule them early.
One technical precondition. The user accounts must be correctly mapped to Entra ID. Without that mapping, the columns showing who created and modified what read System Account everywhere after the migration, and that cannot be tidied up afterwards.
The switch, and the drive that goes off
Migrating while you work
Most of the content moves across while everyone carries on using the old drive. Heavy runs are scheduled in the evening and at weekends, because Microsoft throttles throughput during office hours.
One moment of switchover
On an announced date the source goes read only, we run a final pass that picks up only the changes, and from that moment everyone works in the new environment. One moment for everyone, because two versions of the truth side by side, that is the scenario you want to avoid.
Actually switching off the old drive
A migration copies, it deletes nothing. The old drive therefore stays in place until somebody switches it off. We schedule that date with you, with a short period in which the drive is still readable on request. After that it closes for good.
The trap that comes after the migration
A technically successful migration can still fail. Usually in the same way.
People want their Z drive back. So they sync the entire library to their laptop and recreate the old situation. That runs them into the recommended ceiling of three hundred thousand items, above which syncing starts to struggle, and sometimes they delete files believing them to be local copies.
Microsoft therefore recommends shortcuts in OneDrive instead of the sync button. A shortcut follows the user across all their devices and syncs only the folder they actually need. For personal folders such as Desktop and Documents we use Known Folder Move, rolled out in phases at the pace Microsoft prescribes.
Alongside that: training per role, a point of contact in every department, and a service desk trained before the switch rather than after. It is not the most exciting part of a migration, but it is the part that decides whether it succeeds.