Migrating legacy public folders to Exchange 2013/2016

UPDATE: This post was updated on August 11, 2016.

Since the release of Exchange Server 2007 there have been rumors that Exchange public folders are not going to last long in Exchange. Although they are a huge enhancement as far as data sharing and online collaboration are concerned, since the first release of SharePoint Microsoft tried to convince companies to rather use their separate online collaboration platform for data sharing instead. However, over the past releases of Exchange public folders remained and have been even improved. In Exchange 2013/2016 they are not the same public folders anymore. The newest version of Microsoft’s email server introduced a completely new approach to public folders architecture. Separate public folders databases are now gone and public folders have been moved into mailbox databases. This model results in better reliability (mailboxes can be a part of DAG), but also causes some problems in terms of data migration from legacy versions.

Let’s focus on the main difficulties you may encounter while migrating legacy public folders to Exchange 2013/2016 and find out how to migrate them successfully.

Migrating Public Folders from Exchange 2007/2010 to Exchange 2013/2016.

What you need to know

Prior to moving your public folders to Exchange 2013/2016 you should be aware of the following facts:

  1. The public folder database in Exchange 2013/2016 is gone. Public folders are now stored in mailbox databases as mailboxes.
  2. Prior to migrating public folders to Exchange 2013/2016 you need to migrate users’ mailboxes first.
  3. Users using legacy mailboxes, won’t be able to access the new public folders on Exchange 2013/2016.
  4. Legacy public folders and new Exchange 2013/2016 public folders can’t co-exist in one organization.
  5. There’s no native path for migrating Exchange 2003 public folders directly to Exchange 2013/2016. To be able to migrate public folders from Exchange 2003, you need to upgrade to a newer version of Exchange first (2007 or 2010).
  6. To be able to migrate public folders from Exchange 2007 you have to run Exchange Server 2007 SP3 RU10 or later.
  7. To be able to migrate public folders from Exchange 2010 you have to run Exchange Server 2010 SP3 or later.
  8. During the native migration of public folders you will have to lock down public folders on the legacy Exchange Server for the time of migration. Downtime for users can’t be avoided in this case.
  9. Be aware of new public folders limits and quotas.

Having it all in mind, if you plan to migrate public folders from any legacy version to Exchange 2013/2016, you need to prepare the environment properly first.

Migrate public folders from Exchange 2003 to Exchange 2013/2016

This scenario is the most troublesome. Since there’s no coexistence allowed between Exchange 2003 and Exchange 2013/2016, direct migration of any data between these versions, including public folders, is not possible natively. To be able to migrate public folders from Exchange 2003 to Exchange 2013/2016 you need to carry out a so called double-hop migration which involves pre-installing and migrating to Exchange 2007 or Exchange 2010 first.

For obvious reasons this process includes engaging more resources and increases the overall cost of the entire migration project. The only way to shorten the migration path in this scenario is using a third party migration tool, which will be discussed at the end of this article.

Migrate public folders from Exchange 2007/2010 to Exchange 2013/2016

This scenario has already been covered on our blog recently. The main point that needs to be noticed are the prerequisites. As mentioned before, you need to have Exchange Server 2007 SP3 RU10 (or later) onboard to be able to migrate public folders from Exchange 2007 and Exchange Server 2010 SP3 (or later) to perform a migration from Exchange 2010. Also, before running the migration scripts all users mailboxes need to be moved to Exchange 2013/2016.

A detailed instruction on how to move public folders from Exchange 2007 and 2010 to Exchange 2013, can be found on this TechNet site. For Exchange 2016, visit this TechNet website.

Although the migration scripts are available for download in Microsoft download center, fiddling around with scripts and preparing CSV mapping files is not something that makes the whole process the easiest to perform. What’s more, the process involves locking down public folders for some time, which obviously affects the workflow of users heavily and is not desired in many companies.

To eliminate those inconveniences you can still use a third party migration tool called CodeTwo Exchange Migration that doesn’t require installing specific service packs or updates on the legacy servers. It also allows to migrate public folders while users are still using them. Let’s get down to details then.

Overcoming the limits of native public folders migration

To avoid all the limitations of the above mentioned paths, you can use CodeTwo Exchange Migration for migrating public folders from a legacy version of Exchange to Exchange 2013/2016. The list of supported migration scenarios for this program can be found here.

The program will let you easily migrate Exchange public folders without the need of running any scripts and preparing any CSV files. The entire process can be performed using the program’s user interface.

Dashboard CodeTwo Exchange Migration

Because CodeTwo Exchange Migration uses a EWS connection between the source and target server, you can easily perform a cross-forest migration of public folders. This scenario can be used as a workaround in case of migration from Exchange 2003. If you don’t want to, or simply can’t perform a “double hop”, the program can help you migrate public folders in one step.

The only three general migration steps here, would include:

  • Creating a mailbox (or mailboxes) for public folders in the target location,
  • Configuring the program to migrate the contents of the legacy public folders to the destination server,
  • Switching the mail flow to the new server after data is copied.

Note that the process of copying data between servers doesn’t require you to lock down the access to public folders at any point. If you wonder how the differences between the newly migrated items and the ones that appeared in folders after the migration finished are handled, take a look at the rescan feature. This option will let you run a delta migration just before making the final switch to the new installation of Exchange and eliminate the differences in folders contents.

Rescan option in CodeTwo Exchange Migration

Owing to the fact that CodeTwo Exchange Migration is a 100% GUI based migration tool, there’s no need to fiddle around with scripts and CSV files in the case of migration from Exchange 2007 and 2010 anymore. In fact, the only preparation that needs to be done here is the creation of empty public folders in the target location. The structure of its contents (subfolders) will he handled by the program itself.

Apart from the above mentioned gains, the program offers some other useful benefits, which help the administrator to handle the entire migration project. Those benefits include:

  • Built-in migration scheduler
  • Connection wizards and pre-configuration checklist
  • The automatch of source and target mailboxes
  • Reporting features
  • Pause/resume option

Testing the software

If you still haven’t found out which path to choose, take some time and consider the pros and cons of the above mentioned methods. If you would like to test CodeTwo Exchange Migration for your migration project simply download the free trial. It will let you test the migration with a limited number of items.

More about CodeTwo Exchange Migration
See the list of supported scenarios

Migrating legacy public folders to Exchange 2013/2016 by

Leave a Reply

Your email address will not be published.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>