We’ve all heard the old saying, “Failing to prepare is preparing to fail, ” etc.
Yep, it’s true. There should be an addition that mentions planning well and thoroughly. The biggest obstacle to a good plan (besides laziness) is a lack of information about the existing environment. If you don’t know what you have, it’s hard to migrate it effectively. This includes dependencies and technical debt, which we’ll discuss today.
I’m going to start off and say that I do not know what the “PERFECT” plan looks like because I haven’t seen one, much less made one. That said, my plans improve every time I find a new pain point or constraint and learn how to mitigate or avoid that particular problem. Each particular migration is different based on the environment and the company culture. The culture part is important to understand as getting buy-in from company stakeholders, and end-users is important to a successful migration.
Common Pitfalls
So how do you make a good plan? Step one is avoiding a few common mistakes.
- Planning out of order – This is critical and not as often discussed as I think it should be. Don’t move SharePoint before Exchange, and don’t implement OneDrive at the same time as Intune. Of course, your migration order will depend greatly on the size of your existing infrastructure. If all you have is Exchange, then yeah, it’s going to be a relatively easy move. Add in moving from another Mobile Device Management tool to Intune, mapped network roaming profiles to OneDrive, and mapped network drives to SharePoint. Suddenly you have a mess of dependencies.
- Simultaneous execution – Even if you have a fair-sized team, other things will come up. Don’t make it worse by trying to do too much at one time. Something will end up falling behind, then you rush to catch up, and that’s when mistakes happen.
- Lack of communication – Let’s also recognize that there is such a thing as too much communication as well. You have to find the right balance for each company’s culture. In some companies, campaigns hyping how great things will be with Office 365 resonate. In others, the attitude is a bit more lackadaisical, essentially “just tell us what we need to expect”. A good rule of thumb is to give multiple notices in a top-down fashion.
- Give the executive team a month’s notice before any potentially disruptive change,
- Give two weeks’ notice to the managers.
- One week’s notice for the rank and file employees.
- Of course, you should send a general notice to everyone right before making the change.
That’s what not to do; now, let’s dig into what a good plan should look like.
Planning to succeed
The first thing is to learn about your environment. How many mailboxes are there, and how big are they? If they are close to 100 GB, then steps must be taken to reduce the size. How many users? How much data needs to be moved to OneDrive? What is the policy on Mobile Device Management? How will that change going forward? Are endpoints ( laptops/desktops) being managed now? Is there a methodology to push software to them? Once you have the answers to these questions, a plan should start coalescing.
A good plan’s next major part is allowing adequate testing time. Get test systems and run through your proposed steps. See what else it breaks. Make test users, so no one gets hurt. Unless you personally built out the company’s infrastructure, you don’t know how everything interacts. I would argue that even if you did design the infrastructure, users have started using things in unintended ways and never told IT. Test EVERYTHING.
The last major part of a good plan is doing a phased rollout whenever possible. As much as you tested, you almost certainly missed a small niche of users with an undocumented, oddball circumstance that you will need to adjust for or take time to help them adjust. I always liked the ring approach where the team working on the implementation goes first, followed by the support team so they know how to answer questions, then the rest of IT, followed by either the rest of the company if small enough, or a branch office or region at a time.
Mapping it all out
Phase 1 – Information gathering. Use any tools that you have available to get as much data as you can. This helps with the planning phase and shows progress to the executive team.
Phase 2 – Get all of your endpoints enrolled in Intune. I’ll go over a more detailed process for this later. Trust me; you want a reliable way to push software and policies to endpoints. SCCM is fine for servers, but Intune was designed for today’s mobile workforce.
Phase 3 – Implement Teams. More ways to communicate are always better. Plus, it’s a relatively easy install as there isn’t a lot of migration involved.
Phase 4 – Bite the bullet and do Exchange. This one is big. Prepare for strange dependencies here. That one deserves its own article.
Phase 5 – OneDrive. Technically this one was active as soon as you gave the users licenses. This part is turning on Known Folder Move and migrating local folder redirects to the cloud. Microsoft has provided tooling, but be careful to migrate what you need, but not too much.
Phase 6 – SharePoint. Not just the migration of your on-prem SharePoint. Any mapped network drives now become SharePoint sites.
Phase 6 – Clean up the mess. If you had a moderately large environment, this process freed up a fair number of servers and storage. This is a good segue way into your next major project – optimizing your data center!
