Now is the right time to consider migrating to a new version of Exchange. If you are running Exchange 2007 or 2010 it is now in extended support, and you need to consider your options.
What are your options?
There are currently three versions of Exchange Server under current support, with a new version coming out soon.
Exchange 2007 and 2010 are both legacy versions of Exchange and provide the basis of modern features used in modern Exchange, such as Powershell management and Continuous replication.
Exchange 2013 is now nearly three years old and has proved very stable. Exchange 2016 is due for release soon and builds upon the reliability improvements in Exchange 2013 combined with the great new features first deployed into the cloud.
Exchange Online is delivered by Microsoft as part of their hosted solution, Office 365. This is always running the latest version of Exchange and although you perform day-to-day user and mailbox administration, Microsoft manage the server-side for you.
Which version of Exchange should you migrate to
Because Exchange 2007 and 2010 are both in extended support these versions should not be considered unless you have a dependency, such as a legacy application. By implementing either of these versions you can expect to need to upgrade again in the near future. Exchange 2007 in particular is unwise as it does not provide a direct migration route to Exchange 2016.
If you are planning on migrating to Exchange now, and want the best compatibility with third-party applications, then Exchange 2013 is a good option. It provides a great path to upgrade from Exchange 2007 and 2010, and also ensures a future migration to Exchange 2016 will be straightforward.
Those running Exchange 2010 and willing to wait a few months should consider Exchange 2016. This new version of Exchange owes heavily to Exchange 2013 and shares more than a passing resemblance. However it provides a much greater range of user-facing features such as a vastly improved Outlook on the web experience.
If a migration to a new version of on-premises worries you, then a move to Exchange Online, hosted by Microsoft in Office 365 might be a better option. Microsoft run this in their datacenters and you never need to upgrade it again in-house.
Key factors and pain points to consider
Choosing the version of Exchange to migrate to isn’t as simple as picking the one that has all the features you want. There is a long list of factors you need to consider before deciding on the version of Exchange that suits you.
Firstly, what version of Exchange are you migrating from? If you are currently running Exchange 2003, then you need a double-hop to Exchange 2010 before moving to Exchange 2013 or higher. This means potentially twice the hardware is required. It is a similar story for those running on Exchange 2007. The migration path to Exchange 2013 is straightforward, but a move to Exchange 2016 requires a double-hop to Exchange 2013 first. Although the simplicity of a migration shouldn’t be a deciding factor, if budget and timescales are the deciding factor then a complex and costly migration process could help you decide on the version of Exchange most suited to you.
The desktop office client in use can also have a bearing on which version of Exchange you can migrate to. If you are running on Office 2007 and are not ready to upgrade or purchase licencing for newer versions, then you will be limited to migrating to Exchange 2013 rather than Exchange 2016. Conversely, if you are planning on deploying Office 2016 when it is released, then you will need to be running Exchange 2010 or higher.
Third party application integration for line-of-business applications is often a stumbling block in Exchange and Office 365 migrations. Often organizations do not adequately check or test the third-party applications in use across the organization. These may be server-side integrations or client-side integrations. Applications that rely on the MAPI/CDO library must be compatible with the latest version of the library for compatibility with Exchange 2013, and will not work at all with Exchange 2016.
Backup software support for Exchange often lags far behind the release of the latest version of Exchange. If you are deploying the preferred architecture, then backups are not a worry but if you are deploying a traditional infrastructure that is backed up regularly you will need Exchange-aware backup tools. These must integrate with Windows and quiesce the filesystem during backups, then after a successful backup has taken place, expunge log files that are no longer needed. In a multi-node cluster that uses Database Availability Groups the database could be running on multiple nodes. Restores often need deep integration to ensure it is easy for an administrator to restore data into a user mailbox. Because of this deep integration it often takes a long time for the backup vendors to support a new version of Exchange, and might even require a full upgrade of the backup system.
If you are using existing hardware, such as a virtual infrastructure you may have limited resources available. Exchange 2013 and Exchange 2016 use considerably more CPU and RAM resources than previous versions and you may struggle to accommodate either alongside existing virtual machines. However, you might find a purchase of additional RAM or an additional virtual host a better investment in the long term than implementing a legacy version of Exchange.
Those planning a move to Exchange Online must consider third—party application integration and clients – but in addition must consider internet bandwidth and availability. Business-as-usual requirements for Exchange Online are fairly low, potentially less than 10Mb/s for a small 200-user organization. However if you are unable to achieve the required bandwidth, or are using a third-party tool to migrate, and must re-download the offline cache, this could increase your bandwidth requirements in the short term considerably.
Before beginning your migration, perform some assessment to understand what you have. My Exchange Environment Report can assist, and is available from Microsoft’s Technet Gallery:
This will provide a comprehensive report with statistics from your environment. You will also need to understand the message send and receive statistics for your environment. Use the Generate Message Profile script to collate this information:
Before purchasing any hardware, you will need to understand what kit will be required. The Exchange Role Requirements calculator for Exchange 2013 provides this information:
Our final recommended script helps you understand the bandwidth required by clients. The Exchange Bandwidth calculator is especially useful for Exchange Online deployment planning:
Finally, you can create a custom deployment guide using Microsoft’s Exchange Deployment Assistant. This covers Exchange 2010, 2013 and Exchange Online: