The “Five Rules of Fields” for File Server Migrations to Microsoft 365

What a fun tongue twister, and such a practical resource that I am excited to share with you today! Well, actually a lot of this information you might have already gleaned by following my past posts about file server migration. But I still find that when I consult with folks they are largely unaware of the basics when it comes to collaboration in the cloud, and especially when we discuss moving files from a legacy on-premises file system.

And that is too bad, because when you walk in blind to this type of project, you are in grave danger of falling into what I call the “Pit of Terrible End User Experience.” Email is simple to move. Files, not so much. When you do this incorrectly, you run a high risk for putting a bad taste in your customers’ mouths. Not a good way to go.

So without further ado, I present the Five Rules of Fields for File Server Migrations.

Rule #1: Before you start, delete!

The best definition for clutter is that which takes up space but delivers no value. Every organization has files that meet this criterion. They have been moved from one file server to the next over many lifecycles, and in some cases, people cannot even remember what they are for. If it has not been modified or referred to in the last three years, why do you think it will be needed in years four, five, six and beyond?

Unless you are obligated to keep specific pieces of data for specific periods of time due to compliance reasons or otherwise, then get rid of it. Mark your “compliance-related” data or set that aside into a separate directory structure. We have many options for protecting and managing your most sensitive and important data once it is in the cloud. But do not let that stop you from clearing out the garbage.

Getting rid of the clutter makes it easier to see what is actually valuable, and it will make migration easier, later. If you do not go through this step now, then you are not taking your migration and digital transformation efforts seriously. Do not bring dead weight into the cloud, period.

Rule #2: Put everything in its right place

The following image explains this rule for the most part:

It is not uncommon to see strange artifacts on old servers where a folder containing semi-sensitive or private information is located in a public (i.e. org-wide) file share. Do not move the mistakes of yesterday into the collaboration spaces of tomorrow. Data that you should be working on individually and only sharing with a few select people goes into OneDrive for Business, or possibly Teams. If the data is private but more collaborative, consider landing it into Teams where you can co-author and have conversation threads related to your work. If you require more public access or you need to broadcast the data out to a wider audience, then you should consider using SharePoint.

Now, we have one more storage space to discuss that is of particular importance to this rule: Archives. This is data that is very infrequently accessed and the permissions stay 100% static forever. Oftentimes, archives do not even move to SharePoint at all; some will put this data elsewhere. But if you do decide to move this data to SharePoint, or alternatively, a managed OneDrive for Business account (find out how much storage you get in OneDrive), just remember that you do not ever sync this data to file explorer.

Yes: you can use the OneDrive for Business sync feature for active libraries, like a channel where you frequently collaborate on files with others. But the point bears repeating: you should NOT EVER sync your archive libraries, which often have hundreds, even thousands of files in them. Reason being: there is a known issue where syncing more than 300,000 objects (counting files and folders) will cause sluggish and inconsistent OneDrive experiences, even crashing the client.* So don’t do it.

Therefore, just think of the file explorer option as a bridge for old timers. Ideally you shift to working out of web and native app experiences, but it is there in case you need a crutch, so to speak, and only for active files. Again: NEVER use it on your archives (which tend to house hundreds to thousands of files in a single library). Access your archives on the web.

Rule #3: Rule Three is the Rule of Three

This should be the easiest rule to remember, and one, if followed, will save you many a future headache. Basically this rule just says: do not nest folders more than three layers deep.

There are technical limitations at work here (eventually you will run into URL length issues with too many subfolders eating up valuable character limits). But there is another, more practical reason that you should not get too crazy with layers upon layers of folders: more layers = more time clicking around to find stuff.

If you think about it, a deep folder hierarchy is really nothing more than someone else’s mental association map; there is a neurological navigation that takes place when you double-click down a dozen times to reach the data that you are looking for. You might get faster at this over time, but remember that every other person you work with or hire in the future has to learn this map from the beginning. Eventually they too will get good at being slow, but if you are being honest that is not what you want. Instead, learn how to navigate a flat structure and leverage search: that is the more modern way of working with information.

