Spooky Systems: How to Slay “The IT Monster” During M&A

We were recently approached by a company that boasted to us that it had created its own, totally customized IT system. It was so amazing, they bragged, that no one, outside of their company, could ever work with it.

That very conversation was the impetus for this article!

We’ve seen this too many times to count. Call it what you like: “Customized.” “Homegrown.” “Frankensystem.” Whatever the name, it’s a problem. Any company with a system like this is necessarily much, much harder to integrate when it’s purchased by another firm.

It’s not just harder. It’s slower. Costlier. And riskier.

You’d think that this post-merger integration, or PMI, challenge, would be flagged pre-acquisition, during the due-diligence phase. But, sadly, you’d be wrong—99 percent of the time. (The other one percent? They’re the truly strategic acquirers.)

What is a homegrown IT system?

Let’s start with what a homegrown system isn’t. It’s not one that uses commercial off-the-shelf, or COTS, solutions.

COTS has lots of advantages. It’s generally affordable. It’s supported by its manufacturer. It’s basically secure. And most important of all, it’s proven. It’s subject to rigorous version-control and testing—what’s known as “software development lifecycle,” or SDLC.

All of that goes out the window with a homegrown system.

Which begs the question: Why would a company ever create one in the first place?

Typically, it will start with a single requirement. They believe they need a point solution, and also believe they can best create it themselves. So it starts small... kind of like an infection.

Then, beyond the original requirement, there’s the personality factor: “Hey, I could do that!” Or: “This looks like an interesting challenge!” Or: “That looks like fun!” In short, many of these clunky, unwieldy systems begin their lives as a hobby.

Sometimes these people have a background in software engineering. Sometimes they’ll follow SDLC. More often, they don’t. Sometimes, a project will simply get dumped onto someone else, such as a junior project manager: “Hey Linda. We want to ‘bend’ this application so it will do something different, just for us. Take a stab at it. We’ll give you six months.”

By that time, the original “hobbyist” would have moved on.

All shapes and sizes

Not long ago, we worked with a global enterprise to help integrate one of its newly-acquired companies. This company had purchased an accounting/procurement system, years ago. The system didn’t do exactly what they’d wanted, right out of the box, so they started customizing it themselves.

It’s certainly possible to tinker with a COTS system; if you can get your hands on the original code, or if it’s open-source, you can do quite a lot. In this company’s case, they added functionality which wasn’t part of the original system.

That’s how this project started. Over time, it grew—and grew. By the time Ensunet was brought in, this home-brew procurement system, with all its bolt-on’s and ancillary applications, spanned a staggering 90 different servers.

Yes, ninety. Five were a cluster for the basis of the system. One handled the print part. Another stored the database. Yet another stored a replicate of the database. And so on.

No one, when we arrived, even understood how it worked. The consulting firm that helped build it in the first place was no longer in business. In addition to the massive infrastructure overhead, the thing was unstable. It crashed periodically. Everyone in the company accepted that, as business-as-usual.

Here’s another example. Back in the 1990s, a lot of well-known defense companies were folded into one of the world’s largest aero-defense enterprises. You’d think that these big companies would all follow best practice. But there was a hodgepodge of customized systems that wouldn’t talk to each other, which flew in the face of the enterprise’s design-anywhere/build-anywhere vision.

Why do we mention a story from the 1990s? Because it took 20 years to integrate all of those acquisitions.

The aftermath

If you’re an acquirer, you’ll be confronted by a host of problems with that homegrown IT system. It likely isn’t documented. You don’t know what it’s interfacing with. You don't know how the data is structured. You don’t know how that data moves around the system. And it’s probably rife with security vulnerabilities.

Meantime, the expertise behind that kluge system—either the developer or the sponsor—now has a different job in the newly-merged company, so they can’t deal with it anymore. Or, worse, once they learned of the acquisition, they simply left, taking all that tribal knowledge with them.

And if you’re the acquirer, you already have a system that does what the homegrown system does, while meeting all your requirements. Now, you’re faced with the challenge of making it all work.

Think you can turn to the company that developed the original COTS software that was so heavily modified? Think again. They won’t touch it. “That’s not ours anymore,” they will rightfully tell you.

Thus, the faster you can get off of that homebrew system, and standardize all that data—so it works between businesses, regions, and teams—the better.

CSI: IT – Forensic Edition

If that homegrown system was never documented, you’ll have your work cut out for you. You’ll need to engage a senior software engineer to figure it all out, without breaking it while it runs. That person (or team) will need to decipher the data mapping, and find the dependencies between the different modules. They must check it for security compliance; has it ever been scanned? While the server may have been patched (another element to discover), the system can still harbor all kinds of vulnerabilities.

This phase alone can take anywhere from three months to a year.

And then, before you can finally migrate the data to the parent company’s system, you’ll need to standardize it—which usually entails a lengthy, costly, manual cleanup.

Where’s the due diligence?

“What happened during due diligence?” you may well ask in a situation like this. The answer: Not much.

During the euphoria of an acquisition ramp-up, the nasty nuts-and-bolts issues are always overlooked. The acquirer will always assume that there’s an IT component to the acquisition, but they’ll always underestimate it, especially if a homegrown system is involved.

(Even if a homegrown system isn’t involved, IT issues get perennially overlooked. Ensunet recently worked on a PMI wherein the due-diligence team reported that “no PCs would need replacing.” Well, they overlooked a half-million dollars’ worth of them—including many that were eight years old.)

Remember “Linda,” who worked on that 90-server setup? She had no idea what SDLC was. None of that was flagged during due diligence.

A cultural migration

As with all IT migrations, the biggest challenge is the human component. There’s an ingrained culture, protocols, and tribal skills. How, then, do you “wean” a company off of its homegrown mentality?

You need to be gentle, and persuasive. You want to lead them to the new company’s system, not push them into it. You need to sell it to them, convincingly: “Here’s the new system. Here’s what it does. It saves money. That old homegrown system, on the other hand, is costly. If we tried to maintain it, we’d have to lay off people just to pay for it. So we’d much rather have the best of both: Great people, and a great system.”

Need help with that next integration?

Here at Ensunet, we’ve helped clients overcome more than their share of homegrown IT systems during post-merger integration. We can help you, too. Download our free M&A IT Playbook & Integration Checklist. Or contact us today for a free, no-obligation consultation with one of our friendly subject-matter experts.

Remember: M&A value creation happens when you address technology considerations, which in turn drives measurable execution to realize synergies across the value chain.