8 Critical Steps to Successful Legacy Modernization

Legacy modernization is steadily crawling up the agenda of most CIOs, driven by digital transformation, expectations of better user experiences, and the business need for significantly faster time-to-market across the board. This puts a firm spotlight on the legacy applications and systems that can’t keep up.

It is clear is that the need to modernize will only accelerate. Gartner predicts that every dollar invested in digital business innovation from now to 2020 will end up requiring three times the amount to modernize the legacy application portfolio. So, if 25% of the budget is allocated to new developments, the remaining 75% could be required to improve and renovate legacy applications.

However, when modernizing applications, enterprises often quickly make courageous decisions to fix substandard legacy applications by rewriting them from scratch. Such radical approaches are sometimes needed, but often the decisions are made too quickly without a sufficient view on alternative options.

At CAST, we regularly work with client CIOs, portfolio managers and application owners to provide the Software Intelligence needed to set the right modernization strategy, both to optimize an entire portfolio of applications, as well as to determine the best way forward for individual applications. We often see that better insight into application architecture and technical debt reveals the underlying causes for legacy application challenges and helps to identify different and better ways to achieve the objectives behind the modernization initiatives.

Avoiding the cost of rewriting applications does not only impact budgets. Typically rewriting applications requires competences that are scarce, pulling key talent away from other innovative projects and ultimately causing budgets to go sky-high.

What Drives CIOs to Invest in Legacy Modernization?

The are an increasing number of reasons why CIOs are investing more and more in IT modernization programs:

Better support of the business. This can range from enabling new business models for example by delivering services via SaaS solutions, providing access to more data and services via the web and mobile, quickly automating new cross-application workflows, leveraging external services like Google Maps, or integrating with new innovative SaaS solutions.
Improving application security or complying with regulatory requirements, like GDPR. Unsupported or insecure components or frameworks may need to be replaced or new security architectures may require old in-house code to be replaced with better or standardized corporate solutions. Such issues must not only be quickly identified but also quickly fixed, since the responsibility of resulting fallouts is likely to fall squarely on the CIO.
Increased scalability. The existing business functionality may be appropriate and up-to-date but the application was never intended for the load generated by millions of connected customers. The need to quickly scale business applications is increasingly becoming a more important driver for moving to the cloud than the cost savings that first initiated many cloud initiatives.
The ability to deliver new features more quickly. New products, new services, and new delivery approaches are all likely to require changes in existing applications and the business is no longer willing to wait months or years for new features. The transition to agile methodologies is now largely driven by the promise to reduce time to market, but agile alone will not suffice if legacy architectures or technologies slow teams down. New business needs are also increasingly cross-functional and require concurrent changes in many applications, putting the slowest one to adapt directly on the critical path.
Making the business more efficient. Although easy to overlook in the big scheme of things, slow, unintuitive, or error prone legacy applications can exasperate customers or cause thousands of employees waste hours every week. Modernizing to remove such issues can in one strike increase business processing capacity by a significant percentage.
Reducing IT cost. Reducing IT budget is not so common these days, but cost savings are always relevant to free up resources and budgets for more valuable work or innovations. For example, by consolidating duplicate or overlapping applications, reducing hardware and infrastructure costs, or controlling license costs increasing due to supplier lock-in. Even for applications already running in the cloud, it is becoming important to reduce use of proprietary cloud features which prevent moving to other cloud environments, and thereby reduce negotiation leverage.
Adapting to changing workforce demographics. This can mean reducing dependencies on an aging workforce or creating environments that attract the desired profiles. If several attempts to get new people onboard for a legacy application have failed, the only realistic option may be to make it more attractive, for example by introducing up-to-date technologies.

8 Critical Steps to Successful Legacy Modernization

Legacy system modernization can be complex and will be subject to the same risks that lead so many IT projects to fail (the PMI Pulse survey provides some interesting insight this topic). In addition to this complexity, we often come across eight key challenges that are particularly critical to overcome for modernization projects to be successful. Get these eight wrong, and even relatively straightforward modernization projects may see a dramatic increase in software risk.

Make informed decisions. The actual decision to launch a modernization effort for a given application is often not as easy to get right. Modernizing one application will exclude another. The first step is to get an overview of the portfolio and each legacy application’s importance for the business to know where to focus the effort. Since the cost of modernization can be significant, it is critical to base the decision on solid facts about the current state, as well as the impact and cost of the different modernization options.
Set measurable objectives. Capture and share the objectives, including the ‘why’ which justified the investment. Define clearly what the modernization effort is expected to achieve and be concrete in terms of observable impact to ensure everyone knows what to focus on and what to exclude from the project.
Lock down the scope. Experience shows that modernization projects are too often assumed to be simple and thus begin with a definition that leaves many of the details open to interpretation. To avoid this, the scope must be carefully defined, in terms of functional changes, but also any implicit or non-functional requirements. This should include the roll-out approach which must be aligned with the release of planned increments. If the modernization includes three distinct changes, it is important to decide if each should be rolled out and field tested separately, or if a single roll out approach is better.
Get the staffing right. Composing a team with the appropriate mix of knowledge and competences, past and present, and getting everyone on board can be challenging. A lack of alignment between objectives and team motivation will become costly over time. The impact on team members’ existing roles and responsibilities, and whether the change is perceived as positive or negative, will also strongly influence the degree of buy-in or resistance.
Keep development on track. Like any project, a modernization project must keep its focus but the temptation to fix more and more “past sins” as they are uncovered can be strong. Sometimes making such unplanned fixes will the right choice, other times it may have disastrous consequences for deadlines or quality. This will require management support, but practical code-level tools will also be essential to factually evaluate the impact and consequences of different reengineering or architectural changes.
Consider the impact of data. The focus is often on functionality and code, but the underlying data can have a significant impact which may only be fully understood long into a project. Persevering with inappropriate data structures may prevent necessary changes or make new code more complex. But restructuring data may also have unexpected impact on existing code or non-functional requirements like performance. Changing data may also impose costly data migration and will often reveal issues with data completeness or consistency that the modernized application may no longer tolerate.
Plan for solid validation. The business is unlikely to tolerate disruptions, and users will have little patience for interruptions in applications they depend on. Legacy applications often lack solid test suites, and even when they exist, they may not have sufficient coverage to detect regressions before roll-out. Existing tests may also need to be significantly updated to match the impact of the modernization changes.
Be realistic about the deployment effort. It is easy to assume that there won’t be much need for communication about changes, or that users won’t need training since they’re already familiar with the application. In reality, the inverse is usually true. Users who are deeply familiar with an application will get annoyed by changes that force them to change long-established habits or routines. It is also important to consider the roll-out approach when planning the release of changes. There is no single right answer, but the impact on end-users is always a determining factor for a modernization project’s success.

The pressure for faster and better application modernization is mounting, yet it’s not always easy to get it right. In my next post, I’ll provide a more detailed look at why it is particularly risky to modernize applications by rewriting them and what the toolbox for incremental approaches contains.