Skip to content

Microsoft 365 Migration – The Beginning

There are lots of reasons to move to Microsoft 365. You can apply most of the same logic to Google’s Workspace (formerly G Suite) or Zoho Office, but we’ll focus on Microsoft’s Office 365 portion of the larger M365 product. There are many extras in the margins between Office 365 and Microsoft 365, and we’ll touch on those in a bit. Let’s back up a bit and ask, “Why do this at all?”

A large part of why to migrate has to do with the cost and effective use of human and equipment resources. A cost is associated with even a free email server running on your hardware. Even if you discount the price of the software, which is rarely free, you have the cost of the hardware, bandwidth, and the time of someone to maintain it. These small costs add up quickly! Conversely, a cloud option like M365 moves that cost to a monthly fee per user. In exchange for that fee, you get email, storage, chat, websites, security, integration with your on-prem Active Directory, and more. Check any of the above products’ websites. They are happy to tell you why they are great.

The main thing to consider is ‘core vs. context.’ If you are not running an email organization, why do your customers care about what email platform you use? So long as it works and does the main things we expect a mail platform to do around messaging and scheduling, no one cares about the details. It’s context, not a core competency or differentiator. In the last 30 years, no customer said to a business, “I want to buy what you are selling because you have a great email server.” That is unless they were talking to someone selling email servers! If it’s not improving your business, hire an outside service.

To summarize:  If your company is not in the business of providing email, SharePoint, and /or cloud storage, outsource it to Microsoft or Google (pick one). These things are not core competencies. They are context and, therefore, distractions from the core things your company does to make money.

Depending on the size and complexity of your organization, this could either be a weekend project or a multi-phase beast spanning months. A big decision to make is who does the migration. How do they do it? These are intrinsically linked because if you hire a partner to do it, they have their own processes that dictate the how. If you do it in-house, then you need to determine the how.

Let’s talk today about the decision on hiring it out or doing it in-house. Here are a few leading questions to ask yourself to make that decision.

  • How big is the environment?
    Even a single admin who can follow complex instructions can accomplish the Exchange migration if the environment is small. SharePoint is more difficult without tools but see the points below.
  • Do you have people who are competent in Exchange and PowerShell?
    While most of the work can be done in the GUI environment, a fair amount of PowerShell code is involved. Most of it is copied from Microsoft’s website and modified for your environment, but if you or your admin aren’t familiar with PowerShell basics, you could have problems.
  • Is your current on-prem environment very customized or plain vanilla?
    Perhaps you don’t even have SharePoint on-premises, or you only have a few hundred Exchange mailboxes. Conversely, you have a ton of old, poorly organized mailboxes left over from a previous management decision to keep everything forever, including thousands of shared mailboxes and distribution lists with no owners. <Sorry, I got triggered a bit there>
  • Are you willing to invest in some tools?
    Tools like Sharegate and some others will GREATLY ease your migration pain. Sure, you could code up some PowerShell scripts to do much of the same but remember what we said above about core competencies?
  • How FAST do you want to do it?
    It may take a while if you have a small team or a very complex environment. Hiring someone to do it will still take time, but hopefully, you paid by the project, not the manhour. If you have a very small team running at full capacity to keep things running, they may not be able to get this done in a timely manner.

Another point to consider on the speed thing is this; Is the completion of this project going to mean a reduction in staff? If you have one person whose only job is running Exchange and SharePoint servers, they will be understandably nervous. I’m not trying to say anyone would deliberately slow down a project to stretch out their job, but subconsciously this person is likely not working as hard as they could if they fear losing their job.

The flip side is if you have an overworked server admin that maintains Exchange and SharePoint and would love to simplify the environment to concentrate on value-added things like cloud automation and such fun stuff. This admin will work nights and weekends to get these beasts out of the environment. This is the admin that understands that running Exchange in-house is a thankless job. If it works, no one notices, but one thing glitches, and they are out for your head.

The final piece of the do-it-yourself vs. hiring someone debate is cost. Obviously, part of the equation is what this migration will cost in dollars and cents. The benefit of doing it with existing staff is that you are already paying them! The downside is if there is a problem with the existing team, either in competence or capacity. If that balance tips too hard against doing it in-house, either hire out the whole project or, if it’s a capacity problem, hire a contractor to come in and take the lead on the project for you.

Take all of this into account and decide the WHO. That decision dictates the HOW. The HOW could be a book all by itself, but next time I’ll run through a summary of things that need to get done to call this a successful undertaking.

 

1 thought on “Microsoft 365 Migration – The Beginning”

Leave a Reply

%d bloggers like this:
Verified by MonsterInsights