SBS (Small Business Server) 2011 is basically Windows Server 2008 R2 bundled with Exchange 2010 in a single suite. Therefore, you would expect SBS 2011 to Microsoft 365 (Office 365) migration to be similar to Exchange 2010 to Office 365 migration. As it turns out, there are some differences that affect the migration process. Read on to learn why it’s a good idea to migrate from SBS 2011 and your options for migrating data to Microsoft 365, the most popular migration destination.
Why migrate from SBS 2011 now?
SBS 2011 includes Exchange 2010. One thing is that you should not expect any new features in the version of this server. No big surprise here, especially since it’s been over 10 years from the release date. But even if your business is doing well and you don’t really need the latest features, Exchange 2010 and SBS 2011 will soon reach the end of their lives. This means that all these security updates will no longer be provided. Unless you’re willing to patch your environment yourself, keeping one of these servers demands security breaches.
After a server is no longer supported, it is not only extremely rare that you will receive patches and updates for your server software. The number of problems you will encounter will most likely increase over time. So if you’re considering a move to the cloud, now is the time.
What migration options do you have?
If you want to migrate from SBS 2011 to Microsoft 365, you can choose from the following migration methods:
Cutover migration
Cutover migration is probably the oldest native migration method. Simply put, this method basically transfers all mailboxes and their contents to the destination server in a single batch. While it sounds incredibly simple, there’s a lot more going on behind the scenes. Before you actually use your Exchange admin center to perform the migration, you need to make sure your source and destination servers are prepared. Cutover migration is also usually done outside of working hours as it involves some downtime. This migration method is almost identical to migrating a standard Exchange 2010 environment.
For a detailed migration plan see: Migrate from Exchange 2010 to Office 365.
express migration
Express migration seems to be the best choice. Finally, it’s the fastest native migration method without preserving directory synchronization. It’s better than Cutover because it allows one-time syncing of usernames and passwords, doesn’t require recreating Outlook profiles, and also promises little downtime. While you would still have to assign Microsoft 365 licenses to each user separately, the list of benefits is still longer than with the cutover method.
As good as that sounds, there’s a catch. According to Microsoft Azure AD Connect requirements Article “Azure AD Connect cannot be installed on Small Business Server”. While it’s technically possible, it’s not supported, and if you run into any unexpected problems you’re basically on your own. Since AAD Connect is required for express migration, this migration path is risky.
Hybrid environments (hybrid migration)
Again not officially supported, but theoretically possible. The easiest way to perform a hybrid migration would be to install the modern hybrid agent, which you can do on Exchange 2010 as long as the agent is installed on Windows Server 2012 R2 or later. Again, the difference between a standard Exchange Server 2010 and its integrated version included with SBS 2011 affects what you can and cannot do.
Apart from that, there are other things to consider. Would you like to keep your outdated SBS running, for example for AD management purposes? For hybrid environments, it is recommended to keep the last Exchange server running, which may defeat the purpose of the migration. At least if minimizing your local infrastructure is one of the goals. If you need a hybrid, you could migrate to Windows Server Essentials 2016 and then switch to a hybrid, but that means you’re doing a double-hop migration, increasing your hassles and the time you would have to book for the migration , double.
Hybrid Configuration Wizard – Step-by-step guide
PST migration
The most manual form of migration. You need to export your users to CSV, export mailbox contents to PST, and then create your organization in Microsoft 365 from scratch. As long as you only have a few users with few items in their mailboxes, this shouldn’t be a problem. The more users and items, the worse it gets. Here is some information on why using PST files is not the best idea (although the article focuses on backups, the issues discussed also apply to migration).
CodeTwo Office 365 migration
CodeTwo Office 365 Migration – this method requires a third-party tool. In turn, you make the transition from SBS 2011 to Microsoft 365 much faster and easier than using any of the above methods. Instead of following a long list of pre-migration activities, simply add your custom domain to your Microsoft 365 tenant, then configure the software to your liking and let it do all the heavy lifting.
Here are some of the reasons why using CodeTwo Office 365 Migration is the best way to migrate your data to the cloud:
- You get an intuitive user interface and a consistent migration experience for a variety of migration scenarios.
- The software verifies that accounts you use for migration have the correct permissions and helps you assign them if necessary.
- This allows you to migrate directly from SBS 2011 (or SBS 2003/2008) to Microsoft 365 with no downtime.
- With post-migration rescanning, you can be absolutely sure that no critical mailbox items remain in your source environment.
- The software can automatically create and license users in Microsoft 365.
- You get 24/7 technical support that is included in the price and available at every step.
Don’t take my word for it, download a free 30-day trial and see how it works:
