The IT migration from hell

Ask any tech professional, and they’ll surely tell you a system migration is, at best, a challenge. But add poor communication and an inept project manager to the task, and you’ll soon find yourself engulfed in chaos.

A couple of years ago, our company was bought out by a large global giant. The deal closed, and the layoffs and reorganization began. In the midst of all this, the mammoth task of merging the two firms’ IT infrastructures was led by a team from the new company under the management of “John.”

[ Also on InfoWorld: Paul Venezia explains how to move a data center without having a heart attack. | Follow InfoWorld’s Off the Record on Twitter for tech’s war stories, career takes, and off-the-wall news. | Subscribe to the Off the Record newsletter for your weekly dose of workplace shenanigans. ]

I’d been proud to work at our old company. We’d maintained high standards with IT best practices, planned extensively for IT projects before implementing changes in phases to make sure nothing broke, and valued open communication between departments. In contrast, the new company was a disorganized hodgepodge of several acquired enterprises Band-Aided together like Frankenstein, had an attitude toward IT projects of “just throw it out there to see what happens,” and didn’t communicate between groups — they were more siloed than a Midwest corn farm.

And like hot and cold air masses clashing over Oklahoma, destruction was brewing.

Before the storm: Preparing to migrate

John’s team decided we should start the migration with the old company’s corporate headquarters. The lack of planning was alarming, but John assured us all would be well; he and his team had done this dozens of times before.

The big project for IT support was to get users’ accounts, mailboxes, and PCs onto the new company’s domain. The migration team had used a “successful” procedure for the last several acquisitions: a third-party tool to automatically migrate all three items at once. We were to do this for everyone in the building, and our new manager told us we’d do this the night of Oct. 24. Of course, it was critical that both their user account and PC be migrated at the same time or they wouldn’t be able to log in.

There was more: Oct. 24 loomed large for other teams within the company. For example, various silos had been tasked with migrating by Oct. 24 and 25. John’s team also oversaw these departments’ migration assignment, but failed miserably in scheduling and communicating these goals. And completely separate from the rest of IT, the network team had been working on its own merger project. To adopt the security practices of the new company, all network jacks that had not been used in six months were to be deactivated at midnight on — wait for it — Oct. 24.

As if that weren’t enough, around the time the merger closed, we were in the middle of a rollout of new PCs to everyone in the building. Once the shakeup happened, the inventory backlog dropped down the list of priorities; about half the users had the wrong PC listed as their primary unit. We should double-check everything before the migration, we told John. His reply: “Nah — it will be OK.”

Last but not least, because workers at the new company’s corporate headquarters were crammed in the building like sardines, a couple of departments would be moved to our already tight office. The Facilities department was to reconfigure hundreds of rooms. They did not communicate the new assignments, so none of this information was updated in Active Directory. We knew a move was happening but weren’t told when.

Tornado touchdown: Migration day

The night of Oct. 24 arrived. The migration team told IT support this would be a piece of cake and we’d be home by midnight. They were very wrong. Because of the inventory problems, we spent the entire evening on into the morning just tracking down user PCs and turning them on.

We hadn’t made much headway on the actual migration when at 5 a.m. we were surprised to find moving crews from Facilities arrive, start packing up user equipment, and moving it to new cubes and offices. In addition, we soon discovered that the networking team had deactivated unused network jacks.

People arrived for work and found a variety of scenarios — all of them bad. Either their PC equipment needed to be hooked up, they couldn’t connect to the network because the jack in their office was inactive, they couldn’t log in to their PC because it was on the wrong domain, or they could log in but their email didn’t work because the mailbox migration errored out.

When it rains, it pours

Angry people contacted the help desk. But when a ticket was generated, it was for their old location, so no one knew where to find most users. You couldn’t call them because their phone extensions hadn’t been moved yet and their BlackBerry was not listed in the new address book for the new domain.

Only the network team could enable network jacks, and their new manager wouldn’t do anything without a ticket to document the request. When they actually got a ticket for a user, it often listed the old location, and since that jack was already active, they would close the ticket without doing anything.

If a user’s PC was on the wrong domain, it had to be manually migrated to the new one and placed in the proper organizational unit for the specific department — accomplished through guesswork at best. That part would be automatic, we’d been told, so no need to have documentation at the ready. People ended up with all of the wrong group policies.

For email, we had to manually set their Outlook profile to the old mailbox and migrate them again. If that didn’t work, we could pass it along to the migration team to handle it through a longer process — when they got around to it.

This was how things went for a full week. Eventually, most of the people in the office were able to work again. Some members of the support team were on the clock for 36-plus hours, only to come back and do another multiday shift. The overtime payout was enormous, the lost productivity was incalculable, and everyone pointed fingers at everyone else.

However, at the end of the week John was overheard saying to his team, “All right! Another successful migration. You guys rock!”

He was not so smug after a contentious meeting with our old company’s CIO, who also passed documentation and complaints up to the new company’s execs. They must have listened because the next migration for the branch offices was done in phases, and people actually communicated.

And John? He left soon afterward to “pursue his dreams.”

Do you have a tech story to share? Send it to offtherecord@infoworld.com. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “The IT migration from hell,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.