Exchange is generally one of the first Microsoft workloads that SMB customers move to the cloud, and usually through a hosted option such as Office 365's Exchange Online offering. Migrating to another hosted Exchange provider is also something that many SMBs have taken advantage of in the past, but with the additional value that Office 365 provides it may be worth revisiting the customer usage requirements.
Exchange Online
One of the best options for migrating Exchange Server off Windows Server 2003/R2 is Office 365, a cloud-based service designed to meet organizational needs for robust security, reliability, and user productivity. Office 365 Exchange Online, the Microsoft-hosted messaging service in the cloud that follows Exchange best practices, will likely provide the fastest and easiest option for your migration. It will reduce your planning costs and may lead to overall cost savings because of savings in hardware capital expenditures and ongoing operations costs. You will also need to ensure you have well designed connectivity for your infrastructure if you are running a hybrid cloud and on-premises architecture.
Technologies involved with this solution:
Upgrade on new hardware
The current version of Exchange Server is Exchange Server 2013 SP1, and significant advances in performance, reliability, and manageability have been developed over the years. Exchange Server 2013 SP1 runs on Windows Server 2012 R2.
You will need to consider which version of Exchange Server you have on Windows Server 2003/R2. The following list shows migration paths:
- Exchange Server 2000: Upgrade to Exchange Server 2007 SP3 RU10, and then migrate to Exchange Server 2013
- Exchange Server 2003: Upgrade to Exchange Server 2010 SP3 CU2, and then migrate to Exchange Server 2013
- Exchange Server 2007: Upgrade to SP3 CU2, and then migrate to Exchange Server 2013
You will likely need to purchase new hardware to run Exchange Server 2013 SP1 and Windows Server 2012 R2.
Virtualizing Exchange Server
You can use a virtualization environment to run all Exchange Server 2013 or 2010 server roles. Consider the following guidelines when virtualizing Exchange Server:
- Use standard server sizing. From an application perspective, running Exchange Server on a guest virtual machine does not change the Exchange Server design requirements. The guest virtual machine must be the appropriate size to handle the workload.
- Configure appropriate storage. The storage used by the Exchange Server virtual machine can be fixed VHD drives, SCSI pass-through storage, or iSCSI storage. As with SQL Server–based servers, pass-through storage provides the best performance. Dynamically expanding virtual disks and differencing drives are not supported for Exchange Server servers.
- Use separate logical unit numbers (LUNs). You should use separate LUNs on RAID arrays for the host operating system, each guest operating system disk, and all virtual machine storage. You should create separate LUNs for each database and set of transaction log files, as you would when working with physical servers.
- Configure adequate CPU resources. Exchange Server supports a ratio of virtual processors to logical processors that is no greater than 2:1. For example, a dual-processor system that uses quad core processors contains eight logical processors in the host system. On a system with this configuration, do not allocate more than 16 virtual processors to all guest virtual machines combined.
- Choose the appropriate high availability solution. There are several options for high availability with Exchange Server. You can combine virtualization-based solutions (like Live Migration) with product-specific solutions (like Database Availability Groups). However, in most cases, we recommend that you use the Exchange Server solutions themselves. Virtualization solutions are not application-aware, while Exchange Server solutions are. For example, servers running Exchange Server can detect when a single database dismounts and can mount that database automatically on another server. Hyper-V Live Migration cannot detect the status of individual databases or other services.
- Consider mailbox server performance. The most common performance issues for mailbox servers are disk I/O and network I/O. Running mailbox servers in a virtual environment means that the virtual machines must share I/O bandwidth with the host computer and with other virtual machine servers deployed on the same host. If a single virtual machine is running on the physical server, the disk I/O and network I/O available to the virtual machine are almost equivalent to the I/O available to a physical server. However, a heavily utilized mailbox server can consume all available I/O bandwidth, which makes it impractical to host additional virtual machines on that physical server.
For more information, go to https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx.