Stub elimination: before or after archive migration?

Your organization has decided that it is time. It could be time to deprecate your legacy archive environment. Perhaps it’s simply time to change the underlying storage, going to whole new servers and new infrastructure. Maybe you’re joining the masses and making the move to a cloud environment.

Leadership has a checklist of what needs to move. Mailboxes are a top priority, of course. But what’s that? It’s the barely audible voices of legacy archive admins struggling to be heard. In most organizations, it’s rare that archiving systems are prioritized alongside their mailbox counterparts, even though it’s an important storage repository.

Acknowledged or not, your environment’s mail archives and associated ‘stubs’ need to be migrated to ensure continuity of user experience and to avoid business disruption. So, the question quickly becomes, how? Typically, one of the first options evaluated is rehydrating mail stubs within the source environment and migrating the rehydrated data with the mailbox migration. The following post will explore this as a migration approach and discuss its various benefits and challenges.

What is a ‘Stub’?

A ‘Stub’ or ‘shortcut’ is created when a third party archival solution takes a large item in Exchange and replaces it with a smaller pointer object or ‘stub’ and the original item is stored in an external repository.  They are used in legacy mailbox archiving solutions as a means to provide a seamless end user experience between the user mailbox and the archive. A stub provides the look, feel, and usability of a standard object within Outlook.

How should you handle stubs when migrating your archive?

When initially considering a migration, you face the following question: should you rehydrate the stub on the source environment from which they came, or address them in the destination environment and migrate them independent of your mailboxes?

Before you can make a decision, there are some important questions to consider, including:

• What stub approach has the best performance?
• Are there sufficient resources available to restore the content from its original location?
• What is the level of effort in each approach?
• What is the timeline required to begin or complete this initiative?
• What is the total volume of data being migrated?

Argument for rehydrating stubs in the source environment prior to migration

Restoring all the archived items back to Exchange and eliminating their shortcuts certainly has some appeal. When this approach is taken, there’s only one migration of data from source to target required per user (rather than both the mailbox and the archive migration required in other approaches). Shortcut management is no longer a concern, as the native tools are used, and stub reversion or deletion is managed through that process. All sounds great, right? So far, perhaps.

Argument against rehydrating stubs in the source environment prior to migration

Rehydrating stubs on the source results in an explosion in the volume of data in your Source Exchange server. For many organizations, the expense and risk of this volume of data in Exchange is what drove them to implement an archiving solution in the first place. Mailbox quotas will have to be managed to enable the additional data, and the storage infrastructure in Exchange will likely have to be drastically expanded, even though it won’t be needed once the migration is complete. Even worse, if this aspect has not been adequately considered, or miscalculated, you could face a whole world of problems. Once available space is exhausted, and budgeted funds dry up, you can expect the “I’m losing a gazillion dollars a day due to this outage” conversation for weeks to come while you stop all migrations and try to resume some stability on your Exchange servers. Email systems are nearly always “line of business” with no tolerance for fault; archiving systems are rarely elevated to quite the same level of importance.

What to know if you choose this method

Time will absolutely have to be on your side if this is the approach that you are taking. Not only will each mailbox to be migrated be substantially larger (and therefore take longer), but you will also have to ensure that the restore from the legacy archive solution completed, per user, prior to starting that migration process for that user. Problems restoring the data could substantially delay the ability to even kick off that user’s mailbox migration.

Although it is frequently evaluated as an option, in considering just these few challenges when using stub rehydration as a business model, it is clear to see why it is rarely chosen as a model for the migration of archive data. Keep an eye out for our follow-up post on Quadrotech’s recommended approach to handling stubs!