Download the paper here.

Legacy software anchors organizations to the past, whilst the cloud beckons them towards a future of innovation and agility. Embracing the challenges of migration unveils the untapped potential of accelerating businesses into the digital age. 

If the future looks so rosy, why is it that organisations take so long and are so reticent to address the issue of legacy software?  

In short, the projects are seldom simple. Very hard to predict all the issues upfront. You could argue that the overriding factor is to ensure you have the right team between the business and the Software Development Partner in place so that as and when unforeseen issues arise, they can swiftly and efficiently apply themselves to resolving the issues. 

This article provides a perspective on some of the business issues we see companies facing and the resulting challenges presented by such projects. 

Probably more important we give some consideration of how we try and minimize these risks. Far from being the disciple of this, it is a view based on our own experiences. 

The Need for Application Modernization 

Business continuity Risk is probably THE largest case for acting on this topic.  Technical Debt and the resultant security vulnerabilities together represent a potentially huge exposure in terms of potential business interruption. The commercial impact of core systems being down for any length of the period is almost unthinkable. 

• As operating systems, databases and applications evolve to the point that they are no longer supported, there is huge pressure placed on organisations, especially by the large technology providers that they need to upgrade to the latest versions of software or risk running unsupported software. This is an endless process with increasing amounts of pressure being placed on businesses. Not only do you need to consider the specific piece of software going end of life, but also the other software and services that exist in your ecosystem. For example, new authentication tools may well have issues working with old applications. 

• One of the most significant risks associated with older versions of software is the increased security vulnerabilities. Unsupported software will not be kept up to date with security patches, leaving organisations exceptionally exposed to security risks. 
• Not only are security vulnerabilities a concern but there is also an interesting balancing act between the cost of moving to new software vs a higher cost to maintain older software. As a piece of software moves through its lifecycle, the number of skills in the market familiar with this technology will mirror this life cycle. What was once very popular and every developer was trained in it 10 years ago, will not be what developers today are training in.  
• An area that many businesses don’t see until it is too late is that with real legacy software where the original team of business owners and Developers have long since departed, the remaining team can very easily lose track of the business Intellectual property that is a key part of the enterprise application. This is the business logic and processes built into the application. Typically, this will be consumed into a vast amount of source code, which more often than not is poorly documented and almost impossible to navigate. This in itself is a significant risk to organisations. 

When you add the business requirement to move forward with updated processes, entering new markets, new products etc – you have a very compelling business case. 

That said, it doesn’t negate the fact that these projects can often be steeped in risk. As part of the business case, we believe one needs to not only consider the commercial upside of modernization but equally important is the cost of not doing it. Whilst the projects can be complex, when you compare this to the cost to the business of security risks and or significant downtime in your core systems it starts to put things into perspective. 

Now more than ever, we see that “business velocity “ or business momentum has become critical to survive in the modern digital world. A “do nothing” strategy of yesteryear, probably isn’t an option looking forward. 

So, it is all about trying to identify as many of the risks in such a project and ways to mitigate them as far as possible.  

Challenges of Application Modernization Projects 

 In our experience, the challenges tend to fall within 3 headings: 

1. Projects not being set up for success. 
2. A lack of appropriate upfront investment into Discovery and Requirements 
3. A lack of technical resources to support the project. 

Talking to Roger Brown, Managing Director of CGS,  and experts in Modernization he shared some of the main challenges they are finding when speaking to customers: “Issues we frequently encounter include Legacy Complexity, Skill and Knowledge Gap, Integration and Compatibility, as well as Testing and Quality Assurance. Moreover, modernization efforts must adhere to current security standards and regulatory compliance mandates.” 

Take a look at each of these in turn: 

Projects not being set up for success. 

All too often in our experience, the mindset is that the Cloud will automatically be faster and produce a cost-saving compared with the legacy of today. Unfortunately, in some cases, this is like comparing apples with pears. On-premise performance is not comparable with cloud performance and especially where you end up with a hybrid solution where some of it remains on-premise and some of it resides in the cloud. As is so often the case, the devil is in the detail. 

In these complex projects, it is very easy for your Software Development partner to be blindsided by a lack of critical information. Compound that with a perception by the business that the new Software Development Team has a magic wand that will cover up all the holes that exist as a result of the historical issues created by the brain drain of talent and legacy software.  

