Post merger IT integration RRS feed

  • General discussion

  • I'm looking to see if anyone has resources or has participated in IT team integration projects as part of a merger/aquisition.

    1. How did you compare in place technologies?
        Did you try to maintain the aquiring company's platform or go with a "best of breed" solution?
    2. How important were the business' goals and objectives to your IT decision making?
    3. During integration did you find any particular solutions easier or more difficult to integrate?  Was there any vendor (say, Microsoft) that was easier or more difficult to integrate?

    Any links to research/evidence would be greatly appreciated.
    • Changed type Kevin Remde Sunday, May 23, 2010 1:44 PM Much too broad for a single answer. Great discussion.
    Thursday, March 12, 2009 6:09 PM

All replies

  • First it starts with the Business Requirements. It depends what the business wants, I.T provides a service to the business.
    Andrew Sword, MVP
    Thursday, April 2, 2009 11:29 AM

    <- has a good article on this.  You have to pay for the full research. 

    The first step, should be a GAP analysis with consideration to indexing all technology, determining purpose and functionality, then weighing pros and cons and of course, cost.  Once done, you are left with making the tough decisions based on those metrics and filling in the necessary gaps remaining and reducing overlap. 

    Business goals and objectives should be considered, but with a grain of salt.  Keep the organization in business, and keep the business units at the table with decisions, but explain to them the sooner you tie things together, the sooner you begin seeing the ROI of the merger.

    Some vendors you will have no problems with, Microsoft, Cisco, and other major techn players that are fairly universal will be easy.  The problems you'll face will be obscure third-parties that have poorly written code, or no open-standards of migration towards similar products.
    Eric Irvin, MCP, MCSA, MCSE, MCITP:Enterprise Admin, CISSP
    Thursday, April 2, 2009 10:40 PM
  • "explain to them the sooner you tie things together, the sooner you begin seeing the ROI of the merger"

    Absolutely.  But that's easier said than done.  Explaining that in a way they will accept AND understand requires overcoming a lot of hurdles of personality, past experiences (as in "remember that time we invested so much and got so little out of the XYZ software initiative?"), or simply risking stepping on someone's toes ("Hey.. I was the guy who approved that purchase.  We're not throwing it out.  No way.")

    Kevin Remde US IT Evangelism - Microsoft Corporation
    Monday, April 6, 2009 1:03 PM
  • Hi Eric,

    We are in a similar situation. Did you find any helful information? Especially about domains consolidations?


    Wednesday, April 29, 2009 11:06 AM
  • I didn't find anything about domain consolodation (as that's not what I was focusing on) but, having gone through one of these and seeing the challenges I have a one thought for you to consider:

    Naming domains after the organization is NOT a good idea.  At a retail organization I worked for they named the domains after the particular store brands.  This worked until those brands were sold and/or consolodated.  We had to go back and rename everything (including the servers that were named similarly).  Huge pain.

    Reccomendation: name the domains after their physical LOCATION (TX-Houston, NY-NewYork, etc.) then use OU's to create the right management layers. 

    If physical location doesn't work just pick something else that you can guarantee will NOT change over time.  This can be a political challenge, but is worth fighting having been part of the renaming. 

    This might be obvious to most folks, but we didn't make the right choice and ended up paying for it in the end.

    Hope that helps a little.

    Wednesday, April 29, 2009 10:06 PM