How the modern CIO grapples with legacy IT

For Jo Abernathy, CIO at Blue Cross Blue Shield of North Carolina (BCBSNC), it was time to just walk away from the healthcare company’s aging IBM Db2 databases running on AIX. “We decided to prioritize the elimination of some pervasive technologies that have become too expensive relative to comparable products, and where support was lacking,” she said. Db2 has been expensive to license. Also, identity and access management has been problematic, and support for AIX today is a specialized skill set. Most importantly, they needed good support. “We haven’t gotten that,” she says. “We needed to do something different.”

The key to deciding how long to keep a technology lies in figuring out where you get the best return on investment, and while moving off Db2 might sound like a no-brainer, there’s nothing easy about the decision process. “It’s not like you can jam all the factors into a machine and it pops out the answers,” she says. “It’s very situation-specific.”

Linda Ivy-Rosser, VP and research director at Forrester, knows all about dilemmas like these. “Most CIOs are managing cost by maintaining the core ‘as is,’ just trying to hold on and stay within that ‘if it ain’t broke don’t fix it’ mantra,” she says. “But even if you decide to retain legacy systems, that doesn’t mean you do nothing. To bring growth in, some level of modernization has to occur, and you still have to pay down technical debt.”

Here’s how other IT executives tackle the problem.

The weight of tech debt at UC Riverside

Reducing technical debt was CIO Matthew Gunkel’s objective when his team decided to migrate the University of California Riverside’s ERP system to Oracle Fusion Cloud Financials. “We had 90 custom applications that supported our finance organization,” he says, that were originally built using PL/SQL and the Grails Framework. “We spent a lot of time supporting those applications on a legacy codebase. It was decades old, badly commented, and didn’t follow modern coding and development paradigms.” Developers willing to work on the system were hard to come by, and when someone new did come on board, it would take six months to get them up to speed. “We didn’t have enough people or enough time,” he said. Today, as part of the migration, his team reduced the number of supported applications to just 30.

The scarcity of talent that can support business-critical legacy systems can block growth, and is a good reason to consider retiring aging technology, says Ivy-Rosser. “We see a lot of that with our banking, insurance, and actuary clients.” If migration isn’t feasible, another option is to work with a service provider that can provide a large pool of legacy talent.

Part of the code review process was getting developers to think differently about how they worked in the old paradigm at UC Riverside and how they might work differently in the new one. For example, the team initially estimated they would need a month to rewrite an application. But after carefully reviewing the code and streamlining the application, they ended up doing it in a week. “They were able to eliminate a middleware piece that was adding complexity,” he says.

Any opportunity to pay down debt, repurpose, and make strategic investment decisions that give the highest yields should be looked into, says Ivy-Rosser. But Gunkel says other legacy systems aren’t worth the risks to update. For example, researchers built industry-leading climate models in Fortran. “It’s very cost ineffective to rebuild that, and you run the risk of causing some change that shifts the model or trust in the model,” he says. In cases like that, he adds, you hold onto it.

Even when you have a business case for replacement, you may be at a disadvantage in terms of disentangling your systems from a technology if you didn’t plan for the technology’s eventual replacement up front, Gunkel says. “You need to understand the exit strategy from the beginning,” he says, particularly with a SaaS engagement. Abernathy agrees. Ideally, your separation agreement and transition support were negotiated up front, she says.

Regular reviews are critical to assess any changes in terms and conditions. For example, when a storage contract with Box went from unlimited storage to a capped amount, the scale and cost no longer made sense—especially when Gunkel reviewed what competitors were offering. “You have to constantly analyze and understand where and how the competitive landscape is changing,” he says.

The University is now moving toward annual reviews of all IT systems and software. “It’s about how we can make everything work together more effectively, and where we can leverage commodity systems,” he says.

And Ivy-Rosser adds, “As you revisit the technology’s capabilities, consider how it maps to desired strategic outcomes and business value, and whether the technology is incompatible with modern capabilities.”

BCBSNC Keeps It Simple

Even when a technology needs replacement, convincing the business can be challenging. There’s a tension between retiring old assets and focusing on new applications that bring additional value, Abernathy says. “Business leaders often underestimate the complexity that technology leaders deal with,” she says. “It’s harder than they think, and being able to convey that without sounding like you’re exaggerating or whining, it’s tough. That’s why we strive for simplicity.”

When reviewing products and services, Abernathy considers whether a technology still fits into requirements for simplicity of geographies, designs, platforms, applications, and equipment. “Driving for simplicity is of paramount importance because it increases quality, stability, value, agility, talent engagement and security,” she says. Other red flags for replacement include point solutions, duplicative solutions, or technologies that become very challenging because of unreasonable pricing models, inadequate support or instability.

In some ways, moving to SaaS-based applications makes the review process simpler because decisions as to whether and when to update and refactor are up to the provider, Ivy-Rosser says. But while technology change decisions are the responsibility of the provider, if you’re modernizing in a hybrid world, you need to make sure your data is ready to move and that any changes don’t create privacy issues. With SaaS, the review should take a hard look at the issues surrounding ownership and control. “And as new services are released at a faster pace, you need to make sure if you’re in a hybrid world that your operations, architecture, and infrastructure are optimized to leverage those new features,” she says.

