Application Replatforming: A Guide to Critical Considerations

Many organizations face challenges when modernizing their production-ready applications for the cloud-native world. Various application modernization strategies vary in terms of execution complexity, short-term and long-term costs, and potential business impact.

The simplest approach is rehosting, often called “lift and shift.” The practice involves moving the application to a new infrastructure (like the cloud) without changing its code. It’s quick and easy, but it may not take full advantage of cloud capabilities.

Replatforming offers a more balanced approach by modifying the application’s underlying environment—for example, switching from a commercial database to an open-source one—without altering the core code. The strategy offers a cost-effective way to gain significant modernization benefits without the heavy lifting of a complete rewrite. It’s a compelling alternative when lengthy rearchitecting efforts aren’t feasible.

And then, there’s rearchitecting that involves a significant overhaul of the application’s structure and design, often breaking it down into smaller, independent components optimized for cloud environments. While it offers the greatest flexibility and long-term benefits, it’s also the most complex and potentially expensive option.

In this article, we’ll be focusing on the replatforming modernization strategy and the key considerations for making informed replatforming decisions. 

Summary of key considerations for application replatforming 

Best practices	Description
Understand your application and its components	Not all applications are created equally; some might require different levels of effort in their modernization practices.
Establish a transition plan	Critical business applications often require gradual replatforming to maintain business functionality.
Revisit your software development practices	A more modern decoupled application could allow for less risky and quicker rollouts to production.
Leverage the capabilities of your infrastructure provider	Optimizing the application’s infrastructure footprint is often one of the easiest ways to extend the application’s longevity and simplify operational tasks.
Improve your application’s observability	Newly introduced services and more interconnected components require adjustments to enable adequate observability.

What is application replatforming?

The core idea behind replatforming as an application modernization strategy is to move an application to a new platform—like a different operating system, cloud provider, or version of an existing platform—with minimal code changes. Unlike rearchitecting, which involves significant code modifications, replatforming focuses on modifying how and where an application runs without altering its core code. The approach often involves combining several micro-strategies tailored to the specific needs of an application or the organization. 

A replatforming exercise can include one or more of the following variations:

• A simple platform upgrade: Moving an application to a newer version of the same platform (e.g., upgrading a database to a newer version)
• Changing the underlying infrastructure: Migrating from physical servers to virtual machines or containers
• Adopting cloud-native services: Replacing on-premises components with managed cloud services (e.g., using a cloud-based database or message queue)
• Optimizing for a specific cloud environment: Adjusting configurations or making minor code tweaks to take advantage of a particular cloud provider’s features

To illustrate the nuances of replatforming, two scenarios are outlined below. While these are just a couple of fairly straightforward examples, they show that the steps needed to conduct replatforming require significantly less time spent than any other migration strategy. The strategy is also a practical choice if you don’t have the budget or need for a complete overhaul.

Windows application example

A .NET 3.5 Windows application is running on a single Windows Server 2012 alongside a Microsoft SQL 2012 database instance running on the same machine. The source code of the application is not available, but the application is part of an important business process and will not be replaced for the next two years. 

While the replatforming options are limited given the legacy application stack, the application can still be moved to the latest supported version of Windows Server. The database can be moved to a managed PaaS SQL server on the public cloud, decoupling the data layer and eliminating the need for future maintenance activities.

Python example

A Python web application is running on a standalone Ubuntu Linux server with the data backend consisting of an NFS share and a MySQL database running on a second server. The application struggles with periodic workload increases. 

To help with scaling options, the application can be packaged as a container and run on an automatically scalable containerization solution or a Kubernetes cluster. The database and NFS server could be replaced with a cloud-native file share service as well as a managed MySQL database instance.

Application replatforming: Factors to consider 

While the strategy offers many benefits, application replatforming requires careful planning and execution. Here are some key considerations to keep in mind.

Understand your application and its components

Once you have chosen an application to be replatformed, it’s likely that you will have already identified the overall objective. At the same time, it’s also important to consider the application’s projected lifespan and how the replatformed version will fit into your organization’s long-term strategy.

