When I last left you, we were discussing the HAFNIUM attacks and the probable impacts an Exchange Online migration may have on your infrastructure, systems, and internal processes within your organization. If you missed part one about whether on-premises Exchange has become too risky, you can catch-up here.
In this blog, we are going to continue that conversation, assuming you are starting the planning process of an Exchange Online migration or a migration to Microsoft 365. We’ll talk about the secret sauce of planning and managing a successful enterprise migration project. I’ve dug into my Rolodex (do people still have those?) and called up some expert project managers, migration engineers and solution architects with years of experience, to bring you the top five tips for planning an Exchange Online migration
Retiring your Exchange on-premises mailboxes, public folders, and all the other interrelated systems can seem like an impossible task, but with the proper guidance, we will provide your organization with all the known benefits the cloud offers in security, scalability, and cost savings.
Top tips for planning an Exchange Online migration
Let’s start with what you should be doing when planning your Exchange Online migration project.
- Designate an experienced migration project manager – The experts have spoken, and experience is king! Choosing a project manager that has successfully executed this type of project, and one that also knows your organization’s structure and business operations, is key to a successful migration.
The role of a project manager during a migration project primarily consists of driving a plan to complete a set of scheduled migration events with as little interruption to the organization as possible. That should be their primary impetus to successfully move some number of resources within a set amount of time.
Besides driving the migration events, a project manager will also act as liaison to the business units that are required for the success of the project. This person will provide status updates to stakeholders, and address critical issues to resolution in order to ensure success. In short, an experienced project manager is worth his or her weight in gold.
- Establish Exchange hybrid coexistence – All our experts agree. Avoid Big-Bang migrations (i.e. moving everything and everybody in a single event). Why? The risk is normally too high, and the stress on support staff required to successfully execute is unwarranted.
With single-event migrations, there is no room for error. There will also be problems that are outside of your control. All migration events have one thing in common—something you didn’t plan for will happen. To avoid this risk, our experts say that establishing Exchange hybrid coexistence between your Exchange on-premises users and your existing and migrating cloud users is paramount to a smooth, functional transition and will ensure end-users, support staff and management are all satisfied with the end-results.
You can keep mail flowing, calendar availability up-to-date and ensure security and policies are maintained by running the hybrid configuration wizard. It has never been easier to set up, even if you are using Active Directory Federation Services. The process and automation have become so easy that even the least experienced administrators can manage to get it all set up in less than a day. Believe me, that is far better than it once was, but the first time is always the hardest. When possible, establish coexistence for all your migration projects. It will take a lot of stress and burden off when planning the project.
- Map out your policies to replicate to the target – Oh boy did the experts have a lot to say about policies and the sheer plethora of them. The different policies that may touch an average user’s Exchange mailbox is staggering. From regulating the size of the mailbox, to how long items are kept, or even if some data may be deleted. You have recipient size limits, send limitations on amount and size, not to mention retention tags that a user may assign to individual folders or items.
So, why are policies important to map out and plan before you start your Exchange Online migration?
Well, you may think you can simply start with the defaults in the cloud and worry about it later. That is recipe for disaster the experts say. Let’s pick on Exchange retention policies and tags, commonly referred to as Messaging records management (MRM). Let me start by saying, not all policies are equal. That is the prevailing rule when mapping and moving policies between email systems of any other system. What may operate one way on-premises, may act differently in the cloud, or may not exist in the same form.
Retention tags are particularly tricky, since not only do these involve mapping out the exact same policies from on-premises to Exchange Online, it involves maintaining the individual folder and message items that were tagged by the end-user. Depending on your chosen migration methodology for moving your mailboxes, these tags may not be supported. If retention tags are widely utilized in your Exchange on-premises organization and by your end-users, be sure to confirm your migration method supports it.
I pick on retention tags for two reasons, first they are complex with both an administrator component and an end-user component that can be unique for each user. Secondly, and to illustrate my next point, Microsoft 365 is moving towards newer systems, methods, and controls to manage all your online data safely from a single system. As time progresses, Exchange Online will depreciate retention policies and tags in favor of using Microsoft 365 Security & Compliance features such as labels.
You already see this change impacting the new Exchange admin center, where all the compliance features are no longer visible from that portal. You must revert to the legacy portal to gain access or use PowerShell. Microsoft directs you now to create and publish labels in the Office 365 Security & Compliance Center to protect all your content in SharePoint, OneDrive, Exchange, and Microsoft 365 groups. Remember, as you map out your current on-premises policies, you may need to move to another technology, such as labels over retention tags as illustrated in the previous example. So, make a list and check it twice!
- Over communicate with your users – That’s right, over communicate! Our experts recommend that you communicate succinctly but often. The first task is to formulate standardized communication templates that are localized to region, culture, and language. These templates should include a standard subject that is easily recognizable and is perceived as important. Be sure the communications include a support method to reply to and ask more questions when needed but more importantly, be sure to keep the message short and when needed, include links to good documentation instead of trying to fit everything they need to do or know in a single email. When IT does that, the end-user doesn’t fully read it and ends up most often calling the help desk.
Keep in mind, not all communication during a migration project comes from simple emails. Sometimes it is a matter of composing, procuring and cultivating good documentation, how-to videos, and other sources that are linked to the email or Teams channel chat that empowers the end-user to do things without the need for a support ticket or phone call.
The next priority communication should be sent at project kick-off to prepare everyone that will be impacted and inform them how they will be impacted. After kick-off, when activities begin, be sure to communicate to your end-users their proposed schedule to finalize their move to the target. The earlier you inform the user of their tentative migration schedule, the more time they will have to respond with any blockers they may have, such as travel or critical path projects of their own that could prevent the final move that day.
During the migration, there may be activities that require end-user interaction, such as reconfiguring mobile devices or desktop applications, and other applications tied to their mailbox, calendar, or personal address book. While planning your communication templates, be sure to break them out into the common types you will send, then localize each of those categories. The most common communication types are organization-wide, the group/team level or individual communications that are either informative, directive, or responsive. Meaning you simply want to update the user about an event, that you require them to fulfill a task by a particular time, or you are responding to an inquiry of theirs.
Keep the communication going. If you must send reminders about tasks you require the end-user to complete, send it. Put that email at the top of their inbox. Maybe send an email and post to their Teams feed as well. The point is clear, informative content, along with frequent updates, can ensure that expectations are set by all parties being impacted.
- Set realistic expectations for stakeholders and users – In my experience, this is one of the most difficult things to do, and one of the items that is most often neglected as a priority. It’s not typically on a checklist of things to do, and sometimes the instinct is to leave this subject open ended so if things do go sideways, with no clearly stated expectations you can’t be held accountable. I advise strongly against this. There are ways to making setting expectations to the organization easier. First and foremost, as previously discussed, assign, hire or contract an experienced migration project manager that can properly set expectations based on real-world experiences.
Second, as illustrated in the previous section, communicating often with good, rich informative content is the other way to set proper expectations. With stakeholders, you must set different types of expectations than you would with your end-users. Stakeholders will want to be assured of a few things:
1. Can you meet the end dates based on the size and numbers?
2. Can you guarantee this stuff will be migrated?
3. And finally, some organizations depending on the industry regulations, may want you to prove with audits the items that were migrated.
Most importantly, with stakeholders if their initial expectations and timelines are wrong, speak-up! Show them why the numbers don’t add up. And if that timeline is set in stone, then begin to explore and recommend methods to reduce the amount of data to meet those goals. Setting realistic expectations is hard work, but not setting them can lead to unmanageable results and erode trust between all the different parties. If a migration is “perceived” as unsuccessful by the end-user because it impacted them heavily, even though the end goal was achieved of moving their data, the trust of those end-users of IT or management to conduct a migration is lost and hard to regain.
Next up: What to avoid in an Exchange Online migration
Next time, I’ll finish up this topic and cover our recommendations on what not to do when approaching an Exchange Online migration. Until then, I’ll leave you with this final thought. When you are planning a migration project, regardless of where you are moving from and where you are moving to, always consider how this migration will impact your end-users. That is your #1 priority—lessen their impact to maximize your success.
Stay tuned for the third part of this series. Until next time… go patch those servers!