Your collaboration structure should be wide not deep

In previous articles I’ve provided:

A framework for file migrations to Microsoft 365

and

Processes for file migrations to Microsoft 365

In this article, I’m going to focus on the next level down and how you should be thinking wide not deep when it comes to transforming your data into Microsoft 365.

In essence, structure is not as important as it once used to be. Having layers and layers of directories and sub-directories in a file share was really the only way to catalogue and organise your information in the world of on premises. However, structure becomes far less important in a world where everything is available via search. Think about it, how do you find stuff on the Internet? You search for it. Why then should internal data work any differently?

Search is built into Microsoft 365 and now appears at the top of most pages as you see above.

For example, if I do a search for “bitcoin” then I’m returned results from that location, in this case a list.

Not only do I have search, but thanks to the Microsoft Graph and some “AI” magic I can get a feed of my most relevant documents in Delve. I can also see documents others are working on that are also relevant to me and that I have permission to, again all in Delve.

So, the concept of structure is less important than it used to be, especially the deeper you go. It more becomes a case of get it into some major buckets and we can filter and sort from there.

Let’s say that there is an existing on premises folder structure like so:

F:\Finance\customers\abc\2017

F:\Finance\customers\abc\2018

F:\Finance\customers\abc\2019

and so on. How do you ‘transform’ this into the new world of Microsoft 365? Best practices is to start at the top and work down. Thus:

F:\Finance

is going to be the initial bucket. This means that you should either create a Microsoft Team or a SharePoint Site called “Finance”.

Once you have a Microsoft Team called “Finance” then you would probably create a Channel called “Customers”. If it was a SharePoint site then you’d have a Document Library called “Customers”.

Inside the Microsoft Team called “Finance” and the Channel called “Customers” you have a folder in the Files area called “ABC” and so on for each customer.

At this point we have now reached “Robert’s rule of three” maximum structure depth. That means we have a Microsoft Team, a Channel and a folder. We don’t really want to create anything deeper if we can avoid it. This is where “metadata” comes to the rescue. Perhaps, instead of a a single Channel or Document Library for customers, maybe you have a unique library for each? The choice is yours.

If we look at the structure of the source data, we see that is broken out be year. However, we can create a custom column in SharePoint that contains the values of “Year” and use that to ‘tag’ our data. Thus, you create an additional column in the Document Library where the data lives. You specify that the only values allowed in the column are numerical years. You then set that field to the appropriate value for each file.

In the above example, you’ll see that I have created an additional column called “Customer” and used that to tag both files and folders.

Thus, metadata allows me to collapse my structure by using tags, which in many ways is what people used folders for on premises. Once I have tagged my data I can easily sort and filter it like so:

Here it is “grouped by Customer”

Thus, with metadata you can create a much flatter structure because you don’t need all those sub folders. The benefits of a flatter structure is that it is easy to see more of the data quickly and then using the inbuilt filtering tools to get to what you want. Typically, you’ll only be using this filtering technique if you haven’t searched for the data or had it presented to you via Delve. However, for those that still like to navigate a formal structure, it is still possible as you can see.

My best practice is that every time you are considering going more than three levels deep, you should break the data into another Channel or Document Library. Remember, you can create as many Document Libraries as you want in SharePoint and then also link them back into Microsoft Teams if you want. You should be looking to use lots of Document Libraries and keeping them no deeper than a single folder as a rule of thumb.

The other benefits of using additional Document Libraries is that you can have a different set of metadata to describe your information. You can also have a different set of permissions as well as a different look and feel thanks to SharePoint Views. A wide structure in general makes more things visible to people when they go looking, rather than it being buried deep within a folder structure and lost.

Thus, most of your top level folders from on premises file servers will become independent Teams or SharePoint sites. Subfolders below these will become Teams Channels or unique Document Libraries in SharePoint. It is also always better to break deep structures into different Document Libraries and link them back into Microsoft Teams if required.

Remember, moving to Microsoft 365 is about “transforming” data and restructuring it in a ways that users will benefit most. This means keeping it as shallow as possible and using inbuilt tools like filter, sort and search to get to your information rather than constantly navigating up and down deep structures. Services like Delve will also present to you the information you need most times and so you won’t even have to go searching for it. Simply ‘dumping’ data from an on premises file share into a single Document Library is not providing any value or transforming that in any way. If you aren’t going to do that why are you even bothering to move it?

As I have said previously, transformation requires effort, it doesn’t magically happen. However, the point of migration is the opportunity to transform data so that it can take advantage of all the tool Microsoft 365 provides. Also don’t forget that you don’t have to do all of this transformation in one hit. Create the Microsoft Teams, Channels as a starting point at least, then add metadata across the data down the track. Likewise, if you want to make a change down the track you can. That’s the whole idea with Microsoft 365, it is something that will evolve over time as the business does. It is never a once off migration process without future change. Never!

Microsoft 365 gives you the resources and tools to go wide not deep with your structure. Start my replacing some of your sub folders with metadata fields as illustrated above. Doing so will enable your business to be far more productive than it ever was with deep on premises file shares. Remember, moving to Microsoft 365 is about transforming not merely migrating.