Don't use Exchange Server Database Portability as a Migration Method

Database portability is a feature of Exchange Server that exists in Exchange 2007, Exchange 2010, Exchange 2013 and again in Exchange 2016. In short, database portability allows an Exchange Server mailbox database to be moved or mounted on another mailbox server within the same organization.

Database portability (or database mobility) is one of the developments in Exchange that makes database availability groups possible. It’s also super useful for disaster recovery situations, such as when a server fails, because it may be quicker in some cases to mount a database on another server instead of waiting for the failed server to be repaired and brought back online. Microsoft calls out this benefit in their TechNet documentation:

By using database portability, reliability is improved by removing several error-prone, manual steps from the recovery processes. In addition, database portability reduces the overall recovery times for various failure scenarios.

What database portability shouldn’t be used for is migrating the entire contents of a database from one server to another. I’ve had customers ask for this in the past, and told them it’s not a good idea. Here’s a simple rule I follow:

Database portability is a disaster recovery capability, mailbox moves are a migration capability.

In other words, don’t use a DR feature to migrate data. If you’re not convinced, let’s compare the two processes.

First, database portability involves:

1. Dismounting the database (begins an outage for your users)
2. Manually copying the database and log files to another server (difficult to estimate duration, will depend on amount of data, speed of network, speed of disks)
3. Possible need to perform soft recovery for the database
4. Create database on new server and mount using the copied files
5. Update mailbox attributes of affected users (and then wait for Active Directory replication, this is the end of the outage for users)
6. Re-submit queued messages

During that database portability process there’s a lengthy outage, all manual steps, no error handling, broad impact (all mailbox users for the database at the same time), and no roll back (if you mount the database and re-submit queued messages, then you spot a problem, you can’t just dismount and go back to the old database).

In comparison, mailbox moves involve:

1. Creating move requests or batches
2. Waiting for the moves to process (no user impact yet)
3. Scheduling a completion time for the final cutover (brief outage per user, possible Active Directory replication delay)

During the mailbox migration there’s no disruption for the end user until the brief outage during final cutover, the mailbox data is moved automatically for you, the mailbox moves have error handling and statistics reporting, no need to manually re-submit queued messages after the final cutover, and you can control the impact on a per-mailbox basis.

Here’s some responses that I get from customers and other Exchange admins when I have this conversation with them:

• But database portability is quicker! Maybe, but you’re increasing risk and end user impact for your own convenience, and that’s not a good thing if you ask me.
• But our server is about to crash! If that’s a bigger risk than the impact of using database portability, then maybe you can justify it.
• But mailbox moves create a lot of transaction logs! Yes. Run backups if you need to truncate them, or manage your batch sizes over a period of days/weeks so that you don’t fill up the log volume.
• But it worked out okay last time I did it! Sure. I’ve survived a lot of unwise decisions throughout my life. That doesn’t make them any wiser.

Hopefully at this stage you’re convinced that database portability is not a sensible method for migrating data between two Exchange servers. If you see advice online telling you otherwise, then you should disregard what that person has written.