For many organizations, Exchange Online commonly serves as the stepping stone to Office 365 and often as their first step to using cloud services in general. Sometimes overshadowed by the financial benefits of migrating to Exchange Online is the necessary prep work to get there.
While the migration effort is something you may have engaged a partner for, there is still a fair amount of preparation that your organization will be responsible for. In additional to the technical tasks, there will be operational tasks to address and organizational processes to update.
A project to migrate to Exchange Online can quickly come to a halt if an organization is not ready to take on these preparation tasks.
Below are 10 areas of preparation and recommendations on how you can begin your move to the cloud.
1. Solicit Expertise
Working for a Microsoft partner, my opinion may be a bit biased here but I believe it’s important to engage with a partner that has significant experience with migrations to Office 365. Office 365 is very dynamic so you’ll want someone that actively does migrations, not someone that last did a migration 6 months ago. I often tell clients that migrating to Exchange Online will be their last mail migration so investing here will not only make your migration run more smoothly with less surprises, it will allow your staff to focus on other tasks instead of ramping up for an event that won’t be repeated.
2. Educate
Make sure everyone is up to speed on what Office 365 is about early on in the engagement, this includes the C-levels involved in the project down to those that will eventually support it. I like to think of this as “know what you bought”. This means making sure that we understand that as a shared service, there are some limitations. Understanding those limitations upfront is key to avoiding roadblocks down the road where you find out some critical application is not compatible. Also critical is understanding the update process, how that fits into what you do today and where you’ll need to adapt.
In addition to understanding the service limitations, your technical staff will want to start digging into the service and understand how they will support your environment post-migration. This is not a “send someone to a week long class” scenario; the issue with classroom training is that with Office 365 being as dynamic as it is, course material quickly becomes outdated. Fortunately, some of the best training material out there for Office 365 is free or relatively low cost; that’s not to say that it isn’t time consuming though so you’ll need to budget for time. Some great resources are the Microsoft Virtual Academy, the Microsoft Mechanics video series and the recorded sessions from last year’s Microsoft Ignite conference. There’s also an eBook available, “Office 365 for Exchange Professionals“, which is a great format given how quickly information changes; the authors have also committed to updating the content on a regular basis.
3. Initiate Early Engagement
Nothing creates more friction in an Office 365 project than when you’re sitting with the client in the kickoff meeting and this is the first time anyone brought in a resource from the Information Security team. Engage all the relevant parties early on in the process, this includes networking, security, desktop support and help desk. Getting all their questions out up front will mitigate delays later when some team objects to a design component or core item within Office 365. Ask as many of these questions as possible before the check has been written for licensing and SOW signed for implementation.
4. Adapt Your Processes
Office 365 or cloud services in general will change some of your current process. Provisioning of new users will require integration of some Office 365 specific tasks such as licensing and the current way you handle terminated employees will likely need to be updated; see “Office 365 – How to Handle Departed Users” for more details on this topic. Other processes around areas such as data backup and recovery will also likely need to be updated.
5. Security
Depending on what you do today, your security team may have a significant number of questions. It’s not that Office 365 isn’t secure but it’s often a shift in mentality and understanding that you are now operating within a shared service in the cloud. So if you don’t allow any external access to email today or only from a strict set of devices, that somewhat conflicts with the “access from anywhere” concept in Office 365. With this type of restriction and others, there is almost always a way to deal with it and this is where you’re going to need to lean on your implementation partner.
6. Networking
Is your network ready for Office 365? This can be a deep topic but if you backhaul all your Internet traffic through a central hub, that’s not really ideal for cloud services. Users will now be accessing their mailboxes in the cloud as opposed to from a local mail server. Providing a local Internet egress will keep that traffic off the WAN links.
Ideally you’ll want to avoid sending the Office 365 traffic through a proxy and don’t even think of using IP addresses in firewall ACLs. There are two really good sessions from last year’s Ignite conference that cover this topic, I highly recommend them: “Planning for Internet Performance and Capacity” and “Best Practices for Client Access to Office 365“.
One more area to check (but definitely not the last) is how your DNS is resolving external addresses across your organization. Microsoft uses geo-DNS to direct your users to the closest Microsoft point-of-presence (POP). Basically when Outlook tries to access “outlook.office365.com”, the user should connect to the local Microsoft POP and then take Microsoft’s network back to their mailbox. I’ve seen in some organizations where the DNS design causes users in one continent to end up resolving to the Microsoft POP in another continent which will be a higher-latency connection. This article describes the issue well: “DNS geolocation for Office 365, connecting you to your nearest Datacenter for the fastest connectivity“.
7. Active Directory
Be prepared to do some cleanup in your Active Directory environment. Microsoft has a tool (IDFix) that will get you started with identifying some of the items needing addressed.
An area that can become a lengthy discussion in an Office 365 engagement is the topic of the UserPrincipalName (UPN). For a number of reasons, you ideally want the user’s UPN to match their primary SMTP address. This means any applications using the current UPN may possibly need remediation. Check out this article for a deeper dive into this topic: “Office 365 – Why Your UPN Should Match Your Primary SMTP Address“.
8. Messaging
Preparing the messaging environment will largely depend on what you have today and what type of migration you plan to do. One cleanup item sometimes overlooked is the fact that you can only use SMTP domains in Office 365 that you are authoritative for. If you have a mailbox that has proxy addresses for domains that you do not own, those addresses will have to be removed before you can migrate the mailbox. This includes any “.local” or “.fax” domains that you may be using and don’t own the DNS name for.
9. Workstations
Something that seems to surprise many organizations is the supported client requirements for Office 365. In many instances, I find clients running old browsers due to application issues and outdated versions of Office like Office 2007. If you check the Office 365 System Requirements, you’ll see that Office and your browser must be in “mainstream support” to be supported. That doesn’t mean older versions don’t work (with some limitations) but the supported versions are IE 11 and Outlook 2013. Yes, Outlook 2010 went off mainstream in October 2015. Fortunately Office ProPlus is often part of your Office 365 licensing but make sure you become familiar with the update process and how that works in the subscription installation.
10. Business Applications
If you have third-party applications that integrate into your messaging system today, you’ll need to investigate each of these for their compatibility with Office 365. If the application uses the Exchange Web Services (EWS) API, there’s a good chance it will be compatible with some reconfiguration. If the application installs something local to your Exchange server, it likely will not be compatible and you’ll need to check with the vendor for their support. Applications that simply do SMTP should be fine although there are multiple ways you can address these applications when you move to Office 365.
Summary
This is just the start but if you begin looking into these areas, you’ll be fairly prepared. A good Microsoft partner will guide you through this process and dig further into the details based on the experience and knowledge of your specific environment.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.
