There's a Hidden Risk in Enterprise Modernization, and It’s Not the Software

Think about the last time you built a Jenga tower. Maybe it was at your kid’s birthday party or a night out at the brewery with some colleagues. Maybe you haven’t thought about it in decades. But no matter when it was, you remember the core of the game: The tower looks stable until you pull the wrong piece and everything goes splat.

This is actually how Wayne Kiphart, the CEO of CloudFirst Global, describes the state of enterprise infrastructure right now. Even as many organizations pour money into modernization, there are so many other flaggable issues that come up and they still ignore.

Sure — the application gets replaced. That’s great, but what about literally everything else? The aging hardware, deferred patches, untested backups, weak identity controls? “The application itself is usually the most stable part of any environment,” Kiphart says. “The greater risk lies in the layers around it.”

When CIOs hear the word “legacy system,” they often tend to reach for a replacement budget. This is the wrong instinct — not because modernization is bad (it’s not), but because it’s really just treating surface-level symptoms instead of the actual disease.

“A system that ‘has always worked’ can mask serious exposure,” Kiphart says. “Replacing the application does not automatically solve those structural problems, and instead, it tends to just recreate them in a different environment.”

Outdated systems carry 3x more security vulnerabilities than modern counterparts, and companies running them are 40% more likely to experience compliance issues. In an era where regulatory frameworks are getting stricter, these numbers are surely going to get worse when we check in again next year.

Even those who try to modernize their applications are spending 42% more on operational overhead and experience 4x more downtime than their modernized counterparts, according to the IDC.

The standard response to all of these issues is modernization. Good instinct…usually bad execution.

Up to 83% of data migrations go over budget and don’t even meet the goals. Nearly 50% of delays are caused by legacy application dependencies that weren’t even identified in the assessment phase.

And the most common reason isn’t even technical. “Brittle integrations, undocumented dependencies, and unclear ownership do not simply disappear because the platform changes,” Kiphart says.

It’s why parallel environments keep happening: Organizations tend to replace a system, see that a major dependency still lives inside of it, and then they’re running two environments indefinitely.

It’s also why big-bang migrations succeed only 42% of the time while phased migrations succeed 73% of the time.

Don't worry, the warning signs aren’t grand omens. They’re the small things that teams have just stopped doing somewhere along the way. Blame it on a bottleneck, unclear processes, or lack of staff training — it happens to almost everyone. Here’s what Kiphart always sees in enterprises who are struggling.

Deferred maintenance has become the norm.

“If updates are repeatedly postponed because 'the business can’t tolerate downtime' or 'the last patch broke everything,' resilience is already weaker than leadership realizes," Kiphart says.

This is unfortunately true according to findings by Tanium’s Global Resilience Gap study: 81% of CIOs and CISOs have admitted to delaying patches specifically to avoid business disruption. That’s a bit embarrassing.

Nobody can answer the Big Recovery Question.

Backups running is a start, sure, but when is the last time anyone actually tested a restore? Do you know how long it would actually take? Because Kiphart says if the team has to think about that answer, there’s already a problem. Having backups is simply not a recovery plan; it’s just a limb of one.

One or two people are holding the entire thing together.

This one’s less about headcount and more about what happens when the one or two people who actually know how everything works leave.

Robert Half says only 7% of technology leaders say they currently have the in-house skills needed to execute their most critical projects — which means 93 out of 100 organizations are already operating closer to that edge than they’d like to admit.

From a hosting perspective, Kiphart says these signs will show up operationally — you’ll begin seeing increased performance variability, uncontrolled storage growth, HA or replication alerts that are acknowledged but not investigated, monitoring that confuses staff.

“When teams stop being confident in how a system will behave under stress or how quickly they can recover from failure,” he says, “the environment is already moving into dangerous territory.”

Instead of running around like a chicken with its head cut off, stick to some of what Kiphart calls the “non-negotiables.” It’s not a massive overhaul, but more of a list of what used to be standard anyway, and somehow got deprioritized along the way.

Security hygiene is the baseline and should never be optional.

MFA, privileged access governance, segmentation, patch management — they’re the basic ground floor things, regardless of platform age or industry.

And guess what? The deferred maintenance problem and the breach problem are the same one wrapped in a bow: In 2024, 60% of organizations experienced a data breach that cited a known, unpatched vulnerability as the main cause.

Recovery has to be proven — never assumed.

Seeing high availability on paper does not equal high resilience in real life.

“If the team knows backups are running but cannot say how long a restore would take or when a clean restore was last tested, that’s a serious concern,” Kiphart says.

More than 1 in 3 critical systems miss their recovery time objectives — it’s why it’s so important to test under real-world conditions, whether that’s DR drills, pentesting, or actual stress-testing.

“Redundancy on paper does not guarantee resilience,” Kiphart says. “At the same time, effective monitoring should provide actionable visibility into capacity, performance, replication health, security events, and potential failure points, enabling teams to respond proactively."

DR and cyber recovery are not the same thing.

Recovering from a storage failure is not the same process as recovering from a ransomware attack. In fact, most ransomware attacks target backup repositories, and 76% of those attempts successfully compromise them. A standard disaster recovery (DR) playbook just won’t help you there.

Map your dependencies before you touch anything.

Know what you have before you start packing stuff up. Every integration, every compliance dependency, every process — write it down.

Another thing, Kiphart says, is to assign accountability: “The real question is not simply where the workload should run, but who is best equipped to operate it securely, reliably, and sustainably over time."

Perhaps unsurprisingly, one study shows organizations that used automated incident response playbooks cut containment time from 79 days down to 51.

Someone has to own every part of the system — maintenance, security posture, incident response, lifecycle management — not “the team,” but a person with a name on it. There’s a reason CPR training teaches you to point to a specific person and say, “You, call 911!” instead of just yelling for help. Otherwise you’ve got something ugly called the bystander effect.

“Critical applications remain viable through operational discipline,” Kiphart says. “Not platform ideology.”

Because at the end of the day, the Jenga tower doesn’t care how beautifully stacked the pieces look; it cares whether anyone knows which one not to pull. Oh, and who to call when someone inevitably does.