Microsoft Office 365: Moving Office to the Cloud
Making the move to Office 365 conveys unique advantages for small to midsize businesses, but there are several transition issues you need to consider.
Brien M. Posey
There are a variety of benefits to moving to Microsoft Office 365, mostly related to cost and reliability. There are also several things you should take care to avoid or ensure you do properly, depending on your environment.
If you have a small or startup business and don’t yet have an on-premises network, there’s nothing wrong with going ahead and registering a domain and using it when you sign up for Office 365. However, if you already have an established network infrastructure, it can be a huge mistake to jump in with both feet and use an existing domain name when you first sign up for Office 365.
After maintaining an on-premises network consisting of a lab domain and a production domain since 1997, it was time to outsource my production environment to Microsoft Office 365. The decision wasn’t so much about cost as it was about reliability. Continuity of business demanded outsourcing my production environment. In moving to Microsoft Office 365, several transition best practices emerged.
The Microsoft Office 365 transition process is filled with gotchas. You don’t want to risk interrupting a critical business process by encountering one of these gotchas. That being the case, here are several recommendations for making the move:
- Register a brand-new domain name you can use solely for testing purposes.
- Build a test lab that’s configured similarly to your production environment (but on a smaller scale).
- Get the free trial of Microsoft Office 365.
- Use your lab environment and your throwaway domain name to get a feel for what the transition will feel like before you commit to using your production domain name.
Decide on the Transition Type
One of the first decisions you’ll have to make regarding the transition to Microsoft Office 365 is what type of transition you want to use. One option is to perform a coexistence-based migration. The other is to avoid coexistence altogether.
The coexistence-based migration works by connecting the Office 365 servers to your existing on-premises network. This treats the Office 365 servers as an extension of your existing network. This type of transition can be temporary, or you can continue to operate in a coexistence state indefinitely.
You can also choose to avoid the coexistence scenario. In this case, Office 365 is treated as a completely separate entity. You migrate your existing data to Office 365 without using coexistence. There are pros and cons to either approach.
If you decide to take the coexistence approach, it’s strongly recommended that you take advantage of the Wizard found in Exchange Server 2010 SP2. This Wizard greatly simplifies the migration process. Without the Wizard, your migration will consist of approximately 50 steps. The Wizard consolidates the process into six steps.
Although the migration process is Wizard-based and involves far fewer steps than it would if you were to perform it manually, don’t get the idea that establishing coexistence is easy. Establishing coexistence requires a great deal of planning and hard work. You should probably use your lab environment and a disposable domain name to work through the transition process. That way you won’t have to feel your way through the migration process in a production environment.
If you go with a non-coexistence migration, the process is considerably easier. However, avoiding coexistence is usually only suitable for very small organizations. In larger organizations, it’s impractical to try to manually recreate user accounts and then move data to the cloud.
Meet the New Mailbox
In transitioning my own small business organization to Microsoft Office 365, I opted for the non-coexistence method. The approach was similar to performing a dial tone restoration in Exchange Server 2010. The first step was to create brand-new mailboxes on the Microsoft Office 365 server and configure these mailboxes to use the same e-mail addresses as my on-premises servers. From there, the next step was to modify the MX record for my domain so mail would begin flowing to the Office 365 mailbox server, instead of the on-premises mailbox server.
At that point, the only thing left to do was redirect my Outlook clients to the new mailbox and move the old messages to the Office 365 mailbox server. Moving all the old messages meant copying all mail from my on-premises mailbox server to a series of PST files (a separate PST file for each mailbox).
Once I linked Outlook to the new mailboxes, I connected the PST files and moved the messages from the PST files to the cloud-based mailbox server. This process proved to be labor-intensive, so it probably wouldn’t be suitable for a large organization. For a small network, though, the process worked extremely well.
The MX record had to be updated before switching over to the Office 365 deployment. However, the MX record is only one of several DNS records I needed to update in order to use Microsoft Office 365. Although DNS updates are relatively simple to perform, there are a couple of important factors you need to consider.
The first involves determining who has the authority to make modifications to your DNS records. Most organizations will probably be able to make their own DNS modifications through an on-premises DNS server or a Web console provided by an ISP. In this case, however, I didn’t have direct access to my DNS records. I actually had to have my ISP make the modifications for me.
Regardless of whether you’ll be making your own DNS record modifications or leaving that to your ISP, just keep in mind you’ll need to make multiple modifications. You’ll have to create a special DNS record as a way of proving to Microsoft you do indeed own the domain. Once you’ve registered the domain with Office 365, there are a number of other DNS records you’ll need to either create or modify. Depending on the type of transition you’re performing, these modifications might happen all at once or separately. You might have to modify your DNS records individually as you begin transitioning specific services.
The only DNS problem I encountered during this process was that my ISP uses a command-line-based Lenox DNS server. As such, it had no idea how to create some of the resource records that are required by Microsoft Lync. Ultimately, these records proved unnecessary for the way I use Office 365. It could have been a major problem, however, if I were heavily dependent upon Lync.
Active Directory Synchronization
If you decide to perform a coexistence-based transition, you’ll need to take into account the Active Directory synchronization process. When you perform a coexistence deployment, you’ll continue to have on-premises domain controllers. There will be cloud-based DCs as well. Microsoft Office 365 is designed to perform the required Active Directory synchronization between on-premises and cloud-based DCs.
You might not realize until it’s too late that the Active Directory synchronization process is a one-way street. If you make modifications to the on-premises Active Directory, those changes will be synchronized to the cloud. On the other hand, if you make modifications to the cloud-based copy of your Active Directory, those changes won’t be synchronized to your local DCs. In fact, your changes will eventually be overwritten by the directory synchronization process.
One of the often-overlooked aspects of transitioning to Microsoft Office 365 is that, depending on the nature of the transition, any third-party products in which your organization has already invested could be rendered useless. In some cases, third-party software products may continue to work if your company maintains an on-premises deployment in addition to the cloud-based deployment. This is far from a guarantee, however. Continued functionality depends greatly on the individual product and the nature of your Office 365 deployment.
The problem with using third-party software is that Microsoft doesn’t let you install software products on cloud-based servers. As such, if you have utilities you’re currently running on local Exchange, SharePoint or Lync servers, you won’t be able to deploy those utilities to Microsoft cloud-based servers.
In some cases this limitation can be a big deal. Before transitioning to Office 365, my network used GFI Mail Essentials for spam control. I had put a considerable amount of time into building a white list to ensure client messages were never treated as spam. Just as important, the spam-filtering mechanism was fine-tuned to get rid of the vast majority of the thousands of spam messages coming in every single day.
After making the switch to Office 365, I had to stop using GFI Mail Essentials. Microsoft provides Forefront for Exchange as a means of controlling spam, but it still took the better part of a month to fine-tune Forefront to the point where I was able to filter out most of the inbound spam.
In my case, spam control was the only service affected by the inability to run third-party utilities on Microsoft Office 365 servers. Larger organizations might find themselves having to give up other services. These might include tools for common tasks such as monitoring software or messaging compliance.
The inability to use third-party server-level products with Microsoft Office 365 might not be an issue for some organizations. However, there are also some client-side limitations you need to consider.
For starters, older versions of Microsoft Outlook don’t work with Microsoft Office 365. Office 365 requires the minimum of Outlook 2007. This means organizations running Office 2003 or even older versions of Office will have to upgrade before moving to Office 365. It’s worth noting that some of the Office 365 subscription packages include Microsoft Office 2010 on-premises licensing. Of course, Outlook Web App is included with all Microsoft Office 365 subscriptions, which can be used as an alternative to Outlook.
Another important consideration for Outlook is that some third-party Outlook add-ons won’t work with Office 365. Many of the Outlook add-ons (such as antivirus software, message archiving software and so on) are based on Messaging Application Programming Interface (MAPI), and Office 365 doesn’t support using the MAPI stack. As such, MAPI-based utilities won’t work with Office 365.
Clearly, there are some substantial factors to consider prior to migrating to Office 365. Even so, the switch to Office 365 is worthwhile. The service is invariably more reliable than on-premises networks, and less time spent on patch management and other maintenance tasks equates to an increased value.