Moving to Microsoft 365 means getting to know your data (and your business)

Through my website’s contact form, I still hear about botched migrations to Microsoft 365 on a regular basis. This is usually due to exactly one problem: ignorance about the process, as well as ignorance about the datasets being migrated, as well as ignorance about the various tools that we have in Microsoft 365. All of this ignorance translates to pain that was 100% completely avoidable. The pain is what I most often hear about when people come to me asking if they can hire my help to clean up a mess that they themselves created.

What’s worse, I fear, is what I don’t always hear about. There are plenty of folks out there who already think they are the smartest people in the room (but do they realize how large of a room the world is?); so when they attempt to implement one of these solutions for themselves or their customers and they have a bad experience, they ultimately conclude that it was the software, and not them, that was the problem. This preserves their image in the eyes of the customer, and of course reinforces their own “self illusions.” I see evidence of this phenomenon in several circles/groups online. They will sometimes even get validation from others who are likewise ignorant and had a similar experience. It is difficult to help these folks (they obviously don’t need it).

But I can still help some of the other people. You know: the ones who remember that there is always someone out there who knows more about something than they do.* Anyway, for those individuals, I am going to host a two-part live instruction class on properly preparing for and migrating data to Microsoft 365. This includes some key governance decisions as well as notes on end-user adoption strategies.

But look, I have written volumes about this topic on this website already, so you might be able to just glean what you need that way. I recommend starting here. No pressure to join this class or anything. And to members of my Practice Development group: you already have access (this is a topic that was picked by the group).

Today I just want to emphasize one important piece of the puzzle, and explain why I think a lot of migrations go poorly.

The magic no longer happens ‘behind the curtain’

For more than two decades now, migrations have been done “behind the curtain” so to speak. What do I mean by that? Well, up until now, the person moving the data did not need to know anything about the data they were moving. It was not required to have any knowledge about the data inside the file shares, for instance, or the various shared mailboxes and public folders inside of an Exchange database. Users would just be told to stay off the network, and expect a short interruption while data was copied or moved over the weekend. And when they come in on Monday, the job would be done; the magic all happened behind the IT curtain.

The IT folks just had to understand the infrastructure that supported the existence of these things. They knew how to move a mailbox or a file share using tools like EAC, PowerShell, Robocopy, or whatever. And that was all fine and good.

But if you are moving from old-world infrastructure into a brand-new modern cloud-based information system, knowledge about the data is much more important than knowledge about tools. That having been said, you also need to understand the limitations of the new architecture and the tools that support it. For example, do not attempt to put all of your files into a single library (a common mistake). We have different repositories for different types of data now, and we are moving toward a flatter, wider structure in general, rather than a hierarchy that is nested and deep.

So the fact that we are moving into an alien-seeming structure means that we have to spend more time learning what it is that end users are doing day-in and day-out. By doing so, you will be able to guide the movement of this data into the most appropriate place in the cloud. What used to take place inside a Public Folder database might live in an Outlook Group (or even in Teams) for example. What used to show up as a drive letter might make more sense now as a library in a Communications site, or as files within a Teams channel. It depends.

Understanding the data structure and the purpose of various datasets is therefore more important than which tool you ultimately choose for copying data (and there are a lot of good ones out there now).

The future is bright

But this implies you can no longer spend your days hiding out in the server closet. You have to go mix and mingle with the general user population, and get to know what it is they do, and the challenges they face as they attempt to adopt all these strange new tools like Microsoft Teams, OneDrive for Business, or SharePoint Online. The key point is that both groups have something to learn from each other in this exchange: the users need to learn about the new technology, and IT needs to learn more about the data (specifically the business context in which that data is showing up).

Having a better understanding of ‘what is out there’ will also come in handy as you apply governance and help the organization to make decisions on how they want to customize their environment and meet compliance requirements. So unlike migrations from file server A to file server B, or whatever Exchange version to vNext, this should be a much more engaged migration that involves more players and helps the IT department or Service Provider get to know their customers better. It is a win-win situation, and done right the exercises will help build more trust and mutual understanding, and open more opportunities to add value in the future.

*I am also not suggesting that I’m Mr. Know-It-All here. Perhaps in some limited areas, yes. But there are plenty of topics that I know very little about, and therefore, even I must look to the experts. For example, almost everything in the real world that doesn’t involve sitting in front of a computer.