Application Modernization: 4 key factors to consider

The digital workplace, and the needs of those operating within it, are constantly evolving. Manual processes become automated as the quest for digital transformation continues. However, transformation initiatives are not just about creating new ways of automating manual processes, they are also about updating existing digital processes. Applications that once sat at the vanguard of innovation become outdated, less efficient and more of a barrier than an enabler. So, when you are planning for transformation strategy for the year ahead, don’t forget to include legacy application modernization.

What is application modernization? Simply put it is the reengineering or replacement of existing systems that no longer deliver maximum value or meet the evolved needs of the business. It’s important to remember that legacy does not mean obsolete. In many cases, legacy systems perform business-critical functions, so simply turning them off is not an option.

What follows is a short list of what we think are the four most important factors to consider when approaching an application modernization project.

1. Understand the scope of the challenge

The more integral the application is to your day-to-day operations, the more complex, time-consuming, and risky the project is likely to be. In the case of ERP solutions like Oracle Fusion Cloud Applications or JD Edwards EnterpriseOne, they are likely to impact many areas of the business. In a system with so many interdependencies, small inefficiencies can add up and become significant barriers to innovation and efficiency. The principle of continuous innovation and adoption (advocated by software vendors like Oracle) is designed to minimise this risk, but it may not always be viable for a customer to take every ESU the moment it arrives. This requires a structured approach to staying code current.

Core elements to consider here include an assessment of whether the system has become too complicated to manage, whether it is flexible enough to adapt to changing needs within the business, whether it is having a detrimental impact on customer or user experience, whether it is driving up the overall cost of ownership and whether it is exposing your business to unnecessary risk. If the answer to any of these questions is yes, it may be time to update.

2. Assess the current state of your legacy systems

Before you embark on any legacy systems modernization project it is essential to understand exactly where your current system sits and what is required to bring it up to date. It sounds like an obvious step, but is something that proves difficult to define accurately, especially if you are running one or more heavily modified versions of commercial off-the-shelf products.

Older versions of enterprise software often use outdated coding standards and an update is the ideal opportunity to identify decommissioning opportunities – to reduce your modified footprint and move closer to a standardized version of the software. The longer-term impact of a smaller modified footprint is that every subsequent update project becomes smaller and faster to execute.

When scoping an update or upgrade, visibility is essential. Where possible, compare your production (modified) environment to a pristine example of the code and the new ESU, to establish an accurate view of your modified footprint. Once this is known, a forensic analysis of every line of code, and every user setting, will help you to identify opportunities to retire redundant code and eliminate unnecessary custom objects. In real-world applications, we’ve seen customers reduce their modified footprint by up to 75%.

3. Adopt a best practice approach to application modernization

Once you have identified the scope of your upgrade or update project, there are several things you can do to reduce development times and mitigate the risk inherent in change. Any conversation about application modernization has to include infrastructure. If your systems are still located on-premises, you should be having the cloud conversation – what makes most sense to your business, on-premises, cloud, or hybrid?

Uncertainty can be a barrier to change. If you don’t have all the inhouse skills required to carry out a major project, make sure you partner with a supplier who can, wherever possible, fix the budget and timescales for your upgrade. Managing your project properly will go a long way to eliminating risk, so seek access to role-based tools for your project managers, developers and QAs.

For any major software project the devil is often in the detail. If you can address these challenges, you can reduce risk and development timelines and improve your “right first time” ratio.

  • Scan your systems for known changes.
  • Understand the interdependencies between objects.
  • View from and to releases concurrently.
  • View net change data to understand the impact of changes.

4. Understand the impact of testing on project timelines

Do not underestimate the amount of time testing takes. For major software upgrades, testing can account for more than half the overall project timeline because you need to test everything. During smaller more frequent update projects it is important to remember, you want to be testing smarter, not harder. QAs can be tempted to test everything and whilst you might think of this as best practice, it really isn’t. Why test something that doesn’t need testing? If you have visibility of all the net changes and dependencies, you should only test what needs testing. This alone can save 50% of your testing time.

The functional testing of software can be a time-consuming and repetitive task. As such, it is the ideal candidate for process automation. Once you’ve established a catalogue of test scripts you can run, repeat, edit and report on tests significantly faster, and with greater consistency, than resorting to manual testing. Discrete scripts can be combined to test end-to-end workflows and detailed documentation can make all subsequent projects smaller, faster, and smarter.

Creating an application modernization plan

Application modernization isn’t a one-time project. It’s a holistic, ongoing approach to improving your business-critical infrastructure and processes. Committing to a program of continuous innovation is the best way to make sure you continue to realise the maximum returns on your investment in enterprise software. It is important to plan for future system development, and it starts with maintaining clean, well-documented procedures, processes and code. Introducing coding and documentation standards during the modernization procedure will make things easier for developers working on future modernization efforts.

The goal of any modernization strategy should be to keep your technology systems up to date with the latest technology. Depending on your business and IT needs, legacy applications can be effectively modernized through small-scale steps such as packaging, code refactoring, or migration. However, the most important thing is to thoroughly assess your business and technical needs before deciding on your modernization strategy.

Of course, application modernization is not without risk. However, the risks associated with undertaking a transformation project often outweigh the risks of not doing so:

  • Access new features and technologies. If your competitors have access to efficiency, scalability and performance enhancing features that you don’t, you will be at a disadvantage.
  • Eliminate hidden or unnecessary costs. Old or deprecated systems generate more support tickets, this leads to lost productivity and a poor user experience. If the user experience is bad, it can impact on your ability to recruit and retain users.
  • Address legacy security vulnerabilities. Older systems are more difficult to secure as they are frequently not suited to the modern hybrid workplace. Ubiquitous access to systems poses a genuine threat to infrastructure and data security.

If you’d like to talk to one of our experts about modernization, testing and development services, get in touch.

DWS Logigear Logo
DWSLogo 257 x 191