Another challenge for Abernathy is deciding between maximizing an existing technology versus getting too locked into one vendor. For example, BCBSNC uses Salesforce, which Abernathy describes as a low-code platform that makes it fast and easy to get business applications out the door. “On the one hand we need to leverage the heck out of it,” she says. “On the other, you’re getting into vendor lock-in, and there might be a less costly point solution that, say, AWS is rolling out. Salesforce is more expensive, but you have it all in one platform. It comes down to who’s going to be the best partner. And then there’s the simplicity factor. There are always trade offs.”

Abernathy also developed an annual budget just for refreshes and retirements. “We have Technology Lifecycle Management, a bucket of money we get every year and we use it to keep our systems running, secure and cost effective,” she says. Another strategy, she adds, is to time major refreshes and retirements with the business cycle, if you can. “When companies are having a good year, it’s a good time to say let’s throw money at this legacy thing and start a migration,” she says. “But there has to be a lower OpEx, and the ROI has to be there.”

On the other hand, some technologies that aren’t delivering may not be worth replacing right away. “If the expected return for replacing something isn’t compelling, especially if we know it’s on a limited timeline for existence, we may let it ride,” Abernathy says. Even an end of life notification isn’t always enough to make her fold. In some cases, she says, they’ve negotiated best effort break-fix support, used third-party support, or even gone unsupported for a period of time.

Cosentino follows strategic criteria

Sometimes compelling new features in a major upgrade provide a strong incentive to migrate, which was one reason why surfaces manufacturer Cosentino is moving to SAP’s S/4HANA. “In most cases, we make decisions based on strategic criteria to determine the right time to make a change,” says group CIO José Rodríguez. “This could be driven by our company’s strategy, technological advancements, user experience, or economic factors. The next migration to SAP S/4HANA addresses several of these factors.”

Cosentino performs roadmap reviews every six months. “The criteria for these decisions is always around alignment with the company strategy,” he says. And while many systems are refreshed on a regular schedule, IT infrastructure in the factories is replaced every 36 months. Even though that’s aggressive, he says, “we are a factory that runs 24/7. We can’t allow a single minute of downtime. With newer equipment, the probability of failure is less.”

Rodríguez has eight key criteria he uses when reviewing existing IT hardware, software and services:

Is it meeting the needs of the overall group, versus serving just the needs of a specific part of the company or a specific brand? “We prioritize global solutions over specific ones for specific markets,” he says.

Does it keep company know-how, such as key business processes, inside the business?

Is it keeping up with market trends?

Does it follow the latest standards?

Is it as fast and agile as competing products or services? (Sometimes speed and agility are more important than other factors.)

If it’s serving a standard business function, is it a standard market application?

Does it support the strategy of the company?

Does it fit into the company’s cloud-first strategy?

“To me, the most important criteria is business alignment,” he adds. “That means alignment with our strategy, market, costs, and technology.”

BSH Home Appliance

Vice president of digital platform services Berke Menekli takes an analytical approach to regular legacy technology assessments at BSH Home Appliance. “We record the business capabilities into our enterprise architecture platform for every tool so we can run a portfolio optimization process over those” to detect any overlap in capabilities, he says. “Any organization of our size has 1,000 to 2,000 applications registered,” he adds, so having that capability analysis is a key factor when deciding whether to retire or replace a technology.

He also considers alignment with current business strategy and where the product or service fits within the technology refreshment cycle. Factors include whether the product is at end of life, whether the asset is fully depreciated, and whether they’ve fully leveraged the value of the investment. Everything is on a schedule: laptops and data center equipment are replaced every four years, smartphones every three to four years, and data collection devices in the factory every seven years.

During the software review process, which takes place every two or three years, he considers the license contract, replacement cost, and ongoing, recurring costs. “We also look at IDC and Gartner research to understand the capabilities and costs of alternatives,” he says. There’s no standard timeline for replacement except for end of life announcements, he adds.

Menekli’s strategy for maximizing the value of IT investments has changed in recent years. “Previously we focused on optimizing yearly costs. Now we’re focused on the end game: reducing our overall cost position.” In some cases that’s meant accelerating implementations so the company can retire older investments in order to reduce costs. But it’s all about the finances, not bringing in the latest and greatest technology. “If it’s fine to go a couple more years with the technology, we do.”

That may be the case with Macbooks and Chromebooks, which Menekli says tend to have a longer lifespan than his Windows laptops. “We’re looking to see if we have a business case if we can keep them for seven years,” he says. “We’re always investigating whether there’s a better business case.”

Deciding factors

The most important consideration when deciding to replace information technology or not is whether it’s still in alignment with the business strategy, says Rodríguez. Then look at what’s happening in the market, with costs, and with the state of the technology.

Every organization should review legacy technologies during annual planning and budget cycles, says Ivy-Rosser. That’s standard practice. “But every time you have to justify a CapEx or adjust an OpEx budget, you should do the review again…and make technical debt discussions a transparent part of the decision-making process,” she says.

But cleaning up technical debt shouldn’t be your only consideration, says Menekli. You also need to consider the financials and whether a technical refresh is warranted.

Be careful before placing your bets on a replacement technology, and realize that the grass is not always greener, adds UC Riverside’s Gunkel. “All platforms have their problems, so be very intentional about what those problems are, and which ones your team can intentionally solve and can control through your staffing and team.” If the technology you have helps solve your organization’s weaknesses, holding on may be your best bet.

When it’s time to make a change, if you’ve done your homework up front and have a separation agreement, you’ll have an easier time of it, says Abernathy. Also, have a plan if the new technology falls short of expectations. “Decide early on how long you want to invest if the value is slow to come,” she says.