These Mistakes Can Derail a Legacy Software Conversion

One of the most significant common challenges shared by IT executives everywhere is legacy software. Here’s what to do about it. A survey in the 2019 State of IT Report found that 64 percent of companies listed need to upgrade outdated IT infrastructure. Here are some mistakes that can derail a legacy software conversion.

Businesses list legacy software conversion as the leading factor for increasing IT budgets annually.

It is well known that IT systems require continuous maintenance and updating. There is continuous-updating to adapt to changes in technology. Outdated coding languages, privacy, and security concerns, new integration requirements are just a few of the factors causing business errors.

Many organizations inevitably face the challenges of a legacy network and find themselves needing to upgrade. They convert their own IT infrastructure into new, and more versatile systems often called a legacy system conversion. A successful legacy conversion has the potential to create significant advantages.

• Financial: Significant cost-savings from converting to a more seamless system requiring less supplemental integrations.
• Productivity: Increased efficiency created by a more integrated system built on updated coding languages. In the era of remote work, adapting software capabilities is especially necessary.
• Security: Enhanced security and privacy are made possible by more recent software and protocols.

The legacy software conversion process is fraught with challenges.

The challenges can become costly when not properly planned for in advance. It’s no secret that many organizations are intimidated by new software development. Neel Sus is the CEO of Susco Solutions, and an award-winning development firm specializing in legacy system conversion. Neel Sus sees that many of the challenges play out in organizations no matter how small or large.

Sus has stated:

“As an organization grows it needs to be unshackled by replacing antiquated legacy systems with modern scalable solutions. We all know these projects come with great reward, however may of us don’t realize they also hold equal peril.

While an organization may have determined that the pain of change is less than the pain of staying the same, unless they take painstaking efforts to approach the challenge with the humility and diligence it deserves, the results can be catastrophic. 

Many of these projects never see the light of day, and even worse, sometimes they go live and cause great financial loss to the organization.”

Neel shed some light on the biggest and most costly of those mistakes that he’s seen legacy conversion projects run into and how to avoid them.

The 5 Biggest Mistakes That Lead to Project Failure

• Insistence on a Monolithic Rollout (instead of iterative).

A monolithic rollout is a traditional approach to converting a legacy system. As the name suggests, the new system is rolling out all at once.

Analogous with the waterfall approach, monolithic rollouts take a linear path and both the designer and customer agree on a design and scope early in the development lifecycle, complete user testing pre-launch, then deploy the system in its entirety.

While companies often like the idea of one set launch date, the system may be more susceptible to defects. Changes to the live system as a whole are usually more expensive and time-consuming than small adjustments during testing.

• Underestimating the Data Migration Scope.

It is easy to underestimate the difficulty of a legacy data import. Intuitively, you may think that replacing a bad system would be easier than replacing a good system. The opposite is true. Bad systems invariably have poor data integrity.

Often, relationships won’t even be defined by foreign keys. Additionally, the data is often poorly normalized with duplicative information spread across the system. Usually, the systems have no business logic to keep the duplicative information from conflicting.

Bad systems invariably have poor naming. Without access to the original developers, poor naming can make reverse-engineering exceptionally difficult. Identifying the primary key as a “foreign key” field. The Primary key as a foreign key references when the code doesn’t actually have a foreign key constraint. When Primary key and the foreign key is named incorrectly, the process to sort the error out can take hours.

All of this is why you should always set aside a significant percentage of your budget to the legacy data importance. Depending on the scale of the project, it can be a quarter or more of the total budget. Sometimes the foreign key will be a column or combination of columns whose values match the primary key in a different table.

Each of these issues has to be sorted out separately.

• Changing the Business Processes

On the surface, it makes a lot of sense to have a sufficient budget. We’re going to be replacing the legacy system, so why not go ahead and make significant improvements to the workflows while we do it.  Clearly, this is more efficient than doing the conversion, then changing the new system, right?

While this sounds great, there are three significant challenges here:

1. The legacy system conversions carry enough risk as-is. Adding significant improvements to the workflows is adding yet another issue.
2. Chances are the development team doesn’t understand all the emergent workflows users do in the current system, which will break with process re-engineering.
3. Most end users are resistant to changing systems; adding process re-engineering adds more “pain” to the rollout.

• Lack of Buy-In From End Users

Obtaining buy-in from all end users on a project plays an essential role in ensuring a smooth transition to the new system that does not interrupt business processes. Many companies leave critical decisions of the conversion to top-level decision-makers.

Most top-level decision-makers don’t worry about getting the consensus of the end-users being impacted by the conversion. The decision-maker with no information will run into productivity and efficiency issues. Further, this action will open an organization up to risks of project sabotage. By whom? By disgruntled influencers who were excluded from a process that is touchy in the first place.

• Not Respecting the Hidden Complexity of Legacy System

When an off-the-shelf solution doesn’t account for the intricacies of a process where users are forced to create their own workarounds. Most frequently, if a system allows for hand-entered reporting fields, users may start to adapt the fields for different purposes and needs.

The results are inconsistent data and a process that is difficult to document and replace. By starting with detailed analysis at the onset, developers are better able to identify emergent workflows and understand the root problems in the current system that can be addressed by the new system more effectively.

Susco’s, Neel Sus, suggests planning for each of these conversion scenarios in advance.

• Build your team consensus around the project.
• Communicating transparently with all stakeholders on the functionality needed for end users.
• Explain the issues in a new system and show that it can pave a path to a robust final product.
• Demonstrate how the system pays long term dividends for an organization.
• Replacing a legacy system in any organization, no matter the size is a significant undertaking in which the leadership of the project is critical.

The post These Mistakes Can Derail a Legacy Software Conversion appeared first on ReadWrite.

ReadWrite

Deanna Ritchie

Managing Editor at ReadWrite

Deanna is the Managing Editor at ReadWrite. Previously she worked as the Editor in Chief for Startup Grind and has over 20+ years of experience in content development.

(98)