Reader Question: Can I sync my Network Drives to Teams?

Dear Alex, I wish to know if its possible to sync files/folders on my Network Server to teams. I have read a few documentations but all seems to be just for own PCs and not for Server/network drives. Yours is the closest I could see. Please can you help me or direct me to sites where I can read more of these thank you in advance! –Richard

Thanks for this question, Richard. I am guessing you were referring to my series on moving your file server to Teams. I hear various iterations of this question when I meet with IT folks who are eye-balling a move to the cloud, coming from a traditional Windows Server with mapped drives.

To be blunt, the answer is no (most of the time).

But, I think the question is a good opportunity to unpack our thinking around this problem a bit more. To get specific, there are two different scenarios people generally ask me about:

1. Can I keep files “in sync” between my file server, and Teams/OneDrive/SharePoint so that people see the same data from their mapped drives as they do in their apps? * (Answer: No)
2. Can I use a sync tool to migrate data one time into Teams/OneDrive/SharePoint, and then cut people over to it? (Answer: Yes, with caveats)

I think Richard is asking about the first scenario, so we’ll deal with that one to begin. Then we’ll discuss migration afterwards.

You cannot and should not think about trying to keep files “in sync” between a file server and something like Teams/SharePoint. When you make the move to one of these cloud platforms, you MOVE the files (read: delete or at least remove the source directories from view).

The OneDrive sync client is a cloud-to-client sync tool, not a cloud-to-server-to-client sync tool, and no other sync tool exists that will do this for you (if it did, it would be terrible experience, I am sure).

If you move files to the cloud, you don’t need them on your file server. So besides being unnecessary, it’s also just not possible.

SharePoint/Teams is not a file server

Always remember that SharePoint (which powers Teams) is NOT a file server, it is a modern collaboration platform built on the web. SharePoint does things that your file system never could. And it also doesn’t do things that your file system could. They are not 1-1.

Example: a Windows Server file system can keep super long file paths with deep and complex folder and permissions structures. SharePoint/Teams doesn’t do that; you will run into hard limitations. I recently helped an organization that had more than 9-12 levels of nested folders in some places, and way too many instances of broken inheritance. They had to completely reorganize their file structure in order to move to SharePoint and Teams, which only supports a maximum of 260 characters for any given file path.

Therefore, as Robert Crane points out, your structure needs to be wide and flat, not structured and deep.

But here’s the thing–most of the time we find that only a small handful of the server directories are even used, and often there is a mapped drive or a shortcut directly to a folder that contains the bulk of the content we want to work with anyway–so why not just flatten out the structure?

Besides that, research has shown that the time to navigate to data is an exponential curve when you add layers upon layers of folders. Navigating 4-5 levels takes almost twice as long for people as navigating 2-3. In the cloud, you don’t navigate, you search.

Some people think, “But I am really fast at navigating the structure.” That’s cool. You’re fast at being slow. Congrats. The reason for the exponential curve is that layers upon layers of folders = someone else’s mental map of the data. As one person gets to know the structure better, the curve can level out a bit, but every new person has to learn it from scratch–that mental map doesn’t just magically translate–they have to build up the same neurological pathways that others have.

So it is better to reorganize your data anyway and start searching instead of navigating–moving to SharePoint/Teams/OneDrive is a good excuse to get started on the cleanup and modernization project.

SharePoint can also do things like versioning, retention, coauthoring, sharing links with expiry and permissions, metadata, workflows with Power Automate, and more. So you’re giving up all the crappy parts of a file server, and gaining a bunch of cloudy superpowers. Not all bad.

Migration is not what it used to be

However, because these systems are so different, it also means that you can’t just mindlessly slide files over from your old structure into your new one, most of the time. That just doesn’t do anybody any favors.

Many IT people I meet with wish that they could migrate files to SharePoint and Teams just like they could migrate from one file server to another, and hardly anyone notices the change. But you can’t. And you shouldn’t.

There is no DFS or robocopy when you’re moving to the cloud. Besides, why would you move people to this new system if your intention is to treat it like the old one? That is just going to compound your problems. You are moving to a modern, cloud-and-mobile enabled system–so make the most of it! Give your people more than just a bucket to store their shared files in. That means they must STOP some old, inefficient behaviors and START adopting some newer, modern ones.

Thus, you must put the “robocopy” idea out of your mind. This is a BIG change, and not a small one. People are going to notice. And they must.

Now we do have several tools that can help us copy data in bulk from source directories on-prem to destination directories in the cloud:

• SharePoint migration tool
• mover.io
• AvePoint
• ShareGate
• Metalogix
• BitTitan
• And probably even more

But to be clear, you won’t be targeting a “root” folder with tons of subfolders and files, especially if there are deep trees or broken inheritances hiding out in there. Generally you start as close to the data as possible, and migrate that data into a more “top-level” home in the cloud, to flatten everything out. Then, you remove (read: delete) the source folder from their view so that you don’t end up with forked copies of data.

Now take a look at Teams. Are you really going to create a channel for every subfolder that you have in that “Marketing” tree? Probably not–but that’s how Teams is structured: the default document library will have a folder corresponding to each channel. If you end up with some folders that don’t have corresponding channels, then they aren’t visible in Teams, so people will have different views of data depending on where they look. That’s just confusing.

If the new home for a departmental drive is in Teams and you have a certain channel structure that you want there, then you might be collapsing some of your data tree into that department or team so it “makes sense” for the new chat-based collaboration space.

For these reasons and more, the reality of migration is that you will need to reorganize, and that means involving your stakeholders and end users. They need to be trained in the new system and they have to understand a few things about the new platform so they can help you build out the structure that is best for them. Sometimes finding a new home for data is tricky, but there are a few rules and guidelines that you can use along the way. I will have more to say about these topics in an upcoming series on file server migrations. Stay tuned.

Update:

A reader left a good comment below that I want to draw your attention to. If you want to replace your file server with a “file server like” substitute then consider looking at Azure Files, and especially Azure File Sync. The latter allows you to keep a smaller footprint server on-prem or at a branch office and just “cache” the frequently accessed docs that are actually stored back in Azure SMB file shares.