Let this valuable guide make your migration as seamless as possible and ensure success throughout the entire process by helping you:
Ready? Then, let’s go!
If you’re an Active Directory house (and you probably are), you’re most likely going to use something called Azure AD Connect (AADC). This allows folks to login with the same credentials they use for applications not being moved to the cloud.
But first, you need to ensure your Active Directory is healthy enough to synchronize with Azure. This means bringing a couple of tools into play.
First, review your Organizational Unit (OU) structure and decide if you want all that extraneous data pushed into the cloud. Many objects aren’t necessary in the cloud, so why push them there? Perhaps all you need migrated are user accounts and some distribution and security groups. Better to adjust the structure so that when you select the OUs to synchronize in Azure AD Connect (AADC), you don’t have to jump through more hoops to select what you want (and deselect what you don’t).
Next, run Microsoft’s IdFix tool. This will provide a report of all the fields (names, addresses, etc.) that are incompatible with Azure Active Directory. IdFix also finds duplicate addresses and invalid characters. Since you’ve already tidied-up the OU structure, you can tackle the objects you know are in-scope first, then return to clean up the rest of the directory when time permits.
Azure AD Connect has specific requirements, so review this link and carefully follow them. The sites that only discuss AADC will tell you the AD Forest Functional Level (FFL) only needs to be 2003 or higher. While this is technically correct, you’ve probably got Exchange in the mix and you’re probably going to deploy an Exchange “hybrid” server, so you can manage users from an on-premises resource, which means you’ll need the FFL to be at least 2008 R2. Thankfully, the AADC is relatively easy to install and configure.
Let’s assume you’re running Exchange (if you were running Notes you’d have greyer hair). First, you’ll want to review your Exchange environment to make sure it meets the minimum requirements. The bare minimum is Exchange 2010 SP3. That may seem old, but I’ve encountered Exchange 2010 SP2 a handful of times over the past year so it’s by no means a statistical outlier.
Spend some time cleaning up old distribution lists and removing mailboxes that are no longer required or in use. You don’t want to waste time (and perhaps licenses) on old data and users who are no longer with the company. Work with HR to clean the Exchange databases and purge any mailboxes that are no longer required. Management, legal and perhaps HR will also have a handle on how much Email ought to be retained. Sometimes, policies to purge old data are not universally applied. Don’t forget to ask users to purge data they know they shouldn’t keep but are reluctant to delete. The more unnecessary data you have, the longer it will take to move the good data to Exchange online.
Additionally, review your send and receive connectors. Sometimes, SMTP connectors persist that aren’t needed. Perhaps you switched from Mimecast to ProofPoint, or vice-versa. You don’t want to retain confusing information in the new environment.
Ideally, you’ll want an Exchange 2016 server in the environment, because it shares a similar look and feel with Office 365 Email Management. This Microsoft guide will help you migrate a legacy Exchange 2010 server environment to Exchange 2016. Once you introduce this server into the environment, run the Hybrid Configuration Wizard (information on this is here). This tool will create the necessary federation connections to the Office 365 tenant, letting you make changes to user mailboxes using the on-premises server, and then sync those changes to the cloud. You can also use this system to initiate the migration of on-premises mailboxes to Office 365.
Message hygiene solutions are prevalent these days, both on-premises and cloud-based. These include Mimecast, ProofPoint, and Barracuda, to name just three. Each of these offers documentation on integrating with Office 365. Mainly, these services scan and pass SMTP traffic, so there’s little else that need be done. Download the relevant documentation from the vendor and review the Office 365 sections. These will help you configure the service to send Email into Office 365 rather than to the on-premises server, as well as configuring the outbound connector to send messages from Office 365 into the cloud-based solution.
If you have an existing on-premises hygiene solution, you’ll be getting rid of it. You don’t want your Email travelling out of Office 365 to your data center and then out again to the Internet. That’s pretty inefficient. Instead, implement a cloud-based hygiene solution from either your on-premises vendor, or have Microsoft take care of all the hygiene and data loss prevention (DLP in the parlance) for you.
For many organizations this is going to be the thing that is most visible and takes the most time. You’ll want to gather all the information from your phone service vendor about voicEmail-to-Email integration (e.g. are you using Cisco, Mitel, Avaya, etc.?).
For instance, you’ll want to know the locations of all the fax servers because they‘ll need to be reconfigured to send faxes to an Office 365 mailbox rather than to the local Exchange server—not least because the server they currently communicate will be decommissioned as part of this migration exercise (and is almost certainly out of support, anyway).
Gather information about all applications deployed on-premises that need to send Email. Your IT help desk system, timesheet system, and expense notifications will all need to start delivering Email to Office 365. At your earliest opportunity, document everything and discuss reconfiguring the applications with the service owners. It’s best to get these things ironed out before moving users.
When planning your move to Office 365, one decision will be whether to continue with the distribution groups as-is, or move them to shared mailboxes or Office 365 groups. Some applications don’t like to communicate with shared mailboxes, but instead require a “conventional” mailbox. Don’t just assume you can make an Office 365 shared mailbox for all the applications delivering Email. Some incompatibility is possible, so be sure to research the vendor documentation. Luckily, you can convert from shared to normal, and back. Remember though, that if you convert from a shared mailbox, you will have to assign a license. So, it’s in your best interest to maintain a shared mailbox since it’s cheaper for the business.
Note: for more information on licensing, be sure to check out this additional blog post.
For users who just need basic browser-based access to Email, an E1 license might suffice. No downloadable versions of Microsoft Office are available with this license, but Skype and Teams are available in the browser and the mailbox size can be as large as 50GB.
If your users need a local installation of Office, an E3 license is necessary. In addition to downloadable Office software, the package also includes eDiscovery, archiving, legal hold, and a maximum mailbox size of 100GB.
Other tiers and packages are available; those mentioned here are the most common. The takeaway here is to prepare an Active Directory group for each license type you’ll need—including add-on license packs such as Mobility or Azure Premium—and populate the groups with user IDs. Next, license the groups in Office 365 in order to know precisely how many licenses you have, how many you need, and who has what license. In this manner, you’ll also be able to tell if you’re short any licenses—and can take the necessary corrective steps—even before you’ve performed any migrations.
Another tangential aspect of licensing is that of shared mailboxes and resources. While user and service accounts do incur a license cost, shared mailboxes and resources do not. Bear this in mind when calculating your licensing needs. When you plan the migrations, be sure to convert the mailboxes to shared, and room or equipment resources as soon as the cut-over completes. You’ll discover that some applications (likely legacy) cannot be used with shared mailboxes. Unfortunately, you’ll have to assign a license to these mailboxes, but won’t be able to convert them to shared mailboxes in Office 365.
Office 365 allows you to delegate far more functions than before, so it’s important to ensure you won’t be burdened with managing the whole environment by yourself. Assign users in finance responsibility for billing. Think carefully about which roles to assign to current Active Directory admins; the User Management Administrator role is probably more appropriate than Global Admin (who has rights over everything). Similarly, assign Exchange Admin and SharePoint Admin to those administrators rather than the Global Admin role. Your admins will know they’ve been granted administrator rights because the Admin Tile will appear on their personal Office 365 portal, and they will see only links to those tasks to which they’ve been assigned.
Say you have a lot of data stored in Windows, or on other file servers and NAS systems. When moving to OneDrive in Office 365, not only will your users be able to store files in the cloud, they may also—if you permit it—share data with users inside and outside your organization. When you set up your tenant, take a look at the OneDrive admin console when setting up the sharing policy. The default is pretty wide open so you’re going to want to dial that down to a level your organization will be happy with. You may configure more than just Email with a retention policy, so be sure to have this in place before migrating users to the cloud. The same goes for DLP policies and any data that might be subject to legal hold. In terms of policy and retention, everything you can do in Exchange, you should also plan for in OneDrive.
Of course, you might not want to use that storage. Perhaps your file services aren’t ready (or appropriate) to move to the cloud. In this case, simply disable OneDrive. Work through the options with the business and implement before migrating any users.
Be aware, moving personal data to Office 365 exposes it to greater threats and challenges. You may already have a solution for managing devices that roam outside company property. And if so, great. All the major vendors offer solutions for managing access to Office 365, though some charge for the add-on security. But what if you don’t have a device management solution, or even an enforceable policy? Until now, you’ve been able to permit Email on mobile and home devices with great ease through ActiveSync and OWA. But without additional high-maintenance infrastructure, access to collaborative resources, such as SharePoint and Skype, have been out of reach. Carefully consider what you want to allow on devices your company doesn’t own, and what to permit outside the company environment on devices they do own. Plan to allow the same level of functionality in either case, and also plan to permit access to data located inside the company VPN. Review some basic security on the devices and require a configuration policy to set a PIN, PIN expiry, minimum device OS version, and so forth. If the devices are owned by the company, the company has the right to enforce policies. If users are allowed to use their own devices to connect to company data, they’re obliged to accept some restrictions in return for the access.
Measure twice, cut once! You have only one chance to get your Office 365 deployment right, so it’s vital to spend as much time as you need to map out your infrastructure, what services to migrate, and when to do the migrations. Gather all the info you can from your current Exchange environment: mailbox sizes, users on legal hold, and users with archived mailboxes. Purge your Active Directory of extraneous user accounts and groups you don’t need to replicate up to Azure AD. Understanding your licensing requirements matters because this represents a significant monthly cost to the business. Work with stakeholders—such as application or systems owners—who need to receive faxes, send helpdesk tickets and forward that data to mailboxes or SharePoint sites that will now be in Office 365.
First, you’ll need to ensure your organization has the correct SMEs in its migration team. SMEs include technical and business teams, such as Network, Exchange, Active Directory, Information Security, Communication, Help Desk & Desktop support leads. These individuals will play an important role in decision making, user acceptance testing and execution. It’s also beneficial to include a 3rd party integration partner, like Anexinet, one that has the expertise to guide you through a successful migration.
A Migration Plan is crucial to the overall strategy of any migration.
A few things to keep in mind when developing your strategy are:
Stay within budget
Maintain organizational security
Aim for a target completion date
Keep users happy
Now let’s take a look at the top three strategies for migrating to Office 365 to help you determine which approach best suits your organization: Staged-Exchange Migration, Cutover-Exchange Migration, and Hybrid-Exchange Migration.
When developing a migration plan, an organization may take several approaches. One strategy—most commonly used by large organizations—is a “Staged-Exchange Migration” or “Phased” Migration. This strategy schedules the migration in “waves” based on the project-completion timeline. This timeline, in turn, should be based upon the number of users and the amount of data to be migrated.
When creating your migration waves, always consider the Shared/Resource Mailboxes. Migration waves may be categorized by geographical or physical location, by department, or by mailbox size. Regardless of which method you use, always consider users who have access or mailbox delegation to a Shared/Resource Mailbox. For example: Administrative assistants should be migrated with the individuals whose mailboxes they manage.
The same goes for the “Accounting” team—regardless of their geographical or physical location. Those who have access to the “Accounting” mailbox should also be migrated in the same migration wave. This will not always be an easy task; however, it will alleviate issues and reduce support calls during the coexistence period.
A second migration strategy is the “Cutover-Exchange Migration.” This is good for small organizations looking for a fast migration cutover (say, over a weekend). A cutover migration is recommended for organizations utilizing an on-premises Exchange Server (2003 or later) or an on-premises Exchange with fewer than 2,000 mailboxes.
The third option is a “Hybrid Exchange Migration.” This allows for long-term, cross-premises coexistence, in which your organization’s end state is both on-premises Exchange and Office 365. This approach may be required when some mailboxes or 3rd party applications (that integrate with Exchange) aren’t compatible with Office 365.
The Hybrid Exchange Migration approach lets an organization keep a leg in the Exchange and Office 365 worlds, while also allowing it to move a select number of users or departments (at a time) into Office 365, at a pace suited to the organization’s needs.
To utilize this approach, your organization will need to meet some requirements. First, you’ll need to setup (or have in place) a Hybrid Server to host the connection between your on-premises Exchange Server and Office 365. You’ll also need to utilize Directory Synchronization (such as Azure AD Connect Sync), since a Hybrid configuration relies on it.
The strategy an organization ultimately chooses is dependent on its environment, priorities and culture. When determining their ideal Office 365 migration strategy, an organization must ask, “What’s the best way to improve the performance of our data migration, optimize the migration pace, minimize downtime, and achieve a positive user experience?”
As part of the migration process, your organization will need to send several communication Emails. Here are a few suggestions:
Developing an effective training plan means anticipating and documenting all the questions users may have and providing adequate training materials. Training should take several approaches and be geared toward maximizing training effectiveness (along with the users’ time) during the sessions.
Specific to executive staff and assistants, the main focus here would be on the “White Glove Treatment.” This consists of a select, dedicated group of technicians skilled at troubleshooting and interacting with executives. All VIP troubleshooting is typically coordinated with the executive’s assistant.
The target audience for Onsite Migration Prep Sessions should include all user types, and the content should include general info on what users will experience and what they will be required to do as part of the migration process. Example topics include a user migration demo/test, known/expected issues users may encounter as part of the migration process, a catalog of items that will (and won’t) be migrated, and (reiteration of) the details of the post-migration support-request process.
User Lunch & Learns should include a demo of the benefits and features Office 365 has to offer. Topics should include: how to request permissions to shared mailboxes, how to save files to OneDrive, how to properly and effectively collaborate using MS Teams (including chat and meeting-scheduling). Additional topics might include a deeper dive into Outlook’s features, depending on the organization’s level of expertise.
When transitioning to O365, a detailed FAQ document is always helpful as it provides information on what users should expect as part of the migration. An FAQ document should include what users should do prior to leaving the office the day before their scheduled migration, along with what will be expected of them following the migration. It’s also important to document any “known issues,” along with a running list of frequent questions being called in to the helpdesk to help reduce future helpdesk calls. This document should be posted on the organization’s intranet and the link Emailed to users as part of communications.
Internal support staff should conduct live webinars, utilizing a 3rd party partner to assist in hosting sessions, specifically around pre- and post-migration questions and issues. This also represents a great opportunity to stay ahead of the game regarding documentation in order to help eliminate or reduce repeat questions/calls to your support staff.
All the applicable information your IT team has developed as part of their testing and pilot experience should be placed on an intranet site. Be sure to capture all material used to document the user experience around pilot migrations, FAQ, as well as feedback from pilot users and helpdesk scripts.
Support training materials are specifically targeted to your helpdesk, desktop and onboarding teams. Content should include specifics around O365 support training, including how support staff would add new users, delete users, change SMTP addresses, apply Legal Hold, apply mailbox permissions, create Microsoft support tickets, view the O365 Service Health Portal, and perform O365 connectivity testing (https://testconnectivity.microsoft.com).
Developing an onboarding process and designating the responsible teams (post-migration) is a critical step. At some point, your organization will need to stop creating mailboxes via a legacy process and start creating them using Microsoft’s recommended method (the Microsoft Azure Active Directory Synchronization Tool or Microsoft Azure Active Directory Sync Services) in order to synchronize/create on-premises users in Office 365. After migrating mailboxes to Office 365, you’ll be able to manage user accounts on-premises via Active Directory, which would then synchronize with Office 365. For additional information on directory synchronization, refer to this Microsoft article on Directory integration.
Ensure all helpdesk processes are in place at least one week prior to production migration. This will allow your team to be prepared for—and focused on—handling support calls, versus having to tidy up helpdesk scripts and processes at the last minute
Developing and implementing a well-designed escalation path for Level 1, 2 and 3 support prior to migration will reduce user frustration by ensuring support staff is comfortable handling high-priority issues and knows where and to whom they should be escalated.
Ensure all support teams are informed on migration dates and on which users are being migrated. Provide them with adequate training and materials for troubleshooting.
To handle the increased call volume and eliminate extended wait-times and walk-up visits, it’s beneficial to increase the number of Support Techs available during and after the migration.
Enact a specific Call-Number Option for users experiencing migration-related issues. This will let your helpdesk handle migration-related calls more efficiently as they will be quickly directed to a support tech who will be immediately aware if the user is inquiring about an Office 365 or migration-related issue.
Ensure proper daily analytics are collected, analyzed, and sent to requisite stakeholders. This allows the stakeholders and technical support staff to implement any processes, technical needs or helpdesk scripts that may be required to efficiently handle issues that arise during and after the migration.
While the benefits of moving to Office 365 are many, laying-out a comprehensive plan beforehand is critical to ensure project success, optimizing and accelerating your migration while avoiding the usual risks, letting you maintain productivity and realize fast gains on initial investment. Whether you’re upgrading from an older version of Exchange, Lotus Notes, or transferring data from tenant to tenant, a seamless, secure migration is key to minimizing disruption.
Anexinet’s Office 365 Migration Strategy Kickstart prepares your organization for a successful Office 365 migration. Anexinet takes a holistic, best practices approach to Office 365 migration that optimizes performance and encourages adoption through training. Our consultants guide your organization through the migration lifecycle, steering you around potential pitfalls to guarantee a successful outcome.
Our Office 365 Migration Strategy Kickstart enables process efficiencies on day one, strengthens your security organization, assesses the preparedness of your infrastructure, and generates an Office 365 Adoption Roadmap. All in just two short weeks.