This post may be late in coming, given that most smaller companies have already moved away from on-prem solutions to cloud based services for things like email and file sharing, but I feel like it’s important to stress some of the realities involved in migrating from on-prem to cloud systems. Particularly when migrating to Office 365.
What I would like to point out is simple: Third party utilities are often not necessary. This is especially true with migrating. This is not to say that third party tools like BitTitan’s MigrationWiz, CodeTwo, and SkyKick are not useful. They are, for certain scenarios. What I am stressing here and have stressed over and over in posts here is that the Cost of a solution must outweigh the Benefit of a solution before it is used. In most cases of Office 365 migration, particularly email migration, this is not true.
Microsoft provides a lot of tools for getting businesses onto their system. These tools are extremely capable and there are very few reasons to avoid using them. Below is a simple explanation of how you would migrate from various systems to Office 365.
| From Exchange Server | From Google Apps/Mail | From IMAP/POP3 eMail | From Office 365 | |
|---|---|---|---|---|
| To Office 365 | Use Hybrid Move Method | Use 3rd party tools | Use IMAP Migration | Use 3rd Party Tools |
There are 4 basic scenarios for migrating to Office 365. And before anyone comments that there are more mail systems than these, yes, that is true, but there are not many that change the above and as far as I know, all other mail systems (Domino, Zimbra, etc) either require 3rd party tools or complicated manual migration processes. I should also point out that the above matrix table is applicable when you want to migrate calendar, personal contacts, and other information as well as email. The reason for this is that there is no existing standard for effectively sharing and maintaining those functions. IMAP and POP3 are email only solutions that require custom back-end database or file functions to actually store email, so if you don’t care about calendar information, you can use IMAP migration for each scenario if you choose.
Also note that migration to G-Suite can be accomplished with Google’s own migration service. Google has built tools that handle the vast majority of migration cases (with possible exception of calendaring features for IMAP/POP3 environments that do that as well), so the matrix is the same no matter what. I am excluding the possibility of migrating to IMAP/POP3 systems because I simply recommend against doing that. Ever.
Moving from G-Suite/GMail to Office 365 and Office 365 to Office 365 (Also known as a tenant to tenant) migrations are the only common situations where third party tools are required. For G-Suite, third party tools are necessary to migrate information that is not email. If all you want to migrate is email, you can get away with an IMAP migration, but any other information needs to use third party tools to migrate unless you want to spend hours manually migrating data. The benefit here usually outweighs the cost because it takes one to two hours per user to manually migrate data from Google’s systems due to the need to export, copy, and import data between. Tenant to tenant requires third party tools because of how Office 365 is built. Office 365’s email portion, also known as Exchange Online, has every customer/tenant on what equates to a single Exchange Server back-end. The core programing of that back end prevents an email domain from existing in two tenants at the same time, and that’s just the simplest problem to deal with. It is possible to do a tenant to tenant migration without third party tools, but doing so is very complicated and it’s easy to screw it up. It’s also very time consuming. Third party tools greatly simplify this migration type by automating most of the configuration and tasks required to complete such a migration and effectively act as a virtualized hybrid setup between two Office 365 tenants.
So there you have it. There are limited reasons to use third party tools, but in the situations where they are justified, they can provide immense time savings and are extremely useful. You are, of course, free to make your own choices about how to handle migrations, just realize that the worst person to get your information about need from is a salesman for a company that develops migration tools. They will probably tell you that you need them for every situation when that is simply not true.