When analyzing the application’s current state, factors like programming languages, source code availability, and the current environment determine the extent of platform-related changes and the potential for optimization. For example, legacy applications with limited source code may have fewer replatforming options compared to modern applications with well-documented code.

Note that the scenarios discussed in the earlier section represent small, monolithic applications running on just one or two servers. However, modern enterprise-grade setups house larger, more complex applications with multi-tiered architectures, numerous servers, specific middleware, and extensive databases. In these cases, your replatforming strategy will need to be significantly more comprehensive and may require detailed inventory and dependency mapping to assess the application’s complexity. 

Assessing application dependency flow with Device42

Here are some key things to map when building your application inventory:

• Lists of servers where the application is running, including their performance metrics, operating system versions, and database management systems
• Middleware and libraries that are used by the application as well as their versions
• Relationship mapping among the different servers, including network connectivity (communication direction, protocols, ports, and network appliances that these flows traverse through)
• All external systems that the application communicates with

Another essential topic is applying the same operational practices as the application had prior to modernization. If you have stateful data in the legacy environment, backups must be configured as soon as the application lands in the new setup. Even though your replatformed application might be running on a different operating system or using different tools, the need for regular patching and security hardening should be carefully assessed. 

Establish a transition plan

When it comes to application modernization, planning is the key to reducing unexpected outcomes. If your replatforming effort is just one smaller part of an even bigger project (like a data center migration), the overarching governance will likely be guided by the bigger project. However, even if it’s a standalone initiative, a solid transition plan is important. This should include:

• Inventorying: Discovering and documenting all of the application’s components, dependencies, and infrastructure
• Communication pattern discovery: Understanding how the application interacts with other systems and users
• Securing approvals: Obtaining necessary approvals from application owners and stakeholders

If you have an application that has been identified as a candidate for modernization (rather than an outright replacement), instead of immediately building a dependency map, start by determining which of the “3 Rs”—rehosting, replatforming, or rearchitecting—makes the most sense. Be mindful of any hard constraints that might influence your modernization path. For instance, it can be very difficult to rearchitect an application if you do not have the application source code. Similarly, applications built on niche frameworks or databases might limit your ability to leverage certain cloud-native services.

If there are no hard constraints preventing your preferred transition plan (assuming replatforming is your chosen migration strategy) you can move on to gathering requirements and designing the future application infrastructure on your chosen cloud platform. A common diagramming standard like C4, which can operate at different levels of an application, can be very useful in outlining the components of the application. 

A typical C4 model architecture viewpoint (source)

At the same time, don’t forget to establish a clear timeline for testing and, importantly, a rollback plan in case things don’t go as smoothly as expected. To maintain operational continuity, all of the initial activities of application testing should be done in an isolated environment to validate that the chosen solution can support all functional and non-functional requirements. The application owners should give the final approval to ensure that the migrated application is operating and performing as expected.

Revisit your software development practices

A key consideration in your transition should be to transform how you fundamentally build, deploy, and manage application stacks. Replatforming offers a unique opportunity to modernize not just your application but also your entire development workflow. While it’s often associated with applications that are no longer actively developed, replatforming can be even more impactful for applications still under development. This is your chance to take a closer look at your in-flight development practices and see how they can be aligned with and improved in a cloud-native environment. 

As you move the application to the public cloud, you get the option to define all of the infrastructure in code using Terraform, CloudFormation, Bicep, or similar declarative languages. As a result, you can easily deploy and create consistent environments for development, testing, and production with a few simple clicks. 

Replatforming also offers the perfect opportunity to break down silos between development and operations teams, encouraging collaboration and shared responsibility. Through leveraging cloud-native features that promote continuous integration and deployment, you can automate the entire pipeline from code commit to production, creating a repeatable and efficient workflow that can be reused for other applications. This replaces your manual workflow with a new development process featuring faster feedback loops, improved communication, and greater efficiency. Implementing a CI/CD release cycle with code change versioning can also significantly improve your development process by eliminating error-prone releases and opening up possibilities to have features like canary releases or automated tests.

Leverage the capabilities of your infrastructure provider

Replatforming often goes hand-in-hand with maximizing the use of cloud-native services. Whether your applications reside in your data center or have already been lifted-and-shifted to the cloud, consider leveraging your cloud provider’s native services to truly enhance the replatformed application stack.

