Now that Microsoft has released Exchange 2010, Exchange administrators across the planet can start evaluating the new version for possible implementation. Does the new version offer enough benefits to go through an upgrade? I cannot answer that question for your organization, but I can outline the upgrade and coexistence scenarios that are available for Microsoft's newest entry into the Exchange product line.
If your organization is using an older version of Exchange and you're considering upgrading to Exchange 2010, one of your first considerations must be how to deploy the new version of Exchange. In this regard, Microsoft makes the decision pretty easy. Like the previous version, Exchange 2010 runs only on 64-bit operating systems.
Also like Exchange 2007, Microsoft does not allow an in-place upgrade of your existing Exchange system to the newest version of Exchange; that is, if you want to move from Exchange 2007 to Exchange 2010, you need to perform what Microsoft calls a transition, which is a move to new hardware (or virtual machines). Although the same was true for a move from Exchange 2003 to Exchange 2007, back then, there were very different reasons that made a lot of sense; for instance, Exchange 2003 was 32-bit only, and Exchange 2007 was 64-bit only.
In the case of Exchange 2007 to Exchange 2010, Microsoft has indicated that the sheer number of database changes between Exchange 2007 and Exchange 2010 helped the company decide that a transition was the only upgrade option. From a support perspective, not allowing an in-place upgrade will probably mean a lot fewer failed implementations, and the requirement to transition rather than upgrade gives organizations a built-in fallback in the event that something goes awry during an upgrade. But if your organization recently shelled out a lot of money for new Exchange hardware, the need to buy more hardware may not sit well.
At some point during the Exchange 2010 beta testing, someone must have thought of a way to attempt to circumvent this restriction by trying to mount Exchange 2007 databases on an Exchange 2010 server, as many sources explicitly indicate that this, too, is unsupported and will not work. Again, this is due to the fact that there are a number of database schema changes between the two versions.
Moving to Exchange 2010 is not an all-or-nothing proposition, though; it's possible for Exchange 2010 to run side-by-side with other Exchange servers — Microsoft refers to this as coexistence. As you might expect, Exchange 2010 is picky about the versions of Exchange with which it will coexist. In short, only organizations already running Exchange 2007 will be able to install Exchange 2010 and expect coexistence to work. Exchange 2010 can coexist with a native Exchange 2007 system, with a combined Exchange 2003 and Exchange 2007 system, or with native mode Exchange 2003 servers.
Exchange 2000 is not supported at all in conjunction with Exchange 2010. If you are running Exchange 2000, you need to move to at least Exchange 2003 before you can think about Exchange 2010.
In order to support coexistence with Exchange 2010, your existing Exchange 2003 and Exchange 2007 systems must be running their respective service pack 2 releases.
More Exchange 2010 resources on TechRepublic
- Preparing for Exchange Server 2010's hardware and software requirements
- Top 10 new features in Exchange Server 2010
- Reduce hardware needs and ease administration with Exchange 2010
- What to expect from Exchange 2010: Not much backward-compatibility
- A crash course in the Exchange 2010 Control Panel
Want to keep up with Scott Lowe's posts on TechRepublic?
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at email@example.com.