Posted by
Valentin Vasquez, Senior Solutions Architect, E2E Complete
Customer questions relating to Exchange resource forests are becoming more and more common for our technical team. Organizations want to consolidate their existing Exchange environments to a single Active Directory (AD) forest running
Exchange 2010, while leaving their user accounts in their old AD domains.
Merging multiple AD forests into a single forest is a
VERY complex undertaking, which requires transitioning workstations, laptops, servers, printers and all applications that interact within that AD environment. So it’s no wonder that customers shy away from that
migration project and go with a brand new build-out of an Exchange resource forest to run their messaging environment in a more centralized, consolidated infrastructure.
This may become an even more common method to deploy
Exchange 2013 when it is released. However, there are some serious challenges related to linking active user accounts from one AD environment to a separate Exchange AD forest and successfully migrating all the email data intact.
In this article, I’m going to discuss the different steps that MUST be performed to do this manually and describe how our E2E Complete software automates this entire process.
READ MORE >>
Everyone knows that the first step in any activity is the most crucial one. An email migration project is no exception. However, the importance of the proper project initiation is often overlooked. Many times a project kickoff meeting focuses only on the statement of work when it should include a full planning workshop, which involves significantly more than a document review. There are several key considerations that should be addressed during this session and all responsible parties must be in attendance. Binary Tree specializes in email migrations and we often run migration planning workshops with customers that are preparing for their transition to Exchange 2010. In this blog post, I’m going to impart some of our best practices to drive a successful planning workshop for an upcoming mail migration. The main topics covered in this article are: 
- Understand why the migration is occurring
- Define critical goals for the success of the project
- Identify project team roles and responsibilities
- Plan for end-user change management
- Ensure team buy-in on realistic project timeline and milestones
- Address the top 3 overlooked critical success factors
READ MORE >>
Binary Tree specializes in
email migrations and it is quite often that we attend planning workshops with customers that are preparing for their
transition to Exchange 2010. During these meetings, a very common question that comes up is,
“How fast can we migrate to the new environment?” And it may sound tongue-in-cheek but our standard answer to this question is,
“You can migrate as fast as you want.”
This usually comes as quite a shock to the project teams. However, as we explain the scalability of migration processing they come to understand that the theoretical limits for migration speeds are really only bound by the available bandwidth on their network and the speed of their servers. The more migration infrastructure (sessions and processing methods) you configure within your environment, the faster the data will get moved.
The true gating factor is the practical limitation of migrating end-users,
NOT their mailbox data. Moving mailbox data is easy, moving end-users is hard. The change management aspects of a migration project, which include end-user training, desktop updates/refresh, communications, migration scheduling, help-desk support, among other things, are truly the limiting factors for how fast you can migrate email to a new platform.
But customers always want to know how they can perform an accurate estimation of their data throughput for a migration to see what their theoretical limitations are for the project. There are two important factors that I’ll describe in this post which are key to crystalizing a migration throughput estimate:
- Identify and Validate a Single Migration Speed Unit (for each source and target location)
- Perform a Migration Test in the Production Environment with Real Mailbox Data
There’s no getting around the need for Cross-Forest, or Inter-Org,
email migrations. They just happen. And in some cases an IT group has only a few days to plan out the transition. They are brought about by different events such as mergers & acquisitions, company divestitures, or just plain company partnerships when organizations want to combine their email environments onto a single platform. Whatever the reason for your migration project, you will need to address the same issues every time.
The
cross-forest migration process is quite complex and the Binary Tree
E2E Complete product can assist you to simplify and streamline the mailbox migration process. However, to begin with, you will need to synchronize the Active Directory (AD) forests, establish bi-directional data flow between the domains, and prepare the environment for the mailbox migration process.
What options are available? Are there solutions which can ensure the success of the AD transition?
READ MORE >>
The Lotus Notes Era
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.
The Notes Exodus Era
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.
READ MORE >>