Some key areas that can make a difference:

• A more efficient and less maintenance-requiring compute engine. Although virtual machines are a common starting point, consider exploring managed application platforms like App Service (Azure) or Elastic Beanstalk (AWS). These platforms abstract away much of the underlying infrastructure management with features like autoscaling, load balancing, and built-in CI/CD pipelines. You can also look for platforms that offer specialized environments for your specific application needs, such as those optimized for .NET or Java.
• Choosing the right container service for portability and consistency. For simpler deployments, services like AWS ECS or Azure Container Apps might suffice. For complex, microservices-based applications, you can adopt the orchestration capabilities of Kubernetes platforms like AWS EKS or Azure AKS. 
• Consider serverless computing for event-driven architectures or applications with highly variable workloads. These platforms allow you to only pay for the compute resources you actually use, and scaling is automatic. However, it’s important to understand the implications of serverless limitations, such as execution time limits and cold-start latency, because these can affect applications that require long-running processes or those with sporadic traffic patterns.
• Transition to a managed database engine. Most major relational database engines (including PostgreSQL, Microsoft SQL, MySQL/MariaDB, and Oracle) and NoSQL engines are available on public cloud providers as PaaS offerings. To truly optimize your database environment, you can also choose the right service tier for your needs. For example, if your application requires high availability and automatic failover, you might choose a multi-availability zone deployment. If your workload is read-heavy, consider using read replicas to offload read traffic from your primary database instance.
• File and object storage services. Just like with databases, stateful data that utilizes a familiar protocol like SMB or NFS can be moved to a managed cloud share. For the majority of organizations, this can be much more appealing than taking care of a Windows DFS cluster.
• Managed queuing and caching solutions. For applications that use decoupled components that communicate using a messaging platform (e.g. RabbitMQ) or event publishing systems, most cloud providers offer similar managed services without the need to maintain the highly available underlying infrastructure. The same can be said about caching solutions like Memcached and their managed equivalents on public cloud platforms.

That said, managed services usually involve a higher price tag than managing your own infrastructure, often because you’re essentially paying for convenience, expertise, and reduced operational overhead. The decision to utilize managed services should always be based on a thorough assessment of your application’s needs. 

It is also worth considering that while cloud-native services can significantly enhance your replatforming efforts, they might require architectural changes to fully leverage their capabilities. In some cases, this might push you closer to refactoring or rearchitecting your application. So, while replatforming might be the initial goal, be prepared for the possibility that it could evolve into a more substantial modernization effort.

Improve your application’s observability

Monitoring legacy applications running on standalone servers offers limited to basic metrics of CPU usage, memory consumption, and disk space. These insights provide a general overview, but they don’t tell the whole story of application-level performance data and the experience that end users might get.

A replatformed application, however, can offer extended capabilities by collecting data that is more closely related to the key indicators that represent the actual user experience. In addition, you can take advantage of the built-in monitoring capabilities offered by managed services.

For example, when you replatform, you often decouple application components, distributing them across various infrastructure elements like managed databases, message queues, and load balancers. These services typically come with built-in monitoring and logging capabilities that provide valuable insights into your application’s performance. You can gain visibility into database query latency, message queue throughput, and API response times—metrics that were previously difficult or impossible to obtain.

You can further instrument your application to capture meaningful metrics, logs, and traces that provide a comprehensive view of its health and performance. Consider choosing the right instrumentation libraries and frameworks for your application’s technology stack. OpenTelemetry is a popular open-source option that offers vendor-neutral instrumentation and can integrate with various monitoring backends.

OpenTelemetry high-level design

Conclusion

Application replatforming can be a fairly easy and low-impact strategy for your application modernization. However, a thorough evaluation of your application’s unique characteristics and factors, such as application criticality, technical debt, future roadmap, and resource constraints, is a must.

Whether running on-premises or in the cloud, Device42 provides an automatically generated, centralized repository of application, service, and device relationships to help you plan your migration strategy. With agentless discovery and dependency mapping, you can gain a comprehensive view of your application’s dependencies without the need for expensive packet captures.

To learn more about how you can make application migrations easier with Device42, book a free trial here.