If you are following the first two rules, then you will likely already have a flatter structure in Microsoft 365 anyway! So for example you might have a Team (level 1) and a channel (level 2). Within that channel you can often just deposit your files, and sometimes (maybe) add one more subfolder layer to organize data a little further (level 3). But that is where you should stop (three means three, not four or five). Do not try to make it more complicated than that, you’re just hurting yourself and doing a disservice others.

Rule #4: One Site, One Audience, One Purpose

This rule is also known as my Permissions Mantra. You repeat this phrase to yourself whenever you are confused about permissions in Microsoft 365. The idea is to have a very flat information architecture with a wide collection of sites (including Teams). If you have sub-folders or directories on your file server with strange things like broken inheritance and custom permissions sets, just remember that every “break” into unique permissions = new audience, which generally means you are going to need a new site in SharePoint (or a new Team in Teams). See this article for more details.

So you might end up with a lot more “top-level” containers such as Teams, Team sites, or Communication sites. Think about the purpose of the information. Is it related to the inner workings of a specific department? A cross-departmental production pipeline? Or a temporary project? Whenever you are addressing either a new purpose or a new audience, you are creating a brand new site (or team). And do not worry: Microsoft gives you 2 million site collections per tenant, and up to 500K teams, so it is highly unlikely that you will run out.

The benefits to having this flat collaboration structure are many. And prime among them is not having to manage broken inheritance issues.

Rule #5: Mind your governance

Organizations would do well to articulate their needs for collaboration and record the reasons for making certain decisions in advance of the migration to Microsoft 365. If you have already started leveraging Microsoft 365 it is not too late; you can (and should) still go through this exercise and make adjustments in the environment as needed. At a minimum, you should be discussing these topics:

• Creating and managing collaboration spaces (Microsoft 365 Groups)
• When do inactive Groups expire (e.g. 6 months, 1 year)?
• Is there a retention policy in place for content such as email and chat messages, or files in OneDrive, Teams, and SharePoint?
• Data classification and labeling for both sensitivity and more specific record retention requirements?
• External sharing/collaboration requirements and limitations?
• Data Loss Prevention measures in the cloud and on the endpoint?
• Endpoint security and access from unmanaged devices?

When you have these conversations, it is extremely valuable to capture the decisions that are made for posterity in a document. That way, if the organization needs to make changes to their governance options in the future, they can have context for why something was set up in a particular way. Soon I will be updating my best practices guide with a governance decisioning template document, to help get you started.

Conclusion

So that is basically it, if you can follow those five rules then you should have a successful migration, and avoid the most common disasters that land you in the pit of terrible end user experience.

The rules are different than the actual steps and project plan for carrying out the migration. I might have a separate post about that: like a practical guide for executing a file server migration (with the goal of eventually powering down the old server). But the rules are indispensable, and will dictate how you approach your migration.

For example, you probably noticed that this ruleset implies that you can’t just mirror all the files & folders you have on-prem today directly into the cloud. That’s right: it is an all new information architecture, and you should not expect that you can just slide users over from their old mapped drives to this new experience, and have it be seamless like nothing happened. It is not possible to do this, and you should not try.

Yes, moving to a more modern ecosystem can be a shock, but you also have the opportunity to level-set and clean house. Plus, you can do so much better than that old clunky file server. But, if you are not ready to make these changes, then why are you looking at migrating to Microsoft 365 at all? Do you want a modern work experience, or not?

*Footnote: The OneDrive sync limitation is actually due to a .DAT file stored somewhere in your app data area. When it grows past 2 GB the OneDrive app loses its mind. This happens when the sync client has to keep track of about 300K objects. You might eck out a tad more with the files on-demand feature, but do not push your luck. If you stop and think about just how many objects 300K is, you will soon realize there is no reason you should ever need to maintain access to that many files & folders simultaneously, anyway. Unless you are a robot or advanced alien species, is not possible to consume and contribute to that many objects over any reasonable period of time.