You know and love our Must-Read IT Blogs lists, but now, say hello to the nonprofit side.
Although Software as a Service (SaaS) applications such as Microsoft Office 365 hold wide appeal, migrating is not simply a matter of moving to the cloud — it takes time and effort.
As with all projects, the more planning and preparation IT managers can do, the more likely they are to succeed. What follows is some advice for organizations that are about to embark on an Office 365 implementation.
One of the first steps in an Office 365 migration is a domain verification. Office 365 can be configured to use an existing domain name, but the organization has to prove to Microsoft that it owns the domain name.
The domain verification process involves adding a record to the DNS server. This record is typically a TXT record and contains text provided by Microsoft. Once the DNS record has been added, Microsoft verifies its existence and uses the record as evidence of domain ownership.
Next, verify that the organization is running supported versions of Exchange and SharePoint on premises. Those who are running Exchange Server 2003 will need to update to a newer version before migrating to Office 365 unless they have a third-party tool that supports legacy migrations.
Exchange Server migrations can be involved, primarily due to the relationship between Exchange Server mailboxes and Active Directory user mailboxes. The first decision to make involves choosing a migration method.
There are two main approaches to Exchange Server migrations. One option is to perform a cutover migration. Cutovers are the easiest type of Exchange Server migration, but are only suitable for organizations with fewer than 1,000 mailboxes. Furthermore, cutover migrations require all of the mailboxes to be migrated as a part of a single migration batch.
Although cutover migrations are intended to be simple, a number of different tasks must be completed first in order to prepare for the move. For instance, IT managers must configure Outlook Anywhere for an on-premises Exchange Server environment. This will make it easier to redirect Outlook clients once the mailboxes have been migrated. Incidentally, organizations will need to make sure they’re running a supported version of Outlook. Microsoft provides instructions for making a cutover migration at TechNet.
The other migration method is a staged migration, which involves setting up a hybrid Exchange Server deployment. This method is more difficult, but supports long-term coexistence and the ability to move mailboxes back and forth between Exchange and Exchange online. Choose this method for migrations involving more than 1,000 mailboxes.
According to some estimates, there are 200 steps involved in planning for and working through a staged migration. Microsoft offers a free online tool that can assist with the Office 365 migration process as it pertains to Exchange Server. The Exchange Server Deployment Assistant asks several questions about deployment goals and then provides instructions for working through the migration process.
Although SharePoint migrations aren’t usually as tedious as Exchange Server migrations, they tend to involve quite a bit of work. Analyze the existing SharePoint environment to see what resources need to be migrated. Most organizations find that they need to migrate SharePoint content and various customizations.
Unfortunately, Office 365 doesn’t automate SharePoint content migration. It’s possible to use SharePoint Workspace as a manual migration tool, but most prefer to use a third-party migration tool. Such tools not only help with migrating content, but may also help to recreate the site collection structure within SharePoint online.
Just as there are numerous planning and preparation tasks that must be completed prior to an Office 365 migration, there are also post-migration tasks to plan for. For example, organizations will need to modify their DNS records to point to Office 365 as opposed to local servers, and may also need to decommission the servers that they’re no longer using.