BinaryTree

Posted by Vadim Gringolts, CTO

In the early days of our existence, Binary Tree ventured into the challenging and complex world of email migration by creating products that facilitated change. In the mid-1990s, we developed and marketed a number of separate tools for migrating mail, calendar, and contacts migrated from a source system to Lotus Notes.  

 

This approach initially satisfied the market need; however, it also proved challenging for customers who had multiple messaging environments in place, such as Outlook Express, MS Mail, and CC:Mail. In late 1998, while migrating a customer with a myriad of different email systems to Lotus Notes, we decided that the only rational solution was to create a comprehensive migration product. The migration challenges presented by our customers paved the way for us to create the Binary Tree Common Migration Toolkit (CMT). 

 

Over the next four years, we continued to advance the capabilities of CMT and the names Binary Tree and CMT became some of the most recognizable names in the world of messaging migration, as we became a key enabler to organizations that were transforming their messaging and collaboration capabilities.  Our list of customers was rapidly growing to include the “who’s who” of the corporate world.

Evolving to Facilitate Merger & Acquisition Integrations  

 

In the early 2000s, we recognized that the migration trend was beginning to expand beyond just migrations to Lotus Notes. Corporate mergers, acquisitions, divestitures, re-branding, and other events created a need for an enterprise-grade migration solution within Lotus Notes.  So we developed the CMT for Domains product so that customers going through a merger, acquisition or divestiture could streamline how they migrated, consolidated, or separated diverse Domino domains.  While CMT for Domains focused on Domino-to-Domino merger integration, our product line would eventually evolve to support Domino-to-Exchange and Exchange-to-Exchange merger integrations as well.

 

Also in the early 2000s, another trend was slowly emerging: migrations to Microsoft Exchange.  With IBM focusing less on Notes and Domino and diluting the Lotus brand and value, and Microsoft emphasizing Exchange and Outlook more as an enterprise messaging solution, some of our Notes migration customers approached us about a migration tool from Notes and Domino to Outlook and Exchange. 

 

In response to the market demand, we created CMT for Exchange, an enterprise-scale migration solution that met the needs and the requirements of end users and administrators alike.  The combination of fidelity, scalability, and manageability made CMT for Exchange the product of choice for the largest Domino to Exchange migration ever performed, for one the largest global financial firms, which had over 180,000 users worldwide.

 

As our experience with migrations to Exchange grew, we learned that as enterprises embarked on Domino-to-Exchange migrations, they required extensive interoperability (or “coexistence”) between the two diverse systems so that their end-users would experience a highly functional and seamless transition process.  While there were tools available for temporary coexistence between Domino and Exchange, we aimed our sights on creating an enterprise-class coexistence solution.  The result was CMT for Coexistence.  By the mid-2000s, the CMT product suite became a true enterprise messaging migration solution suite.  In recognition of that fact, the abbreviation CMT was changed to stand for Complete Migration Technology.

 

by Joel Greenwell, Owner, Pearbrook Management Consultancy and Information Technology & Services Consultant

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 products. 

 

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.

 

By Tracy Riddle, Senior Account Executive at Binary Tree

People often ask me "How can Binary Tree help ensure that my migration will be successful?"  I think this is a great question that I am always happy to answer.  And recently, a customer found out first hand the lengths we are committed to their success.

 

Thursday, August 25, 2011, I received a call from a client asking to understand how our CMT for Exchange solution can help them migrate 50 NSF files to PST’s. They explained to me that their company had recently acquired a small organization and they promised the business that they would have the PSTs available on Monday morning. 

 

Understanding that there was a huge time crunch to meet their deadlines, I set up a conference call with my Solutions Architect, the customer and myself.  We began to show them the steps they would need to do to complete this migration.  As I listened to the customer ask questions about completing this email migration on their own, I quickly realized that for them to read the manuals to learn our product, set up and configure the solution, and complete the project in less than four days was a very tall order. 

 

So I offered up our Support team.  I explained to the client that if they would like, Binary Tree would be happy to take their NSF files and convert them After considering the challenges they were facing, the customer agreed and we set up call for later Thursday afternoon to discuss how they would send us their files.