From file server to SharePoint step by step, without a big bang

Part two of the Documents in SharePoint series. Last time we covered what SharePoint does as soon as you turn it on. Today: how to get there without bringing the company’s work to a halt for a month.

When we talk to a company about moving its documents, the first worry is almost never “will it work?”. It’s “how on earth are we going to move all this?”. The server holds hundreds of thousands of files, a hundred folders with their own permissions that someone set up long ago and nobody understands today, and people who know exactly where everything is. The idea of moving it all over one weekend and having everyone learn a new system on Monday is frightening — and rightly so.

The good news is that it doesn’t have to be done that way, and usually it shouldn’t be. Moving documents isn’t a house move but a gradual change in the way you work. And that can be done in small, verifiable steps, each with its own benefit, and after each one you can decide whether to carry on.

Step 0: find out what’s actually on the server

Before you design anything, it pays to know what you’re working with. How much data and in which folders, how old the files are, when someone last changed them, how deeply they are nested and how long their paths are. On most servers it turns out that a large part of the content is an archive nobody has worked with for years — and that doesn’t need to be moved, or at least not straight away.

The inventory also reveals folders where the permissions don’t match who actually works with the documents. That’s valuable information even if nothing ends up being moved. The tool you’ll later use for the move can help too: Migration Manager (more on it below) can first just scan the files, without moving them, as a pre-assessment.

Step 1: a pilot in one area of work

For the first step, pick an area that meets three conditions: it’s small, it has a clear owner, and moving it to SharePoint gives it something the server can’t. A typical candidate is directives, policies and ISO documentation: dozens of documents, a small group of authors, and approval, numbered versions and an audit trail pay off at the very next audit. Part three covers this in detail.

The pilot has two goals. The first is to check whether the new way of working suits people — not in theory, but on real documents. The second is to learn what the big move will need: how to name sites, how to set permissions, how to train people. Mistakes are cheap on forty documents, not on forty thousand.

Step 2: design the structure for the rest

The most common migration mistake is copying the folder tree from the server 1:1 into one giant library. It works on day one, and then it turns out you’ve brought all the old problems with you — and added a few new ones.

It’s better to start from who works with what and who is allowed to access it:

• A site per team or area where permissions differ. Sales, finance, HR and management each have their own space with their own members.
• Libraries by type of content inside a site — contracts, quotes, project documentation. Each library can have its own properties and templates.
• Permissions at site and library level through groups, not on individual folders. As few exceptions as possible. Once saved, a document inherits the permissions of the place it belongs to, and nobody has to set them by hand.

This is usually where it turns out that a hundred folders with their own permissions can be described by ten or twenty groups of people. That simplified map is, incidentally, the most valuable outcome of the whole project — for security too.

Step 3: move team by team

Each team moves when its space is ready. A short training session on its own documents, simple rules for “what goes where” and a contact person who answers questions for the first few weeks. Meanwhile the other teams carry on working as before.

Two practical things decide whether it succeeds:

• After the move, set the old folder on the server to read-only. Otherwise within a few weeks people start working in two places and nobody knows which version is current.
• Let people keep File Explorer. They can add the library as a shortcut in OneDrive and work with it like a folder. The change of habit is then much smaller than if they had to do everything in the browser.

Step 4: what to do with the archive

The archive has two honest options. Either it stays on the server, read-only, until the server reaches the end of its life, or it gets moved too — ideally into libraries of its own, separate from live work.

What to use for the move

For moving file shares, Microsoft has its own tool: Migration Manager. You’ll find it right in the SharePoint admin center, and the work is done by an agent that you install on a Windows computer or virtual server on the network, from where it can see the file shares. Before each move it scans the files, and it transfers them including the folder structure. According to the description of file share migration in Microsoft FastTrack, basic metadata carries over too: the created and modified dates, and who created and last modified the file.

It can carry over permissions only in part. Migration Manager has an option to preserve permissions, but it only transfers basic NTFS permissions as you see them in File Explorer, and it needs users on the server to be matched with accounts in Microsoft 365 (typically through Active Directory synchronisation). Advanced permissions and explicit denies (Deny) don’t carry over — so content that was protected by a deny may become accessible. Permissions set on the file share itself don’t carry over either. That’s another reason we recommend not carrying permissions over, but setting them up according to the new structure from step 2.

For large volumes and complex scenarios there are also third-party tools; for a typical company, though, Migration Manager is usually enough.

What doesn’t carry over and what to avoid

This is the part worth knowing before the first file is moved.

• Version history from the server doesn’t carry over. Shadow copies stay on the server; in SharePoint, history starts on the day of the move. If you need an older version of a document, keep the server available read-only until a set date. Windows file attributes, such as “read-only” or “hidden”, don’t carry over either.
• Path length: no more than 400 characters. The whole path counts — library, folders and file name. Deeply nested folders with long names need shortening before the move — and it’s better to find that out during the inventory than from a migration error.
• Sync has a practical limit. Microsoft recommends syncing no more than 300,000 files in one library to Windows, and warns that the same performance problems can occur when a person has 300,000 items in total across all the libraries they sync. That’s another reason content is split into several libraries by area of work, not one giant one — and people add shortcuts only to the folders they really work with. Microsoft recommends OneDrive shortcuts over the Sync button, because only the selected folder is synced, not the whole library.
• The number of files isn’t the limit, storage is. A library can hold up to 30 million files and folders, but the whole organisation gets 1 TB plus 10 GB for every licence — with a large server, work out whether you’ll need to buy extra space. Otherwise, the problem with large libraries is mainly clarity, sync and permissions: for a library or folder with more than 100,000 items you can no longer break permission inheritance. That’s another reason to design permissions before the first file is uploaded to the library.

When you’re worried people won’t find their way around

The most common worry after a move is that people won’t know where things are and where to save what — on the server they had their map in their heads, in SharePoint they don’t. What helps most is a clear, easy-to-understand structure and a few rules. There are also tools that make saving and finding things so simple for people that they don’t need to know the structure; ours is the My Documents app, but the principle matters more than the specific tool: people should be asking “what am I saving and for whom”, not “which site does this belong on”.

Key takeaways

1. Moving documents isn’t a house move, it’s a change in the way you work. That’s why it goes step by step — pilot, structure, teams, archive — with a decision after each step on whether to carry on.
2. A 1:1 copy of folders carries the old problems over too. A structure based on who works with what, and permissions through groups, are the most valuable outcome of the whole project.
3. Deal with limits during the inventory, not during the move. Path length, library size and the loss of version history can be planned for; a surprise halfway through the move can’t.

---

At EP365 we move documents from file servers step by step — from the inventory and structure design, through a pilot, to moving individual teams and training. We most often start with a Restart, which shows what you really have on the server and in Microsoft 365. If you’re weighing up where to start, get in touch.

In the next part: ISO 27001 and ISO 9001 in SharePoint — what an auditor wants to see for documented information, what you can evidence with built-in tools and where SharePoint alone isn’t enough.