Why modernize?
Software development and usage of software-driven products are rapidly evolving subject areas. Healthy competition means crafting applications becomes quicker and cheaper over time. The customers of such systems expect ever-more-sophisticated capabilities and user experiences out of a growing pool of competitors. Expecting users to work with outdated or inefficient software systems is a quick way to losing business and reputation. Companies that rely on software systems operating over several years or decades open themselves up to a range of potential risks, some severe, if they do not consider modernization within their overall technology strategy. Worst-case scenarios include reaching a point where the cost of operating critical legacy systems is no longer supportable, or cease functioning entirely.
Businesses need to ideally invest in the ongoing maintenance of software systems they rely on to stay competitive and keep their customers happy. Staying up-to-date with industry and market trends is simpler and cheaper to accomplish when done in small chunks, iteratively, minimizing the need for big-bang updates. At a minimum, businesses should include modernization analysis and planning in their longer-term product strategies when continuous product maintenance investment is not an option. This work helps ensure critical software is updated or replaced before problems arise, and it establishes a better position to manage any unforeseen issues.
When is legacy application modernization necessary?
Cost reduction or reaching new business opportunities are the most typical driving factors behind modernization. When a legacy system becomes more costly to operate versus creating an updated equivalent that implements the same functionality, businesses can justify modernization investment as future cost savings. Similarly, suppose the cost of extending a legacy system to address a newly opened business opportunity outweighs that of the opportunity itself. In that case, businesses may want to look at modernization efforts to expand their market reach more cost-effectively.
However, complete system replacement is usually a last-resort option, as it is the most complex and costly modernization strategy available. Businesses ideally want to avoid such a scenario by engaging in ongoing modernization efforts to reduce the complexity of any updates needed and spread any cost over a longer period.
Degrees of software modernization
In some cases, forming an entirely new product creation workstream to replace an outdated system may be the best course of action. However, legacy system modernization does not have to be such an all-or-nothing affair. Completely replacing an existing system can be cost-prohibitive and is usually only needed if a business paid insufficient attention to the system’s ongoing maintenance over its lifetime.
Properly appreciating the full lifecycle of a software system can help plan ongoing maintenance efforts that won’t break the budget. Before launch, up-front development costs account for most of a product’s budget; however, investment does not end when a product reaches the market. Infrastructure and hosting costs are required to operate the system, and maintenance or bug-fixing activities may require further software development.
Ongoing maintenance
Some form of iterative maintenance is the ideal modernization strategy as it keeps ongoing costs low and allows quicker turnaround for other essential fixes. Typically, post-launch development activities include fixing any issues users may encounter, feature improvement, and new feature development, where required. This period is when delivery teams can conduct incremental upgrades to keep the system up-to-date alongside other bug fixes and improvements – all integrated within a single software delivery lifecycle (SDLC). These upgrades may take the form of library, middleware, OS, and infrastructure updates.
Allocating time and budget for this extra work – while not obviously nor immediately beneficial to customers – will help keep future maintenance costs down. However, this work can include significant benefits in applying security patches to the application and its dependencies. Not every system update will be due to security reasons, but reserving the capacity to perform them promptly is vital when budgeting for a project.
Operational steady-state
When active ongoing maintenance is no longer viable on a system, it may fall into a period of purely operational overheads (hosting, bandwidth, etc.). Assuming the system is still profitable or serves a useful purpose in other ways, this course of action can be perfectly valid. Businesses spend the minimum required to operate the system and just let it continue to run, doing its thing.
While on paper, this state is the cheapest to run — and indeed operational costs tend to reduce over time with new efficiencies — throughout this period, the system will be accruing a hidden “modernization opportunity cost.” The longer a system is left to run without day-to-day oversight, the costlier it becomes to update once a business eventually revisits it. For many companies, this is a non-issue; they are content with letting things run as-is and see themselves as unlikely to need further work on their systems. Suppose the systems are left to operate beyond a certain date or revenue level. In that case, the net profitability of running the system at its lowest maintenance cost point will outweigh any potential cost of updating or replacing the system if such an eventuality occurs.
While appealing on purely a cost basis, this option puts organizations in the least responsive state when dealing with any unforeseen issues with the system. Attempting to resolve problems with zero capacity is highly disruptive and can significantly impact other business areas, or in the worst case, the company’s reputation with its customers.
Isolation and abstraction
Assuming a system still generates revenue, or critically supports other revenue-generating areas, at some point, a company may want to revisit the system to make some improvements. Businesses may seek such improvement work for a variety of reasons. Enhancing or extending some functionality, disabling or removing functionality that is no longer profitable, integrating the system with other systems to support expanded or more optimized workflows, or meeting new business opportunities are among the many reasons for software uplift.
Complex systems comprised of several independent or codependent sub-areas inevitably have some areas of relatively higher and lower implementation quality and overall value. It is often most pragmatic to only focus modernization efforts on the higher-value components to keep costs as low as possible and avoid any disruption to the rest of the system. Areas within well-architected systems should already be properly isolated and able to be worked on independently. However, “big ball of mud” legacy systems will need additional work to identify independent areas and separate them. Isolation and abstraction could create interfaces between different subsystems within a single application or go even further, isolating subsystems into independent microservices.
With a system decomposed into isolated subsystems, modernization work can occur on the highest value components with minimal knock-on impact to other areas. A robust automated test suite is extremely valuable when performing this sort of refactoring to confirm that the updates are not regressive while also increasing delivery velocity. Creating a test suite in systems that lack it before performing further modernization will pay dividends for all future work, so the extra effort to create such a suite is by no means wasted effort.
Backward compatibility – maintaining or breaking
When modernizing certain subsystems within a broader application ecosystem, the interfaces between the affected areas and any of their dependents require careful consideration. Understanding data flows between areas is key – APIs, feeds, first-party, and third-party integrations should all be factored in. Usually, backward compatibility is a strict requirement, so rigorous testing is needed to ensure a newly-upgraded component still provides expected functionality through the same interfaces as it did before.
However, changes in requirements could simplify things here – specific dependencies may no longer be needed and can be removed. Other dependencies may require simultaneous work, meaning strict backward compatibility becomes an optional requirement between the affected systems. Breaking compatibility needs careful management to avoid introducing new issues. However, when properly managed, it can open up simplification opportunities such as disabling unneeded functionality or replacing system pieces entirely to implement alternative functionality.
User experience
Modernization has many benefits across the full application stack. However, it is usually most visible to end-users of the system, and consequently, focussing on the ways users access the system may provide more direct value. Businesses with limited modernization budgets may want to limit the focus to updating a system’s user interface to modern standards while keeping the existing backend system intact. However, this work assumes that the backend interface is already sufficiently decoupled and accessible (such as through a web-based API).
Focussing only on the UI means investment can also target new platforms if desired, such as web or mobile. Opportunities may also be present for federating the system into broader application portals or platforms that give users access to new cross-product workflows using already-operational applications. In all cases, the strategy around this type of work is to provide a better overall experience to users – possibly even one that can justify an upsell opportunity, making the modernization project pay for itself.
Data migration
Information is typically the real value center of a technology product, not the software itself. Modernization efforts may focus exclusively on data, looking to migrate it out of legacy systems into more valuable strategic repositories. If a business can migrate the data and any processes required for its maintenance, it can sunset other legacy systems previously responsible for operating on the data.
If this type of migration is too complicated or if the underlying systems and the data they provide are too critical, businesses may choose to keep the legacy systems running (possibly for a limited time only). The old components can continue to operate while teams implement new integration flows to expose the data through a more modern format or to feed it into parallel systems during a prolonged migration until the eventual replacement is deemed complete.
Rebuilding
Rebuilding an application from scratch is usually the last resort when it comes to modernization. It involves the cost of a new product build and extra complexities around migrating users and data off the old system. Rebuilds are typically only done when maintenance or enhancement of legacy systems can no longer meet current requirements or are simply too costly to do so.
There are positives in considering a full rebuild. Creating a new product can mean accessing new or previously unattainable opportunities, righting any wrongs with the old system, reaching more customers, achieving greater user engagement, and focussing on the most valuable areas of a product given real-world feedback. These points can create a step-change in product experiences between old and new, creating more engaging experiences for clients while allowing organizations to increase revenue and move away from their legacy systems simultaneously.
Extra dimensions
While complicated enough, the incremental modernization strategies described here are made even more challenging given extra considerations that businesses face. These can come from both pre-planned and unforeseen directions, adding to the set of risks organizations need to deal with when updating their software.
Security & other legal requirements
Security vulnerabilities or changes in the law governing operating regions may force modernization efforts on an otherwise unprepared organization. Legal changes are usually known ahead of time, and governing bodies afford organizations specific grace periods to plan for and update their systems to meet the new requirements.
However, security issues are usually unforeseen, preempting other feature work and putting organizations on the back foot when dealing with them. Having some capacity allocation flexibility as part of ongoing product maintenance investment can help meet such ad-hoc security fix needs without disrupting other work.
Internationalization & accessibility
Businesses may have desires to expand their product’s footprint to reach a more diverse range of customers and possibly enter new regional markets with different language requirements. Applications not designed with internationalization and accessibility in mind from day one will require retrofitting to include additional presentation capabilities. They will need further testing to validate the expanded set of language or display formats. Depending on language skills within the organization, external translation teams may also be required to provide relevant language sets – and the text bundles for all languages need updating for any future presentation changes. This type of modernization work is not limited to legacy applications – any system designed for presentation within a single language market will need the extra presentation features added.
Infrastructure
Legacy software typically comes with some form of legacy infrastructure. While increased commoditization in infrastructure means operations teams can upgrade and replace hardware independently of software improvements, this is only true up to a degree. Licensing restrictions or software runtime requirements may necessitate particular hardware configurations for operation – and these scenarios typically mean cost increases over time due to a captive market.
Organizations likely require software modernization when looking to update their infrastructure strategy to reduce costs. Typically companies look to reduce or eliminate their in-house hosting and move to third-party offerings, ideally using a wide range of commodity compute and storage offerings from cloud services providers. While infrastructure virtualization can help isolate legacy software and allow more upgrade flexibility, organizations need to design their applications specifically for modern cloud services to use them effectively.
Delivery Platforms
Software designed before significant shifts in delivery platforms (desktop to web, web to mobile) require extra consideration when updating to determine which platforms the modernized system should target. User’s expectations on how they access their software shift over time as new technologies become available. For example, this means what may still be an entirely appropriate desktop application could be considered limited and inflexible by users compared to a web-based alternative that they can access from anywhere. While it’s impossible to predict where platform evolution will end up, businesses can make certain hedges and target a common subset that is likely to provide a degree of future-proofing. Currently, this means targeting web platform technologies that can provide both desktop and mobile delivery avenues, and likely others in the future.
Third-party dependencies
Software systems are rarely built entirely from scratch and instead use external dependencies to provide scaffolding, middleware, and other utilities common across many application types. Every dependency has its own lifecycle, including the possibilities for security patching, major breaking changes, or abandonment/discontinuation – modernization work that includes software patching needs to factor all this in.
Companies that use commercial dependencies in their software systems may wish to engage in vendor support contracts to ease upgrade paths. Most applications built today typically depend on community-managed open-source components. Some form of dependency assessment and standardization may help manage this complexity, including providing suitable upgrade patterns or replacements where needed. This oversight is especially valuable in larger organizations with many systems that rely on common sets of external dependencies. Ideally, businesses can modernize dependencies in a single system, then apply a standardized update process to the remaining dependent systems.
Skill Sets and workforce
Labor markets evolve alongside the technology industry, meaning technologies that were once commonplace may no longer be economically viable to support today, or the skill sets required may be lacking entirely. Part of any modernization strategy must consider available market skill trends and availability to ensure the target system state is supportable through a broad talent pool. Skillset availability is likely part of an organization’s overall technology strategy when creating and supporting applications through in-house teams, as this feeds the technology division’s hiring strategy. Costs are a big factor here again, with many options for cost reduction either through internal means across regions or contracting to external providers.
Managing legacy application modernization
As with greenfield development projects, modernization efforts can be large and costly undertakings in their own right. Such efforts come with complexities and risks beyond that of a new build, which can significantly impact the time and budget needed to modernize fully. Rigorous oversight is needed to prevent projects and budgets from spiraling.
When considering modernization, decision-makers need detailed up-front analysis to understand all available options and make the best-informed choice on which strategy will most benefit their business. With a chosen modernization strategy workstream planned out and implementation underway, continuous risk assessment and management becomes critical to dealing with unforeseen complexities and ensuring successful delivery. Being flexible in decision-making, striving for simplicity, and keeping deliverables as small and iterative as possible are vital in making modernization projects achievable. Having a delivery partner with expertise in modernizing enterprise software systems also greatly helps!