What are the main application modernization strategies?

• 7Rs of app modernization
• Rehosting and rehosting examples
• Replatforming and replatforming examples
• Refactoring/rearchitecting and examples
• What refactoring involves
• Replacement and examples, plus when to replace
• Considerations for what app mod strategy is best

The 7Rs of application modernization are an evaluation framework that helps technology leaders determine and prioritize the right modernization approach for their organization. It’s an important framework because not every application should be modernized the same way. Some systems should be retired, retained, migrated, improved, rebuilt, or replaced based on business value, technical condition, and future importance. So, rather than unilaterally applying the same modernization approach to every application, the 7Rs framework helps organizations choose the right strategy for each system.

Rehosting, often called lift and shift, moves an application from its current infrastructure to a new environment. For example, the application might move from an on-prem data center to AWS, Azure, or Google Cloud. When rehosting happens, there’s usually no significant changes made to how the application is built or how it works.

Organizations choose rehosting when they need to:

• Exit a data center quickly and meet timeline-driven migration goals
• Reduce infrastructure management overhead or adapt to workforce changes
• Accelerate cloud adoption so applications can be accessed on demand and scale up during peak demand and down when demand draws down
• Improve scalability so an application can handle more users, transactions, and workloads without degrading performance

The primary advantage to a lift and shift project is speed to the cloud. Because application code remains largely unchanged, migration projects can often be completed significantly faster than more transformative modernization approaches. The challenge, though, is that rehosting doesn’t address technical debt, an app’s architectural limitations, or inefficient application design. That’s why many organizations use rehosting as a first step before deeper modernization efforts. Rehosting as a first step in application modernization aligns with an enterprise’s need for balancing speed and cost while minimizing operational disruption.

A retailer runs a customer loyalty portal on virtual machines in its own data center. The application works well, but the hardware is aging and expensive to maintain.

Lift and shift approach:

• Existing Windows servers move from the corporate data center to Amazon EC2
• The application code remains unchanged
• The database moves to an equivalent cloud-hosted environment
• Users see little or no difference  

Why rehost?
The company wants to exit its data center quickly and reduce infrastructure management costs without funding a major redevelopment project.

A manufacturing company has a custom HR application used by employees for benefits enrollment and time-off requests. The application is stable and meets business needs.

Lift and shift approach:

• Application servers move from VMware infrastructure to Azure Virtual Machines
• Existing networking and security configurations are replicated in Azure
• No major code changes are required
• Employees continue using the application as before

Why rehost?
The organization wants to improve disaster recovery and reduce dependence on aging on-premises infrastructure while minimizing migration risk.

An insurer operates a claims-processing application that was built years ago but still supports critical business processes.

Lift and shift approach:

• The application moves from an on-premises Linux environment to Google Compute Engine
• Existing middleware and application components remain intact
• Infrastructure is recreated in Google Cloud
• Business workflows stay unchanged  

Why rehost?
The company needs greater infrastructure scalability and resilience but isn't ready to invest in a large-scale modernization effort such as refactoring.

Replatforming involves moving an application to a more modern platform while making limited changes. Those changes scope to performance, scalability, security, or operational efficiency improvements. Unlike rehosting, replatforming introduces targeted improvements without requiring extensive code changes.

Organizations often choose replatforming when they want to:

• Lower operational costs  
• Improve reliability and resilience  
• Reduce infrastructure complexity  
• Enable future modernization efforts  

Replatforming is particularly attractive in today's environment, where many enterprises are focused on cloud optimization, FinOps, and operational efficiency rather than large-scale application rewrites.

Examples or replatforming include:

• Moving from self-managed databases to managed cloud databases
• Containerizing applications
• Adopting Kubernetes or managed application services
• Modernizing middleware and runtime environments

A state government agency runs a citizen case management application on aging on-premises servers. The application is still effective, but the infrastructure is costly to maintain. It’s also difficult to scale during periods of high demand.

Replatforming approach:

