Updated: Feb 3
It's easy to misjudge the size and complexity of migrating to Microsoft 365, and specifically Exchange Online. There are many factors to be aware of that can impact the final cost of the migration when you're evaluating your service providers and planning your project budget. Here are 8 factors that can drive up the cost of a migration project:
1. Number of Mailboxes
The number of mailboxes subject to migration will definitely impact migration. However, it may not be in the way you think.
Most Cloud migrations are actually cheaper per mailbox as the number of mailboxes increases. That's because there is economy at scale here. Basic tasks that are part of the migration, such as setting up your identity sync (if used), setting up your destination tenant, obtaining all the admin credentials required to perform the migration tasks (such as to your DNS), all need to happen. These preparatory tasks are required whether you're migrating one mailbox or 100.
Once the migration begins though, the data transfer process doesn't much care. It's automated, and it happens fairly quickly. Sure, there is the matter of total volume of data and transfer rates, but the migration process is not much different at scale.
Caveat: for much larger migrations, such as enterprise environments with thousands of accounts, special consideration are required. Some of these considerations are discussed below.
2. Where You're Migrating From
Yes, where you're migrating from matters. Different migration source requires different planning and considerations, and accounting for anomalies costs time and money.
For example, one client environment was solely on Webmail. The way their environment was setup however, the client (and their IT admins) didn't have access to the email admin panel. This meant that any preparation tasks needed involvement from their Internet Service Provider (ISP) who was their email host admin. The coordination required extra time and effort, which meant a higher migration cost.
Another example is if you're migrating from an older on-premises Exchange server. You might need to upgrade your Exchange server to a later, and compatible version first before you can begin migrating to Exchange Online.
3. The Number of Email Domains
If you have multiple email domains, considerations need to be in place to account for the multiple user identities. Can your users be merged? Is there any special consideration to resolve duplicate accounts? Should the accounts remain separate?
Multiple email domains can be very simple (just add your additional email domains and call it a day), or it can be very complex - involving considerations in privacy, compliance, and other legislative governance processes.
On top of that, there are licensing implications. You and your service provider will have to account for the extra planning that goes into a multi-domain migration.
4. Identity Integration
Identity integration is also a major consideration. As we briefly touched on above, if you have multiple domains, are there any duplicate accounts that need to be resolved?
If you're migrating from on-premises, where will your identity source be? Do you require Azure AD Connect to be set up to synchronize your user identities? Will your on-premise identity provider be decommissioned as part of the email migration? These are all things that need to go into your project planning and cost considerations.
5. Environment Health
It should come as no surprise that your overall IT environment health is a huge component of your migration cost considerations.
Any time there is a problem during a project, remediation effort is required to resolve it. This means if your environment had problems to begin with, it's not as simple as sticking your head in the sand, slapping your email onto a new provider and hoping all your existing problems will go away after the migration. Unless the migration effort was specifically scoped to address some of your technology challenges, rarely can you simply ignore existing problems.
Another issue that we've seen is when an over-eager client purchased their license, provisioned their AAD tenant and began playing with the new Cloud environment before any sort of migration planning had begun. Normally, I am all for clients playing in their environment - check out any features and functions that they may find useful for their business. However, in this instance, the client had enabled To-Do and began using its functionalities extensively. Unbeknownst to the client, To-Do is very heavily intertwined with Exchange, and it became a problem when they needed to synchronize their user identities from on-premises. There was no way to actually merge the data from the two accounts without manually exporting the data, deleting the account, and then reimporting it.
All this is to say, there is always a potential for problems in your IT environment, whether you are aware of them or not. Some remediation tasks are easier than others, and your service provider should account for potential problems in their scope of work.
6. Whether or not Downtime is Acceptable
For most companies, email is critical infrastructure which means zero-downtime for email migration is expected. As with any IT systems, any time that zero-downtime, or near zero-downtime is expected during a migration task, processes and planning need to be in place to provide for this. This may mean the migration techs will need to work after-hours or during holidays. Depending on how your project is priced, this may increase your costs.
When you receive your project estimate, especially if it's an hourly billing, check to see if there is an addition cost for work performed outside of standard business hours.
7. Migration Timing
Let's talk a bit about timing: Do you want a cut-over migration? Or do you want the migration to happen over several months, or longer?
Typically, mailbox migrations happen as a cut-over, meaning mail is stopped at your old destination and started at your new destination. The reason for this is that MX records for your domain (the thing that tells the internet where to deliver your mail) can only point to one destination.
But, depending on how many mailboxes you have, it may not be realistic from a business point of view to cut over thousands of users in one evening: perhaps it's the sheer volume of data that needs to be transported, or technical administrative work that needs to be done, or a business impact perspective.
For example, if you have Exchange on-premises, Exchange-hybrid can be supported to extend your migration timeline. (We're not going to get into the use of smart-hosts and how it's still technically a "cut-over"). A hybrid migration is the recommended method by Microsoft for large volumes of mailboxes, but it introduces complexity into the project and into the environment that will need to be accounted for in the project time and cost.
Believe it or not, your organization could be a factor in driving up the cost of an Exchange migration project. How?
Any proper project estimate need to account for project management and change management. This means, keeping all project stakeholders apprised of the changes forthcoming. Depending on your environment, this could have a bigger impact on the cost than you think.
For example, if you have a environment where everything needs to be decided by a committee or the Board, this could impact your project timeline and cost. Composing follow-up emails, scheduling and attending project meetings, writing project reports all take time. And time is money.
You can help reduce the cost on this front by being highly responsive, and by taking responsibility for all your internal communications instead of needing your IT Professionals to chase and follow up.
Dangers of Low Price Estimates
So as you can see, estimating an Exchange migration cost isn't exactly straightforward. Many of the pricing you will see online for "per-mailbox" migration is simply the cost of licensing a migration tool. This doesn't include any project management, change management, or other migration planning tasks. The expectation is that you will use the tool and perform the migration yourself, with little to no support. This may be perfectly fine if you're savvy with mail servers, domain identities, and business processes to manage all the demands of a migration tasks.
A low price estimate is always attractive for any business owner. You know how to stretch a dollar and you want everything you want. However, the saying of "you get what you pay for" generally rings true. If your migration cost seems low, make sure to read your project proposal carefully, find potential hidden costs that may overrun your initial project budget, and ask questions.
Sometimes, costs are disguised with a low initial estimate and frequent Change Requests. This isn't inherently problematic as long as you're aware of when a Change Request may be issued, and what was originally in your scope of work. Do be aware though, Change Requests, especially if your internal project budget approval process is onerous, most likely will extend your project timeline. So if your project is time sensitive, try to get everything included and approved upfront.