Let’s assume you’ve decided to pursue an Exchange Online migration. Is your move motived by the 0-day exploits being perpetrated against Exchange servers by HAFNIUM? Perhaps you simply just want to take advantage of all the benefits that moving your mailboxes to the cloud can provide to your organization and your end-users?
In my last blog, I outlined the Top 5 tips for planning an Exchange Online migration. This time, we are going to wrap this topic up by revealing our expert’s top 5 mistakes to avoid when planning your Exchange Online migration.
What should you avoid in an Exchange Online migration?
Let’s dive into what you shouldn’t be doing when planning your Exchange Online migration project.
1. Don’t move everything
Many administrators and leadership assume that users want and need every bit of their data to effectively function in their daily work lives and without it there would be a revolt. Experts we spoke to unanimously agree moving all your data upfront isn’t always attainable or required. Based on decades of experience designing, deploying, and managing migration projects, I wholly agree.
Now the primary focus of this blog is to discuss moving mailboxes from on-premises Exchange to the cloud. All the Exchange gurus out there right now reading this are uttering this phrase, “You can’t filter mailbox content using Mailbox Replication Service (MRS)”. And, of course, they are right, you can’t filter using this migration method. BUT… who is to say you must use this method if it doesn’t meet your project requirements? You don’t want to bend your project requirements to the tools you are using, instead find the correct tools that fit your requirements. There are plenty of reliable solutions on the market to copy mailbox data that provides filtering options.
For the sake of this discussion, let’s move beyond Exchange Online mailboxes and expand our topic to include other potential migration workloads that you may encounter during an Exchange Online migration project.
When moving users up to the cloud, they have mailboxes, archives, files, and Public Folders. When you move between tenants, you add to the user’s workloads, private, group and meeting chats, and to the shared workloads you also add SharePoint, Teams and Groups. All these different workloads are unique to each identity and can amount to terabytes or petabytes of data. A vast majority of this data is historical, rarely accessed and more than likely not required within the next 90 days. That 90 days provides you a window of opportunity to accelerate your migration velocity and meet those difficult timelines.
When you have a lot of data to move and a short time to move it, our experts recommend the following strategy to meet your migration goals.
- Provide the last 90 days of used data to each user then backfill their historical data after the user has been moved.
- Once the user is moved and working in their new environment, you’ll have time to migrate all their historical data while they continue to manage their daily workload.
- By reducing your initial data footprint, it becomes possible to move your users to the target more quickly.
Here is a surefire set of parameters to meet your user’s needs while keeping the initial data size as small as possible.
- Migrate the last 90 days of mail, the next 90 days of meetings with all reoccurring meetings, all personal contacts, and tasks. Those parameters cover your user’s mailbox content.
- Migrate the most recently used files and folders by age, keep file versioning to a minimum by only migrating the latest versions and filter out files that are too large or perhaps common file types like media files that tend to be larger.
I’m not going to cover the other workloads because these tips should get your mailboxes to Exchange Online as quickly as possible. However, the strategy is the same for the other workloads. Reduce the initial data move to migrate your users over to the target as quickly as possible then backfill their historical data.
As organizations expand their cloud storage usage, there may come a time when migrating ALL your cloud data up-front is no longer practical. Adopting this type of strategy will be important to successfully move the vast volumes of data stored in today’s modern workloads. The lesson to take away from all of this is, if you want to crunch a lot of data into a rapid timeframe, reduce the upfront load by using age filters, cutover your users and then backfill historical data over time. You’ll find your users remain productive and most are unaware that some data may not be there yet, because all their most recent work is.
2. Don’t keep Public Folders
Why are Public Folders so scary? I don’t want to dwell upon this question, as I am sure most reading this know why, but let’s cover the more obvious reasons. Public Folders are an outdated technology that have been part of Exchange since day 1 and there is now an endless array of better, more secure solutions to fulfill the same needs within Microsoft 365. Besides, the same problems that drove organizations away from Public Folders in the first place still exist today. Public Folders are unruly, encourage sprawl, are hard to regulate and motivate end-users to circumvent mailbox retention and size policies by using Public Folders as an archive solution. That was never what it was intended for.
Now, since you have decided to move your on-premises mailboxes to the cloud, you’ll next need to decide where to migrate any Public Folder data you may still be hosting. The great thing about moving to the cloud is it offers you the opening to move this Public Folder data into more modern collaboration tools like Office 365 Groups or even SharePoint Online. Of course, with Exchange Server 2013 and higher, you have the option to migrate directly to Exchange Online Public Folders, maintaining folder hierarchy and the granular permission roles that Public Folders offer. However, there are some restrictions you should be aware of first. If any Public Folder in an organization is bigger than 25GB, Microsoft recommends you clean up unwanted data to reduce the size (i.e. delete it, if you don’t need it!), or the Public Folder’s content first by separating it into multiple, smaller Public Folders before migration. In addition, Exchange Online restricts an organization to Public Folder hierarchies of up to 500,000 Public Folders, and the maximum total size of all Public Folder mailboxes is 50TB.
In our experts’ estimation, you only have two sensible migration paths to consider: either keep Public Folders on-premises, (operating in a hybrid mode) because they exceed Exchange Online limits, or you migrate any necessary Public Folder data to Office 365 Groups. Each Office 365 Group has a Group Mailbox with a maximum size of 50GB and Groups offer a variety of other advantages that Public Folders cannot. The beauty with Office 365 Groups is that within Outlook, they can easily replace the mail-enabled functionality that Public Folders offered to your end-users previously. Outside of the key email functionality, there is a shared calendar where all team members can manage the group’s meetings, collaborate on emails, documents and even converse directly from the group with chat. The other monumental difference between Groups and Public Folders, and can’t be overstated, are applications. When you migrate to a Group, you unlock access to an extensive library of powerful apps from Microsoft 365. Public Folders don’t offer integrations like this.
I bet you are wondering why we are recommending migrating your Public Folders to Office 365 Groups and not SharePoint Online, as previously mentioned. It’s simple, it is easier and was built to do so. Using the batch migration process managed through PowerShell or through a third-party product will provide you with a method to copy the mail and calendar data from your Public Folders directly to Office 365 groups without any intermediary steps. Migrating this same data to SharePoint Online isn’t as simple or as supported a path. Besides, once you migrate your Public Folders to Office 365 Groups, you can convert those groups to Microsoft Teams if you so desire, offering even more collaboration solutions to your users.
The experts have one final tip to share about moving Public Folder data, if you are a Microsoft 365 Multi-Geo customer or migrating to a Multi-Geo tenant, although public folders are supported, they cannot be moved to a satellite geo and must remain in the central geo location. That may make moving those Public folders impossible in this case, so keep that in mind when planning your move.
Now by no means is moving Public Folder data into Office 365 Groups a panacea and the path you MUST take. Some large organizations will find it impractical due to the volume of Public Folders they plan to retain. However, keep in mind some of the advantages we covered here when making your final plans.
The last thing I will say, apply the first rule we talked about, “Don’t move everything”. That rule applies here too. Only move what is absolutely required.
3. Don’t forget about applications
In part one of this blog series, we talked about the importance of identifying applications that have some form of integration with your on-premises Exchange servers. After compiling an inventory of known applications, it is time to begin to evaluate each application to determine its future. Most application migrations to the cloud have little to no ROI. So, you must decide if they are business-critical enough to retain or retire. Each identified application should be evaluated on a case-by-case basis which will result in some being retired, while some portion you will decide to retain. If you decide to retain, then you must determine in what form they will be retained. Below are 5 application migration strategies to take into consideration.
Rehosting
Probably the most common application migration strategy is rehosting, or lift-and-shift. Whereby you simply move the existing application to a cloud infrastructure as a service (IaaS) platform. This strategy is economical and quick but doesn’t provide any application modernization (the application is still not cloud-native so ongoing support will need to be taken into consideration).
Revise
The next strategy is to revise the application. When revising an application, you begin to modify it to take advantage of cloud capabilities, like app containers and newer data storage methods. This strategy is focused on lowering operational overhead using managed cloud services but requires experts in the application and new technologies to build a plan on how to release it without interrupting present services.
Rearchitect
Where the last strategy could be considered a light modification of the application, the next strategy, in contrast would be labeled a heavy modification or rearchitect strategy. When you rearchitect an application you rely heavily on cloud-native capabilities to achieve your goals. As with the last, this strategy requires a plan and team to migrate the application seamlessly.
Rebuild
If you can’t revise or re-architect the application, you may need to scrap it all and start over with a rebuild. A rebuild consists of abandoning some or all the existing code and beginning again. There are many advantages to this approach if the application is truly business critical to your organization. As a Technical Product Manager, I hate technical debt and with this strategy, you can erase all that debt in one swipe. Boy wouldn’t that be nice with your personal debt! With Microsoft 365 Power Apps and Dynamics, you may find that a rebuild may not require a seasoned developer or team to plan the migration. You may find that you can enable non-developers to deliver applications through point-and-click styles of development now offered in Microsoft 365. Rebuilding may also offer you an opportunity to simplify and improve your original application design. Developers will also find they are able to focus on writing great new code instead of adapting or fixing old code that someone else wrote originally.
Replace
The final strategy for application migration is to simply replace it with something else. If you can find a SaaS provider that meets your application’s business requirements for your custom application, then this strategy provides low barriers of entry with an appealing time for delivery. Replacement should not be ruled out, with the explosion of SaaS solutions, there may be a solution out there waiting for you to discover. So, do you research before you decide!
If you can’t retire that application, then use the five Rs to help you decide where to take that application. Remember the options are to, rehost, revise, rearchitect, rebuild or replace.
4. Don’t overburden your support staff
When planning a phased Exchange Online migration project, our experts recommend that you size each migration event (i.e. how many objects), based on the amount of data you can push and the amount of change your organization can absorb during that event. In this blog, we are focused on the organizational impacts a migration can have, regardless of how prepared you are. We recommend that you ramp up to find terminal velocity. You will know when you have exceeded your support organizations and migrations teams’ capacity to maintain terminal velocity when your team is still managing migration tasks and/or remediation issues that were expected to have been completed hours before and you are running into the next event’s scheduled activities. If you have two consecutive events like this, revaluate your capacity and adjust.
Scheduling
The experts overwhelmingly recommended that you schedule migration tasks on the weekdays to begin to push data into the target. Optimally, scheduling during off-peak hours is the best practice to maximize data throughput but we also always recommend that data be migrated continuously, just to a lesser extent. Smaller batches during the day, with larger ones during off-peak times.
Schedule the final events that impact the end-users during the start of a weekend so that final delta migrations and related post-migration activities may complete while the end-user’s applications are reconfigured. On Monday, when the end-users return to work, their latest data will be available for them to begin their workweek. However, there will be problems, confusion, and general questions… there always is. This is when internal and any augmented support staff will begin to receive the first influx of new incidents for users.
Communication
If you read part two of this blog series: 5 tips for planning an Exchange Online migration, I spoke about the importance of over-communicating to your end-users and providing great resources in the form of documentation and videos. If planned properly, your support staff will have answers to frequently asked questions and have resolutions on-hand to the most common connection issues, like new passwords and logins. We recommend involving your support teams in pilot events and providing them an easy conduit to access logs, migration statuses and reports so they are totally prepared to process as many incidents that reach them to ensure you reach your terminal velocity.
Event design
The final piece of wisdom the experts shared about optimizing the size of your migration events was that not all events must be equal. Don’t think because you prove your organization can manage moving 2,000 users over a weekend that the following weekend you must do the same. The goal is to reach the final number. If one week you can maximize velocity with 2,000 users, do it! However, if the next weekend, it is a different region or office, which only hosts 500 users, don’t get locked into a single size. Design the scheduled events based on the known local factors, such as the end-user’s location, time zones, connectivity limitations, support availability, etc. All support is local, so be sure your events are based on local conditions, not just how much data you can migrate at a time. That is only one variable in capacity planning for a migration project.
5. Don’t migrate to Azure Active Directory… yet!
If you are moving your mailboxes to Exchange Online, and maybe even some of those legacy commercial off-the-shelf software products you have, you may feel the urge to start investigating if you should migrate services that on-premises Active Directory (AD) provides today to Azure Active Directory. Our experts say don’t waste your time. This isn’t the time to consider that type of move. However, if you do in the future decide that moving identity management to Azure exclusively is the right move for your organization, then moving your user’s data like mailboxes and Public Folders would be a prerequisite to begin the process. The path you are on—getting that remaining user data into the cloud gets you one step closer to retiring additional Microsoft infrastructure from on-premises data centers, reducing ownership costs and expanding your organization’s capabilities and options for the future.
One solution. Many workloads.
Preparing for your move to the cloud
I began this blog series talking about the new security risks that hosting on-premises Exchange servers may have on an organization considering today’s new realities since the HAFNIUM attacks. With these new risks, many will plan to move their mailboxes, archives, and Public Folders to Exchange Online. I hope that these tips provide valuable guidance of what to do and what to avoid when planning your Exchange Online migration.
If you’d like assistance, Quest can help plan and execute in all areas mentioned above. We offer a wide range of secure software solutions available in SaaS and on-premises models and provide professional management of entire migration projects.
If your organization has been affected by recent attacks, or you need help determining if you have been, contact us to see how we can help.
Until next time… Go harden those Exchange servers!
