Squeezing a Gallon into a Quart Jar (How we Migrated 8TB into 4TB of Storage)

Binary Tree would like to welcome Joel Greenwell as our guest blogger. Joel is the owner of Pearbrook Management Consultancy in the United Kingdom and is an expert information technology and services consultant. Joel, along with Pearbrook, provides personal consulting services, and will works to help customers discover new business opportunities, reduce costs, and improve efficiencies wherever possible.

Clients always want to maximise the efficiency of their infrastructure, and this is especially true with migration projects to a new Exchange environment.
One particular project that I recently worked on started with a Lotus Domino environment that had 8TB of mail data, and the challenge was to migrate all 3,500 users to an Exchange installation that had only 4TB of storage in total. Before I go any further, the client was also implementing an archive solution on Exchange, so this wasn’t going to be an 
impossible exercise, but more of a clever execution of migration techniques and leveraging the capability of advanced features in the Binary Tree migration productsConsolidating Data
Knowing what Binary Tree’s software tools are capable of, I came up with the concept of SNAP and DELTA, a two-stage migration methodology that staged a partial migration of data to the new Exchange platform, and then at a later date allowed for the final cutover of the users and their remaining data. The SNAP stage of data migration focused specifically on migrating email content delivered to a users’ mailboxes up to 6 months prior to being switched over to Exchange and Outlook.
The DELTA stage of migration covered all the remaining mail, calendaring, and contact data and was performed when users were actually being switched between email environments.
Microsoft Exchange environments are dependent on log files for their operation, and when migrating large amounts of data, there are plenty of log files being generated.  SNAP migrations allowed us to manage the generation of log files, thereby ensuring Exchange was always available during the course of the DELTA migrations. 

The SNAP migration also allowed us to assess the performance of the new Exchange environment with live data, not only with the delivery of service to end users, but also impact of tertiary activities such as Indexing, Backup, Archiving, and Anti-Virus scanning of content. Thereby we could address any issues encountered with the Exchange environment and underlying architecture (Virtual Machines, Server Blades, SANs etc) with genuine data with no risk to the business.
Sizing the new Exchange environment is always a contentious issue, as the data compression methods and type of storage between the legacy and new email environments can vary greatly. SNAP migrations allowed us to manage the growth of data within the Exchange environment, especially with regards to the exchange databases, allocation for log data, and also disk consumption due to indexing.

Lotus Notes to Microsoft Outlook MigrationWhen it came to deployment of Outlook and switching users’ to Exchange, the time window for the remaining DELTA migrations was greatly reduced, thereby giving us the opportunity to migrate more users during the deployment phase, while at the same time not consuming all the storage set aside for the Exchange logs.


Coexistence during this migration was a key factor, and supporting a SNAP/DELTA migration methodology needed to support “hidden” Exchange mailboxes that contained the SNAP delta of users yet to be deployed with Outlook.
This is where Binary Tree products were very helpful to support this migration methodology and provide continuity for both environments during the course of the migration. Advanced features, such as being able to easily remove migrated data, allowed us to perform throughput analysis with live data in order for us to size the migration infrastructure.
Binary Tree was first class with regards to its support prior, during, and post migration. They were able to provide technical insight and assist with issues that weren’t directly associated with the migration and coexistence part of the project, like 3rd party systems connecting with the Exchange environment.
I could be corny and say using Binary Tree’s products was a “SNAP”, but it’s true that their migration and coexistence products were the ideal solution, and had the capabilities to support the SNAP & DELTA migration methodology. 

- Joel