When Companies Merge: A Messaging Solutions Story

Recently, I began working on a project that involves one company acquiring another company. The acquiring company engaged me to manage the acquisition process from a messaging perspective. Over the next few weeks, I'll let you walk along side me as I go through this merger process and deal with messaging problems involved with merging two companies, the business requirements, and the impacts on the Exchange Server deployments at both companies. The specific companies I'm working with aren't important but the scenario is. Many of you will face these same concerns, so here's your chance for a practice run.

Background
Both the acquiring company (let's call it ABC.COM) and the "acquiree" (let's called it XYZ.COM) have Exchange deployments, which makes the merger process much easier from a messaging perspective. If the companies had different messaging systems (such as Lotus Notes/Domino and Exchange), my job would be much more difficult. ABC.COM has almost completed its migration to Exchange 2000 and has deployed Windows 2000 Active Directory (AD). XYZ.COM runs primarily Exchange 5.5 (with a few Exchange 2000 mailboxes) and also has deployed AD with synchronization (via the Active Directory Connector—ADC) to its Exchange 5.5 directory.

Business Requirements
The two companies have outlined several business requirements we must deliver for their messaging deployments.

• Requirement A: Both companies want to be able to route mail privately between organizations. This requirement means that instead of routing mail to each other over the public Internet, the companies want to use a private connection that will be in place by the closing date. This approach will provide added security and ease the load of both companies' SMTP gateways to the Internet. Mail traffic volumes between the two companies will naturally increase after the merger, and the need for additional security will be paramount.
• Requirement B: The next messaging business requirement will be Global Address List (GAL) access between the two organizations. In other words, ABC.COM users need to see XYZ.COM recipients in their GAL and vice versa. This setup will make communication much easier than having to resort to Personal Address Books (PABs) or a worse alternative.
• Requirement C: Free/busy information is another requirement. Both companies want to be able to schedule meetings and check schedule availability across organizations. This requirement isn't crucial, but both companies have identified it as a desired bonus to facilitate communication between organizations.
• Requirement D: Another desired goal is for all users at XYZ.COM to have ABC.COM email addresses. This email address standardization communicates to customers that the companies are one and lets XYZ.COM employees feel part of the ABC.COM team. This plan won't replace users' existing XYZ.COM email addresses but simply add an SMTP mail address for recipients at XYZ.COM.
• Requirement E: Finally, because this merger is an acquisition, both companies want to eventually have a totally integrated environment for messaging as well as all enterprise applications (i.e., directory, account, mailbox, and Exchange organization integration). This requirement will achieve total integration of the two companies and hopefully accomplish some of the cost reductions and business benefits the acquisition was intended to provide.

Over the next few weeks, I'll address each messaging requirement and the solutions we decide on. Ideally, you'll be able to glean some ideas and get a first-hand look at a project of this nature through the eyes of the poor soul (me) who has to solve these problems (some easy and some difficult). Obviously, I'm only tackling the project's messaging side—many other infrastructure and application concerns fall outside the scope of Exchange and messaging. So, fasten your seat belts and turn off your cell phones, and next week I'll discuss how we addressed requirements A and B.