Considering that new gadgets and software hit the market daily, it’s important to remember that many continue to rely on decades-old legacy systems that have been upgraded, patched, and re-patched. These systems were often custom-coded when there was less data, fewer transactions and far fewer complexities. And now, these systems are feeling the strain to keep up. As a result, many CPOs, CTOs and CIOs actively look to minimalize the risk of app modernization.
To keep up with technology changes, slow-performing and resource-intensive old systems are frequently updated, but eventually, available technologies become intriguing enough to warrant consideration for an entirely new platform. The latest platforms deliver resource optimization, higher scalability, faster data speed and more security.
While the trend is for such applications to be migrated to the cloud, often that’s easier said than done. In order for the migration to be successful, the behavior of the application needs to be changed for use over the internet.
Moreover, changing application behavior often comes with risks, too. From security concerns or worries about application failures or worse – system crashes – application modernization is not without its challenges. Here are the five steps to ensure you do it right.
Step 1: Conduct an application assessment.
When you perform an application assessment for the first time, identify the legacy system that would be repurposed. Consider how user behavior has changed since the legacy system was first introduced (likely before users had mobile devices and network speeds were greatly increased) and how vulnerabilities could be exposed with a migration.
Step 2: Evaluate the data from your app modernization.
Your legacy system likely has a lot of data. For many companies, this data is incredibly valuable and relevant. In other organizations, however, it merely serves to slow down systems.
Now’s the time to consider how you’d like to process, move and store data in an app modernization project. Assign a high, moderate, low, or no rating based on the importance of the data.
A high rating indicates data that – if lost – would have a catastrophic impact on the business. Whether that would translate into lost revenue (renewal dates for existing contracts, for instance) or reputation harm (a loss of private customer information), you’ll want to identify this information first.
You’ll want to assign a rating of moderate to data that would have a serious impact on business, but one that could be restored once the crisis passes.
Similarly, a low rating should be applied to data that – if lost – would have a small impact on business. Finally, the label of noncritical is used for data that, if unavailable, would have no impact on the business.
Step 3: Assess the security threats.
With a firm understanding of what’s at risk, the next step involves making a list of vulnerabilities in your app that could be exploited to capture the data referenced in Step 2. Similar to the data itself, these vulnerabilities should be ranked according to their importance to your organization: high, medium, or low.
As technology changes, new vulnerabilities can emerge for the same threat. If threats are rated as high and medium, a security threat assessment should be repeated on a regular basis.
Step 4: Conduct a software risk assessment.
At this point, we’ve identified both the potential for threat and the risk that the exploitation of said threat would have on the business. The next step is to combine both of these into a Software Risk Assessment.
Both the value of lost data (from Step 2) and the likelihood of a data breach are plotted on a graph. Viewing the data in this manner provides teams with an analysis of which vulnerabilities offer the greatest risk to the organization.
With this table in hand, we’ve now both quantified and prioritized our risks, preparing us to move on to the final step.
Step 5: Apply data loss protection safeguards.
To mitigate the risks of application information loss and bring them to a more acceptable level (from high to low), apply practical data loss protection safeguards. To determine which tools are cost-effective, conduct a cost-benefit analysis to determine their return on investment (ROI).
Options with the highest positive ROI should obviously be considered first, whereas those with a negative ROI should be discarded. As new potential technologies become available, they should be considered, particularly if they provide higher ROI. Significant changes can (and should) change the priority of planned improvements.
Implications for Agile
In application modernization, typical strategies involve gradual migrations as development progresses. The security risks and enhancements described above can also be used to inform the preparation of project backlogs. Project components with a higher potential risk can be placed higher on the backlog and/or those that will require more work than other items (on a relative basis) may be appropriate to move lower.