• Application servers move to Azure Kubernetes Service (AKS)
• The legacy database is upgraded to Azure SQL Managed Instance
• Authentication is integrated with Microsoft Entra ID
• Core application functionality remains unchanged  

Why replatform?
The government agency wants to improve reliability and security while avoiding the cost and risk of refactoring a mission-critical system.

A pharmaceutical company uses a custom application to manage clinical trial operations and site coordination. The application supports critical business processes but struggles with performance, scalability, and operational overhead.

Replatforming approach:

• The application is containerized and deployed on Amazon EKS
• The database moves to Amazon RDS
• File storage is migrated to Amazon S3
• Existing workflows and business logic remain largely intact  

Why replatform?
The company wants better scalability, improved operational efficiency, and a modern foundation for future AI and analytics initiatives without disrupting active clinical programs.

An electric utility operates an outage management system (OMS) that supports grid operations, outage detection, restoration workflows, and customer communications. The application is mission-critical, but it operates on aging middleware and infrastructure that make it difficult to integrate with modern grid technologies and maintain resiliency.

Replatforming approach:

• The application moves to Google Kubernetes Engine (GKE)
• Legacy middleware is replaced with modern API management services
• The database is migrated to Cloud SQL
• Existing outage response processes, dispatch workflows, and user experiences for operators and field crews are preserved

Why replatform?
The utility wants to improve system performance, resiliency, and integration with advanced metering infrastructure (AMI), distributed energy resources (DERs), and customer communication platforms. It also wants to extend the life of its proven operational system while avoiding the cost, risk, and disruption of a multi-year replacement program.

Refactoring and re-architecting fall into the "improve what you already have" application modernization bucket. They’re part of the same modernization motion; they’re just different in the depth of execution. The difference is largely one of scope: Refactoring may focus on code quality and maintainability, while re-architecting involves more substantial changes to how the application is structured, integrated, and deployed. This is why they’re, typically, both refactoring and re-architecting are grouped together under Refactor rather than treated as separate Rs.

Common refactoring activities include:

• Breaking monolithic applications into services
• Improving code quality
• Eliminating technical debt
• Modernizing APIs
• Improving test automation
• Increasing maintainability  

If we zoom in on moving from monolithic architectures to microservices, for example, and look at monoliths vs. microservices in the insurance industry, a traditional policy administration system might contain customer management, underwriting, pricing, billing, claims integration, and document generation—all running inside one large application.  

In a refactoring transformation, those capabilities may become separate services. While this may add architectural complexity, teams can operate with new focus, confidence, and agility to update underwriting rules, launch new products, or improve billing without redeploying the entire platform. Refactoring and re-architecting are becoming increasingly important for piloting and scaling high-value, AI-ready applications and human+AI workflows.

Refactoring means creating a new application that delivers the same core business capabilities as the existing system but uses modern technologies, architectures, and development approaches. Refactoring is often considered when an application directly impacts customer experience, revenue generation, operational differentiation, or future innovation initiatives.

A refactor typically involves things like:

Organizations usually refactor applications that are strategically important but too constrained by technical debt, outdated architectures, or unsupported technologies to justify incremental modernization.

A large health system uses a custom-built patient marketing platform created 12 years ago. The platform supports robust marketing work with CRM integrated campaign management, patient segmentation, email and SMS outreach, physician referral marketing, appointment conversion tracking, and. marketing analytics.

The system still works, but there are a number of drawbacks:

• Campaigns take weeks to launch, not days (or hours)
• Data updates occur overnight, not in real-time
• AI personalization isn't possible, hi {{firstname}}, is about it
• Mobile experiences aren’t great for patients
• Security controls are outdated and PII exposure risk is real
• Regulations are about to change (again)
• Integrations break frequently
• Developers do not have capacity to touch the code

Here are a few before vs. after examples for a healthcare marketing platform refactor.

Naturally, marketing performance improvements further the healthcare system mission, too. With better patient experiences and high-performing marketing systems, outcomes also include:

