Out Of Office: Planning the Migration to Office 365

Back in the first post of this series we covered off the planning portion with regards to implementing Office 365. Knowing what you are aiming to achieve is critical to measuring the value and success of a project. Assuming the math checks out, now it is time to pull the trigger and start the Office 365 migration. A botched migration can easily compromise the value of a project, so planning should be done with care. UNDERSTAND HYBRID VS. CLOUD Office 365 offers multiple options for deployment. You can run fully in the cloud, which means you'll be able to remove large parts of your infrastructure. This can be especially appealing if you are nearing the end of life for some equipment. Saving on a large capital expenditure and moving it to an operating expense can be ideal at times.

Another option might be a hybrid approach. This approach is a mix of using your on-premises infrastructure and Office 365's infrastructure. This is commonly used as a way to get your mailboxes and data up to the cloud. It allows for administrators to choose which mailboxes run where. It can also be used for security or compliance measures: maybe you want all C-level executives to keep their mailboxes on-premises.

ROLLING OUT NEW SERVICES Have you opted to roll out any other Office 365 / Azure services into the mix? Maybe you are interested in using Azure Multifactor Authentication (MFA), or maybe Azure Active Directory to allow for single sign-on (SSO). How does that fit into the process? You'll need to see how any new service fits into your current environment. Using MFA as an example, will this be displacing an existing service, or is it a new offering for the environment? Either way, there will be additional work to be done. ALWAYS HAVE A PLAN B As with any IT project, what will you do if you have a failure along the way? This isn't to say that the Office 365 migration as a whole isn't working out, but think about the smaller things. What if you move your CEO's mailbox and then something goes awry? How do you move it back? Identifying what needs to be migrated, upgraded, or installed based on the above gives you a list. You can use that list to start forming failback planning for each of those components. A good tip for planning failback is don't just focus on the tech. Make sure you know what people need to be involved. Do you need specific folks from your team or from other teams? Make sure that is part of the plan so if you do need rollback, those folks can be available, just in case. COORDINATING THE MIGRATION When it comes time to start moving data, make sure you don't blindside your users. You'll want to identify key individuals within your organization to liaise with (e.g. department managers). The goal here is to ensure that you minimize disruptions. The last thing you want to do is have an outage period overlap with the closing of a large sales deal. Kicking off a platform migration can be a stressful event, but proper planning and communication can go a long way.