When someone says they want to modernize an application for the cloud, what exactly do they mean? Users have one perspective: They hope modernization brings improved experiences, higher reliability, faster performance, and, ideally, more frequent feature deployments. Architects, software developers, and devops enginees have different answers as to what app modernization means. That’s because there are several technical approaches to app modernization, and the optimal choice isn’t always obvious.
For example, a workflow app used by dozens of users written in the latest versions of Java and MySQL may be an easy lift and shift to a public cloud. This approach requires little code rewriting but likely requires configuration changes, updating the CI/CD, and rerunning test automations. On the other hand, if that same application is written in Cobol and runs on a mainframe, there’s a good chance it will need an overhaul before running in the cloud.
There are still several technical options in between lift and shift and a complete overhaul; these are known as the 7 Rs of cloud app modernization. There are minor differences from one source to another, but they represent the top-level modernization options well.
Factors to consider
Organizations have hundreds to thousands of legacy applications, apps with significant technical debt, and others with user or business benefits in a migration. Architects and technical leads often use different modernization approaches depending on the business need and technical challenges.
The first issues to consider are the impacts on business operations and users. Mission-critical, higher-usage apps will require different technical approaches than apps used episodically. Every modernization will require communication with users, testing, and training people on workflow changes.
Nitha Puthran, senior vice president of cloud and infrastructure at Persistent Systems, provides an overview of some of the business factors in selecting app modernization approaches and road maps. She says, “One of the biggest challenges organizations face is identifying and knowing which applications should be lifted and shifted, refactored, or rewritten and in what order. App modernizations require careful balancing speed to market with scalability, cost optimization, mitigating future technical debt, and operational downtime.”
Garth Fort, chief product officer at Splunk, shares how devops teams benefit from app modernizations. “There can be many benefits to a cloud migration, including reducing costs, improving security and resilience, and making it easier to scale service delivery for customers,” he says. “For devops teams, it can improve staff agility and productivity, enabling teams to focus on the customer experience.”
Devops teams and architects should review each app’s business, technical, operational, and security factors and then consider these approaches to app cloud modernization.
Retire apps that are no longer valuable
Still have apps to support dial-up connections, faxes, or other legacy ways of doing business? When apps perform functions that are no longer needed, the appropriate modernization strategy is to retire them.
Sometimes the decision to retire an app is clear cut: Business users have signed off on shutting it down, or retiring the app has no impact on business operations. But even when apps have low usage or perform a business function, their business value should be weighed against the modernization and ongoing support costs.
Amit Patel, senior vice president at Consulting Solutions, says, “To improve user experience, companies should consider the retire strategy. Quitting outdated legacy applications creates improved efficiencies, leading to a better user experience for your customers. The reduced attack surface also leads to stronger security.”
Replace apps with SaaS, commercial, or open source options
Fort explains that replacement may be appropriate when proprietary solutions are no longer necessary. He says, “Replacing an app is when an organization stops relying on its own custom-built applications and migrates towards prebuilt third-party applications provided by a vendor and hosted on a cloud.”
Examples include customer relationship management tools, content management systems, or customized workflow tools developed when the equivalent SaaS, commercial, or open source solutions at the time didn’t meet business needs. Today, business users may find better and cheaper third-party options compared to their proprietary one that needs updating.
Relocate the app to the cloud
Apps meeting business needs and running on supportable software stacks may be candidates for relocation. Instead of running them on dedicated hardware or virtual machines, the architecture and devops team find technical and business benefits by moving them to cloud environments. For example, it may be easier to configure dev and test environments, autoscale production, and configure disaster recovery environments with the app running in a public or private cloud.
But Bob Quillin, chief ecosystem officer at vFunction says, “Migration does not equal modernization.” He explains, “There are devops benefits to be gained with the lift-and-shift migration method. Almost all companies achieve some short-term gains, but the mistake that many tech leaders make is believing that the work stops there.”
Relocation may provide infrastructure flexibility, improved security, and cost reduction, but it doesn’t address issues with supporting the app and underlying code.
“Here’s the reality: A monolith in the cloud has all the same thorny issues it had on-premises—slow engineering velocity, lack of scalability, and difficult maintainability,” Quillin explains. “This phase is known as ‘lift-and-shift regret’ as costs rise and cloud benefits are still out of reach. To bust this myth, migration must be viewed and planned in the context of a larger, more strategic modernization strategy.”
Replatform components that have operational benefits
Many interpret “lift and shift” as a migration option that requires minimal involvement from the development team and won’t need code upgrades or major configuration changes. The hope is to get some benefits of migration without the added work and costs of reengineering the code.
But between the code and the infrastructure are database platforms, frameworks, and components—and opportunities to replatform them during the migration. Although a replatform generally requires developers, it may not require substantial code changes, especially when commodity, standardized, or near-equivalent platforms are swapped into the stack.
Tomer Shiran, cofounder and chief product officer at Dremio, shares one example. “Rather than lift and shift a legacy data warehouse or data lake to the cloud, a cloud migration introduces opportunities to adopt open lakehouse architectures and data mesh approaches to data management.“
Cloud architects may modernize data warehouses and data lakes to deploy them as public cloud services offering operational and cost benefits. Other replatform options include migrating service buses, moving to an organization’s standard CI/CD tools, or changing content delivery networks.
Reuse, refactor, or rebuild applications that offer longer-term business impacts
Once architects and devops teams decide to upgrade code as part of the app modernization, they have several options:
- Reuse the app’s existing data models, services, and APIs but redesign the user experience.
- Refactor code to improve performance, security, maintainability, and other nonfunctional upgrades.
- Rebuild modules and capabilities to improve functionality, address defects, or reduce technical debt. Some will rearchitect monolithic applications into microservices.
Which approach is best for your application? Patel shares his point of view: “The refactor and rearchitect strategy, while the most expensive approach, should be considered when companies want to move toward a more agile devops model. This strategy also assists with continuous innovation, ultimately helping increase performance.”
Devops teams can also consider phased approaches. For example, they may first rehost apps running on supportable platforms to get the operational benefits of running them in private or public clouds. They can then consider reusing low-use apps that aren’t upgraded frequently and rearchitecting other apps where there’s a business need for frequent enhancements.
App modernizations aren’t free of costs or risks. For organizations with thousands of apps, it can take years to fully modernize the portfolio. Devops teams and architects must use a lens of practicality and review all the factors before selecting an app’s modernization strategy.