Merging Networks the Hard Way

Recently, I had lunch with an old friend whom I hadn't seen for a couple of years. He's the IT director of a midsized business with 500 users that had acquired a smaller competitor with 100 users. The company's acquisition was a rare creature: a mutually beneficial merger arrangement. The smaller company had a very efficient workforce, and there were no plans to lay off any employees. The biggest challenges would be to merge the two corporate cultures and, of course, the two computer networks.

Our conversation about my friend's experience with the merger gave me cause to reflect on the 23 years I've been dealing with computers and their problems. I realized that one lesson in particular is just as valid today as it was in 1980: Nothing is ever as easy as management thinks it is.

Knowledge and Preparation Are Everything
For some reason my friend wasn't able to explain, only a cursory survey of the smaller company's computer network was made before the merger. All he knew in advance was that the smaller company used Windows clients in a Novell NetWare environment, and his team's job would be to migrate those 100 users and their equipment into his existing Windows network, which ran Windows 2000 Server and Active Directory (AD).

The first step my friend took to analyze what actions would be necessary to integrate the two companies' networks was a detailed survey of the networking environment at the smaller company. When my friend took a call from the integration project's team leader at 10:00 A.M. on the first morning of the project, he had a very bad feeling. His pessimism was well rewarded.

Although the acquired company ran Windows clients on an Ethernet network, the computers were running Windows 95 on Thinnet. To make matters worse, at least in my friend's mind, the crack project leader he had assigned to the integration had never seen coaxial-wired Ethernet before, and in a comment guaranteed to make most of us feel really old mentioned that this was the first time he had actually seen a computer running Win95.

Adding insult to injury was the computer hardware: It was state-of-the-art technology, circa 1997. (The computers had been upgraded once; the network hardware hadn't.) The network OS was NetWare 3.0, and none of the clients had Internet access; the network ran IPX, not TCP/IP, as the transport protocol.

Faced with what looked like the need to replace the entire acquired network infrastructure from the ground up—a contingency that was definitely not in the budget—my friend called the facilities manager at the smaller company, to whom the single IT professional on staff reported. When asked why the company was running such outdated equipment and software, the facilities manager gave the perfect reply: "It works."

Because the lone IT guy at the smaller company was destined to join the corporate IT staff, my friend's next step was to call him in for a "debriefing." For the most part, the IT guy backed up the facilities manager: The network was stable, had no recurring problems, and as long as clients were shut down at the end of the workday and restarted each morning, few Windows-related problems arose. The smaller company had a rock-solid NetWare server. The last time it had been shut down was 2 years previously, for a storage upgrade to add a SCSI card for an external hot-swappable array. The IT guy spent most of his time replenishing paper in the printers and training the occasional new user. His most heavily computer-related task was replacing dead hardware components every now and then.

As the conversation wrapped up, the IT guy casually dropped a bombshell on my friend: The acquired company's custom order entry­customer management application, around which the entire company had been built, didn't seem to want to run on anything other than Win95. And, in the way things tend to go when they seem rapidly to be slipping from your fingers, the company that wrote the custom application was long out of business. As far as the IT guy knew, no one had a copy of the source code for the application.

Now my friend was faced with going to his boss and telling him that not only was the new network a ticking time bomb that required the complete replacement of every one of its components, but it couldn't actually be upgraded because its key line of business (LOB) application wouldn't work on a newer network. He knew that his boss wasn't going to be happy to have to tell his board of directors that their newly acquired $35-million-per-year revenue stream depended on obsolete technology.

All's Well That Ends Well
I'd like to report that this story has a happy ending, but the best I can say is that the problems were finally resolved. After my friend delivered a detailed report to the board of directors about the costs of moving the antique computing infrastructure and the LOB application to the acquiring company's current hardware and software standards, he expected the fur to fly. He was pleasantly surprised to get funding and approval for the project time line he had provided.

It took almost 18 months to finally integrate the smaller company's network with the acquiring company's network infrastructure, and doing so involved running a parallel network on every user's desk in the smaller company so that each user had access to the corporate network resources that were necessary for all employees. Developing an application that could replace the previous LOB application took three attempts; the project almost reached the point where the IT department grew frustrated enough to manually enter 15 years' worth of business data into a new system. Fortunately, an automated solution was developed, and the companies are now successfully merged and profitable.

Because of a lack of foresight, this "simple" network integration project extended well into seven figures when all the costs were added up. No corporate bottom line is happy with an unbudgeted multimillion-dollar expenditure. In response to this entire fiasco, my IT director friend now has a permanent seat on his company's Merger and Acquisitions committee, with direct responsibility for evaluating the IT standards of potential merger-and-acquisition targets. Now that's a good, simple idea that, had it been implemented a few years previously, would have saved his company quite a few dollars and almost as many headaches.