• Optimized provider scheduling for lower burnout and healthier quality of life
• Fewer emergency interventions for a lower cost of care
• Better patient experiences, healthcare outcomes, and community vitality

Here’s a simple rule of thumb:

• If the business process is still valuable, but the infrastructure is outdated, replatform.
• If the business and technology model both need transformation, refactor.

Replacement means switching from maintaining a custom-built software application to a commercial Software as Service (Saas) product that does the same job.

Here are some common examples of homegrown applications vs. “off the shelf” and commercial SaaS:

Organizations should consider replacement when a commercial solution can deliver required capabilities more efficiently than maintaining a custom application. After all, maintenance is its own opportunity cost. As enterprise leaders continue to prioritize vendor consolidation, operational efficiency, and measurable ROI, SaaS replacement remains one of the fastest ways to reduce technical debt and ongoing support costs.  

Common replacement software application candidates include:

• CRM systems
• Human capital management platforms
• Finance and ERP applications
• Service management tools
• Collaboration platforms

Replacement is often appropriate when:

• The application is not a source of competitive differentiation
• SaaS products provide mature functionality
• Maintenance costs are high
• Security and compliance requirements can be met by vendors
• Internal development resources can be redirected toward strategic initiatives

The most successful modernization programs focus less on technology migration and more on aligning application investments with business outcomes, operational resilience, security requirements, and future growth objectives. Modernization succeeds when every application has a deliberate strategy—not when every application follows an expected, familiar path.

Slalom's approach to evaluating a modernization portfolio is less about starting with technology inventories and more about identifying where legacy constraints are creating business friction, risk, or limiting future growth. What matters to your business, and what's blocking the outcomes you're after?

The portfolio is then evaluated across three legacy modernization domains:

1. Application modernization
2. Data modernization
3. Mainframe modernization  

These are treated as distinct domains, but interconnected portfolios. A customer may have all three issues, but Slalom generally expects modernization initiatives to begin with the area creating the most immediate business constraint.

Our approach to portfolio evaluation follows a seven-step evaluation framework:

1. See the target. Establish clear, long-term objectives and measurable outcomes.
2. Identify modernization signals to suss out where investments should focus first. We look at signals in the market and regulatory environment, customer experience, your operating model, and workforce as inputs.
3. Assess business impact before technical complexity. We already know the problems exists and that legacy systems are painful. We want to examine where business capability is blocked, what risk is growing, and what value can be unlocked.
4. Categorize portfolio assets into modernization pathways: application modernization, data modernization, and mainframe modernization. This approach helps us stress test assumptions and align all stakeholders around urgency and priority.
5. Evaluate modernization readiness in four domains: strategic readiness, operational readiness, technical readiness, governance readiness.
6. Determine the modernization approach, and don’t assume that cloud migration is always the answer. It’s not appropriate to force every portfolio toward a single destination architecture. There are pathways to modernize ON (stay and improve), modernize WITH (hybrid), and modernize TO (full migration to cloud-native environments).
7. Use AI to accelerate portfolio analysis. Portfolio discovery that once took months can now be accelerated—dramatically—through AI-supported assessment while still grounding results in deterministic validation and human expertise. We leverage advanced, secure, and compliant AI-driven tools, agents, and automation workflow to speed up codebase anaylsis, documentation, and implementation.

Our customers are modernizing mainframes, applications, and enterprise data with results that include:

• 2–4x faster delivery for a U.S. education agency through AI-enabled engineering
• $100MM projected savings and a 60% reduction in refactoring time for a global technology leader
• 30% reduction in technical debt and $1.1MM reduction in annual mainframe operating costs for an iconic manufacturer and retailer
• 66% lower compute costs and 50% faster workflows for a major federal healthcare agency
• 5–9x engineering velocity increase using AI-accelerated modernization for a leading financial services provider  

Our global team of experts partners with Amazon Web Services (AWS), Google Cloud, Microsoft, Salesforce, Snowflake, and over 700 of the world’s leading technology providers to support modernization across complex enterprise environments. Ask us about a modernization and AI-readiness assessment for your team.