Numerous organizations around the globe still use Exchange 2003. The reasons for that are various – after 10 years on the market, administrators know the program inside out, server machines were powerful enough to suit companies’ needs etc. However, ten years in the IT industry is a whole era and much has changed. The explosion of mobile devices that are accessing Exchange mailboxes directly, the Cloud, the release of MS Exchange 2013 and many other factors are making the 2003 version obsolete. Not to mention that in 2014 Microsoft terminates technical support – no more patches, updates and security fixes for Exchange 2003. These reasons are pushing many administrators to consider migrating to more modern solutions, such as Exchange 2013. The sad fact is that Microsoft provides no way to migrate/upgrade Exchange 2003 directly to 2013 at this moment. It doesn’t mean, however, you are left with no options if you would like to move straight to the newest version of Microsoft’s email platform. There are several solutions you can consider. The first one is the “double hop” migration. Drawbacks of double hop migration Exchange 2003 and Exchange 2013 can’t co-exist in one Active Directory forest. On the other hand, moving users’ mailbox data between two different forests is complicated when you want to use only native migration tools. We can complaint about Microsoft’s policy on that matter but it will still remain a fact. Currently there is no native path to make an intra-organizational upgrade from Exchange 2003 to Exchange 2013. For that reason many system engineers recommend to split the process into two steps: First upgrade Exchange 2003 to 2010 version and then migrate to Exchange 2013. This method is called the double-hop migration, which obviously doubles the work required and the risk of the process going awry. It also requires some important resources, like spare hardware (if you have it), or putting up additional virtual machines only to host the temporary environment before moving it to the target location. The entire operation must be planned and done with maximum care, in order to reduce the downtime of mail servers. Will you take that risk? Export/Import PST – good idea? If you operate on a small amount of users working on PST files during the migration can work for you in a way. However, the thing might not be as simple as it seems. Not to mention the fact that the manual export/import operation between the two versions of Exchange might be a bit of time consuming, you might face some other problems which will make the whole process even longer to complete than you initially thought. The first issue is connected with legacyExchangeDN X.500 address that will have to be manually added to each re-imported mailbox as proxy address in the target location. If you don’t do that right after re-creating the mailboxes in Exchange 2013, your users will not be able to use their email in a normal way. The solution to that is quite simple, but obviously it adds some extra work to the entire migration process and carries a risk of longer service unavailability during the migration. You will find more information on that topic here. You can also use this article as a guide. The steps described in it can be used with an on-premises installation of Exchange 2013 as well. Another important problem to consider while using the export/import PST option are public folders, if you use them. Re-importing them in th

The word “Migration” changes its connotation. Nowadays, instead of bringing the image of caribou or wild geese traveling vast areas, it brings the image of moving data from one system to another. When the server administrator hears “Migration”, he usually thinks “Exchange”. Exchange Server is one of (if not the most) important systems in today’s company. Without it the business operation stands still – no messages are sent or received, collaboration tools, such as Public Folders, are not working, chaos is growing. That is why system administrators are so cautious with any programmatic changes made on their servers. Each Microsoft update installation, each configuration change is performed with maximum caution to minimize the risk.  “The more complex the system, the bigger chance of its failure and the harder way of fixing it” - from Murphy’s law One would think that Exchange migration is nothing more than copying mailboxes and users from one server to another. Well, it is far from it. The built in features of the Microsoft program make the process complex and multi-staged. E.g. migrating from Exchange 2003 to 2010 takes a number of steps, and each is quite a process all by its own: Enable Exchange Native Mode for your exchange organization. If not yet performed - install Service Pack 2 on all machines with Exchange 2003. Raise the functional level of the AD forest/domains to Windows Server 2003. On the machine that will contain Exchange 2010 install Windows Server 2008 R2 x64. Install any necessary prerequisites (e.g. LDIFDE tools for schema upgrade). Launch Exchange 2010 setup and upgrade the schema, prepare the forest and domains. Install CAS server role. Move traffic from OWA, ActiveSync etc. to new CAS server. Hub Transport role installation. Redirect all mail traffic to the new Hub Transport. Install Mailbox server roles and configure Databases. Prepare public folder structure on Exchange 2010 to accommodate current 2003 public folder structure. Move mailboxes to the new Exchange Server 2010 using Powershell. Designate Exchange Server 2010 as Offline Address Book base. Designate Exchange Server 2010 as Public Folders base. Transfer Public Folder to Exchange Server 2010. Of course the above list is not the end of the story – administrator also has to plan how long the old 2003 setup is left as a backup structure, in case the new system fails, when and how to decommission the old server, what to do with 2003 databases backups etc. Additionally, when moving between two different forests, the process is even more troublesome and requires enabling the trust between two structures, which is not always possible. Without the trust enabled the migration complicates significantly - the mailbox database has to be exported and imported as raw data. The export tool used for mailboxes does not work for public folders so they need to be moved via PST between Outlooks, which just adds the trouble. Moreover, all the permissions from 2003 are also lost, so they need rejiggering on the target system. Since the 2013 version of Exchange Server is the latest, now many organizations are considering it as the migration target. However, the process for Exchange 2003 users is painful – it is called Staged Migration. Behind a nice name, it is nothing more than a two-step task: first migrate from 2003 to Exchange 2010. Then move from 2010 to 2013. Considering the list mentione