SBS (Small Business Server) 2011 is basically Windows Server 2008 R2 packed together with Exchange 2010 into a single suite. As such, you would expect migrating SBS 2011 to Microsoft 365 (Office 365) to be similar to migrating Exchange 2010 to Office 365. As it turns out, there are some differences that impact the migration process. Read on to learn why it’s a good idea to migrate from SBS 2011 and what options you have for migrating data to Microsoft 365, which is the most popular migration destination.
Why migrate from SBS 2011 now?
SBS 2011 includes Exchange 2010. One thing is that you shouldn’t expect any new features in this server’s version. No big surprise here, especially since it’s been over 10 years after its release date. But even if your organization is running just fine and you don’t really need the newest features, Exchange 2010 and SBS 2011 will soon reach their end of life. It means that all those security updates will no longer be provided. Unless you are willing to patch your environment on your own, keeping any of those servers is asking for security breaches.
It’s not only that, after a server is no longer supported, it’s also extremely rare to get patches and updates for any server software you might have. The number of problems you will come across will most likely increase over time. So, if you were considering a move to the cloud, now is the good time.
What are your migration options?
If you want to migrate from SBS 2011 to Microsoft 365, you can choose from the following migration methods:
Cutover migration is probably the oldest native migration method. To put it simply, this method is basically transferring all mailboxes and their contents to the target server in a single batch. Although it sounds incredibly straightforward, there is a lot more going behind the scenes. Before actually using your Exchange admin center to perform the migration, you need to make sure your source and target servers are prepared. Cutover migration is also usually performed outside of working hours, as it includes some downtime. This migration method is almost identical to migrating a standard Exchange 2010 environment.
For a detailed migration plan, take a look at: migrate Exchange 2010 to Office 365.
Express migration would seem like your best bet. After all, it is the quickest native method of migration, without keeping the directory synchronization. It is better than cutover, because it allows a one-time sync of usernames and passwords, there’s no need to recreate Outlook profiles, and it also promises little downtime. You would still need to assign Microsoft 365 licenses to each user separately, but the list of advantages is still longer than in the cutover method.
However good this sounds, there is a catch. According to the Microsoft’s Prerequisites for Azure AD Connect article, “Azure AD Connect cannot be installed on Small Business Server”. Although technically it is possible, it is not supported and if you come across unexpected trouble, you’re basically on your own. Since AAD Connect is needed for express migration, this migration path is risky.
Hybrid environments (hybrid migration)
Again, not officially supported but theoretically possible. The easiest way to perform 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 in SBS 2011 has an impact on what you can and cannot do.
Other than that, there are other things to consider. Would you like to leave your outdated SBS running, e.g. for AD management purposes? With hybrid environments, it is recommended to leave the last Exchange server running, which might beat the purpose of the migration. At least if minimizing your on-prem infrastructure is one of the goals. If you need a hybrid, you could migrate to Windows Server Essentials 2016 and then go hybrid, but it means you will be doing a double-hop migration, doubling your problems and the time you would need to book for the migration.
Hybrid Configuration Wizard – step by step guide
The most manual form of migration. You will need to export your users to CSV, export mailbox content to PST and then recreate your organization in Microsoft 365 from scratch. As long as you have just a few users with few items in their mailboxes, it shouldn’t be a problem. The more users and items, the worse it gets. Here’s some info on why using PST files is not the best idea (although the article focuses on backup, the discussed problems apply to the migration as well).
CodeTwo Office 365 Migration
CodeTwo Office 365 Migration – this method requires a third-party tool. In return, you make the transition from SBS 2011 to Microsoft 365 much quicker and easier than using any of the above-mentioned methods. Instead of following a long pre-migration activities list, simply add your custom domain to your Microsoft 365 tenant, and then configure the software the way you want and let it handle all the heavy lifting.
Here are some of the reasons why it’s the best way to use CodeTwo Office 365 Migration to migrate your data to the cloud:
- You get an intuitive interface and consistent migration experience for a wide range of migration scenarios.
- The software checks if accounts you use for migration have the right permissions and helps you assign them, if needed.
- It lets you migrate from SBS 2011 (or SBS 2008) directly to Microsoft 365 with no downtime.
- Post-migration rescan lets you make absolutely certain that no important mailbox items are left in your source environment.
- The software can automatically create and license users in Microsoft 365.
- You get 24/5 technical support, included in the price, available at every step of the way.
Don’t take my word for it, download a 30-day free trial and see for yourself how it works:
2 thoughts on “SBS 2011 to Microsoft 365 migration”
Thanks for the article!
This deals with the exchange part of sbs. Do you write about / offer tools to help with moving files to SharePoint and whatever is involved to use AAD to replace the domain controller of the on site sbs box?
Ie being able to not have any server on site (especially now as ‘on site’ could be gone with everyone working from home / no office anymore for small businesses)
I have two situations with sbs 2011 being way past due for replacement, wanting to move completely to the cloud and not knowing how to do it.
Well, email in both cases are already on exchange online. So ‘just’ files and domain admin to deal with.
I haven’t worked with SharePoint. Hoping for a close to similar to ‘s drive’ way to access files.
And AAD – some question if that’s needed in small domains.
Pc password and email password won’t stay in synch. AAD doesn’t give you login scripts, shared printers or group policy, right?
Got these small clients and my ignorance, the last 2 aren’t being used in my cases -other than group policy that’s configured in sbs.
Add your custom domain to the cloud (This Microsoft’s article explains how to do it). If you have already migrated Exchange Online, go to Exchange Online Admin Center to make sure that all permissions are up to date.
When it comes to files, SharePoint Online might be the best destination for your on-site data.
AAD is an integral part of Microsoft 365 & Exchange Online, even in small domains you need your users to have some kind of identity.
When it comes to synchronizing credentials and Group Policies, take a look at Azure AD DS, described in this Microsoft’s article.
CodeTwo sp. z o.o. sp. k. is a controller of your personal data.