In our experience, it is these issues that so often lead to difficulties and indeed failures in such projects. Our advice is to say that whilst you can detail where most of the issues might arise in a specific project, it is healthier to take the approach that there will be unseen issues that come up. In this case, the critical success factor is to ensure that together your business team and Software Development Partner can sit down and work through the issue(s) quickly and efficiently to mitigate these issues.  

A lack of appropriate upfront investment into Discovery and Requirements 

The non-sexy part of these projects is the planning upfront. Short-circuit these parts of the process at your peril. The Discovery Phase ensures you have as complete a picture as possible of the existing legacy system. This is a hugely detailed piece of work to fully understand all the dependencies and interdependencies with your existing system. The good news is that there are now software tools that can help reduce the time in this exercise. 

From there, we tend to work very closely with our clients to complete detailed functional requirements. This is where you have the debate of whether you are replacing like for like or incorporating an update to processes/functionality as you migrate. Purely from a development perspective, our experience is to try and minimize the number of variables you change at any one point, such that in the ideal work you are initially doing a straight like-for-like comparison of the existing functionality. This makes it much easier in testing to ensure you get the same outputs as the existing software. All that said, we are not always in an ideal work and sometimes you need to make the shift in the business process in parallel with the technology shift.  

Working very closely between the business and technology teams at this phase, not only delivers the most robust outcome for the client, it starts to tease out likely future issues around communication styles, political agendas, and cultural differences. All the things that will impact the successful completion of a complex project of this nature. 

A lack of technical resources to support the project. 

 This Discovery and Functional requirements phase will hopefully throw up whether both sides are resourcing this project appropriately.  

You will need an adequate amount of time from actual business users to input, test and review the solution for each of the roles identified in the software solution.  It is not uncommon to find it hard to get the necessary time and support from business users that cover all the roles in the application. 

A joint, fully integrated team would certainly be something that we would strongly recommend to our clients. And ensuring the team has the authority for decisions affecting the build.  

Something we see from time to time, are Clients that inadvertently try and cut corners when it comes to technical resources. This often leads to issues downstream. Your UAT and Development Environments must be equivalent to the Production environment, otherwise, something that successfully passes a User Acceptance Test (UAT) may well fail in a live environment that is running different hardware and software. 

Some Tips to Mitigate the Risks 

In summary, the key question is how we go about trying to mitigate these issues in Client projects: 

1. Assist with the Business Case – In some cases, we create the business case, in others, we heavily input to it. The key point here is that in our experience the movement from legacy to the cloud is a risk and continuity play and not a cost-saving business case. That said, using the SCAD Software development approach we would expect our clients to see a cost saving on the ongoing maintenance and management of the solution across multiple years. Being involved at this stage ensures that we are all aligned with the business case which focuses both teams on the business outcomes the client is looking to deliver.
2. Fully invest in the Discovery and Functional Requirements –  

As detailed above, the feedback we get from clients is that the time we invest in this with them is always a very valuable experience as you get the one-time opportunity for the business and technology teams to sit around the table and discuss the optimal way for business requirements to be delivered through the technology. 

1. Flexible Approach 

We don’t have a one size fits all approach to legacy modernization. Each Client and each scenario is different. We could say that we always aim to replace like with like in terms of functionality, but the reality is that this sometimes isn’t possible – so you need to be flexible to come up with a plan that ensures the success of the project. 

An area we do focus on with our clients is the change management associated with the new application. Sufficient resources and costs must be dedicated to ensuring there is a proper change management programme to accompany the implementation and operationalization of the new technology. In clients where this hasn’t happened, there is always a direct impact on the success and quality of the overall project. 

2. Time and Complexity

Our approach to building software delivers applications that can be as much as 40% smaller in terms of code size. This approach is very focused on removing any complexities that are not required. It also delivers an application that is much easier to update and enhance, as we make extensive use of metadata rather than programming languages. This doesn’t negate the complexity of the overall project, however, it does help to simplify the technical delivery. 

Finally, Roger Brown encapsulated the situation very succinctly “These projects necessitate significant alterations to processes, workflows, and systems. Successfully managing such changes, obtaining stakeholder buy-in, and ensuring seamless transitions without disrupting critical operations demand meticulous planning and effective communication.” 

– By Andy Fensham, Founder of SCAD Software