There's an old saying that goes, "Exchange ain't done, until Service Pack 1." The idea comes from a history of Exchange Server releases where a perception was formed that the RTM version lacked features, stability, or had bugs that made it unsuitable for production deployments. Waiting for the first service pack’s release was the conservative approach taken by many organizations, on the basis that by the time SP1 hit, most of the bugs would be fixed and the missing features would have been added to the product.

There may be some element of truth to that, as Exchange Server often ships at RTM with new features planned for later updates, but waiting for a future release as a guarantee of quality is not a sound strategy. The fact is, software has bugs. Even well tested software like Exchange Server, which hosts millions of mailboxes in Exchange Online, will have bugs that appear from time to time. The bugs might be widespread issues that impact the majority of customers, or they might be specific to just a few types of Exchange environments.

Updates are important so that your environment remains supported. Microsoft has an N-1 support policy for Exchange Server 2016, meaning it will support the latest build and the one release prior to that. Anything older is considered unsupported, especially if you’re running a Hybrid configuration with Office 365.

Putting aside the fact that there is no Service Pack 1 planned for Exchange 2016 (only Cumulative Updates), a sensible approach is to test new releases before deploying them. Good testing involves not just installing the software to see whether it breaks, but also testing things that are unique or important to your environment, such as integration with business applications or third-party add-ons. Using testing to balance the risk of updates with the need to stay supported is the best approach in the long term.

Some commentators have referred to Exchange 2016 as "Exchange 2013 Service Pack 2." At face value, Exchange 2016 is not the big leap forward that previous versions of Exchange were, such as Exchange 2007's move to 64-bit and PowerShell-based administration, or Exchange 2010's introduction of the database availability group.

But that doesn't mean there are no new features. Exchange 2016 shipped with enough compelling reasons to look at upgrading immediately, such as the new Outlook on the web interface, faster database failovers, faster search performance, eDiscovery improvements, Office Online Server integration and simpler Exchange server role architecture.

Not only that, but Exchange 2016 is where you can expect more new features to appear over time. For example, Exchange 2016 has already received improvements to lagged database copies in Cumulative Update 1. Exchange 2016 will be receiving other new features such as auto-expanding archive mailboxes, and search indexing from passive database copies (which improves performance in database availability groups).

Simply put, beginning your migration to Exchange 2016 now means you can incrementally receive new features as they’re released in cumulative updates over time.

With previous versions of Exchange, the upgrade path was sometimes considered complex and created a dependency on the new version of Exchange to "front end" the existing servers. This means that the new version of Exchange needs to be deployed in a topology that’s immediately as resilient and highly available as the existing server deployment.

For Exchange 2010 this is still true, but Exchange 2013 customers have good news. Exchange 2013 can "front end" an Exchange 2016 server, making it possible for customers to deploy just a single Exchange 2016 server into an Exchange 2013 environment for testing purposes, without the new server needing to have a critical role in the uptime of the environment as a whole.

This makes it far less complex and disruptive for Exchange 2013 customers to deploy, test, and then migrate to Exchange 2016.

A persistent myth with Exchange Server is that it can't be virtualized, or that virtualization is unsupported. In fact, virtualization has been supported since Exchange 2007 Service Pack 1.

It’s true that Microsoft recommends deploying Exchange on physical hardware, and says as much in its Preferred Architecture guidance for Exchange 2016. The primary reason is that virtualization adds complexity to the environment, as well as extra behaviors and recovery actions during fault scenarios, which goes against the core principles of Exchange design; reduced complexity and predictable failure behaviour.

Virtualizing Exchange 2016 is supported and, frankly, virtualizing Exchange is more common than physical hardware deployments. Microsoft publishes guidance for virtualizing Exchange in a supported way, which deals with important details such as resource over-commitment and storage protocols, and which any customer should follow when choosing to virtualize their Exchange 2016 deployment.

With the growth of cloud services, particularly Office 365, many people have been assuming that we'll see the end of on-premises software from Microsoft very soon.

The fact is that Microsoft has publicly stated that it will produce an on-premises Exchange Server product as long as there is demand for one. It's reasonable to expect that sufficient demand will exist for a long time yet, because there will always be organizations that are unwilling, or unable, to migrate workloads to the cloud. Whether the company continues the three-yearly releases of a new version of Exchange, or switches to a continuous process of cumulative updates instead, remains to be seen.

What we can say with certainty today is that Microsoft commits to a full product support lifecycle when it releases a product. For Exchange 2016 this includes extended support all the way to the year 2025. As you can see, it’s probably safe to say that deploying Exchange 2016 creates no risk of Microsoft pulling the rug from under your feet.

Learn more about Exchange Server 2016 with this course.