Cloud migration and application modernization explained

What is cloud migration?

Cloud migration is the process of moving applications, systems and data from your on-premises servers to a service provider’s servers. The term cloud migration is used by some to mean a basic “lift and shift” with no app configuration or basic code tweaks to take advantage of cloud features like automatic scaling of compute, storage and networking. Others see it as a tested-in-the-cloud implementation, meaning that the company’s tech team or contracted cloud engineers make basic configuration adjustments to help apps run better in the cloud environment. 

What cloud migration definitely does not mean is application modernization — that is, the process of upgrading or replacing applications so that the company is running software that is supported by and takes full advantage of cloud architecture. This is also called being cloud native.

Done right, there are significant benefits of a cloud migration followed by application modernization of most or all of your apps, such as on-demand scalability, cost savings over time and instant cloud resources that become your R&D lab for digital innovation. Perhaps best of all, when your company identifies a new business opportunity, its path to innovation no longer leads through a technology choke point that stalls the process.

Though you might have a good business reason for doing so, a decision to leave key legacy apps on premises or place them as is in the cloud could mean that you won’t realize as much return on investment (ROI) from your migration as you would if you opt to modernize.

Your cloud migration needs a well-thought-out plan. Many cloud migrations fail because the full ramifications of moving all or most of your processes to the cloud — details like itemizing dependencies and repointing hardware, software and data locations — aren’t identified by the cloud migration team. It’s important to evaluate whether your IT leaders and key players have the expertise required to migrate successfully. Make that decision early and hire new talent and/or get experienced help from migration professionals.

What is cloud-native architecture?

Expecting to move your apps and systems into the cloud and run them as is the way you always have negates the full advantage that cloud offers. To be ready for innovation, to make full use of scalability and to see significant cost reduction, your move to the cloud should focus on a cloud-native implementation where possible.

What does cloud native mean? Cloud architecture’s components were designed from the ground up to run in the cloud, and they work differently than the hardware-specific software in your data center. The cloud was built to support scalability, portability, resiliency, performance and reliability. Cloud-native architecture provides a platform that supports a series of cloud-specific functionalities, such as serverless computing’s automatically scalable applications whose underlying resources are invisible to the user, requiring no management of any kind.

Cloud-native architecture is also typified by containers and microservices. A container is a cloud software construct, evocative of a virtual machine, that holds everything an application needs to run. At its heart, cloud-native architecture was designed to support the use of smaller, independently running bits of code called microservices. If you rewrite a monolithic application to be cloud native, instead of one big application, it will be composed of many discrete, independently operating and separately upgradeable microservices. Microservices usually have few if any dependencies and perform a focused action or task.

When combined with powerful automation, cloud-native architecture lets software developers make significant, business-focused changes frequently with minimal effort. 

Making your applications work with and leverage cloud-based functionality already in place is a cloud-native approach. It requires learning a new set of best practices. In an ideal world, you would switch to apps that were designed to run in the cloud, rewrite proprietary apps for the cloud and leave behind legacy systems and databases. Many companies tackle the challenge on all fronts: “lift and shift” applications at the same time they are rewriting one or more core apps, while at the same time swapping out a legacy database for a cloud-native product. 

What could go wrong? That’s a lot of change (and investment) to undertake, which must be carefully managed. Because it can be complex, many organizations put off the work to make their apps cloud native and their cloud journeys may stall.

What is application modernization?

There is another way, however. One that can get you all the way to cloud native while keeping some apps you can’t part with. If you have the in-house expertise to handle application modernization, you’re in good shape. Many businesses do not. There are outside firms (including PwC) that can handle your app swaps and rewrites. As mentioned earlier, application modernization is the process of upgrading applications, retreading them to work cloud natively.

There are three main approaches to application modernization: serverless, containers and replatforming.

Serverless

This approach involves moving ahead boldly, probably leaving one or more applications behind and developing one or more serverless applications. Serverless computing is a set of underlying cloud services that fully removes any semblance of server management. Serverless architecture can perform automatic up- and down-scaling dictated by current workloads and demand. That means you only pay for the resources your applications use. During off-peak hours, serverless apps partially shut down, and you’ll save money. With containers and virtual machines, you’re paying for those resources to be available around the clock. Serverless apps are arguably the high point of cloud nativity. Serverless also delivers the most potential cost reduction. A downside is that apps must be written specifically to use it. 

Serverless allows developers to focus on their applications instead of the headaches of managing and operating servers or runtimes. This reduction of ancillary work lets developers save time.

Good uses of serverless are for new application builds. Resource-intensive code, such as an image-processing pipeline, is a great use case for serverless. It’s also useful on an ad hoc basis when you need to set up an unexpected workload. And serverless excels when the traffic pattern rises significantly. It automatically detects the load change and adjusts instantly.

Containers

The second way to make existing applications work more efficiently in the cloud is to place them in a container, alongside all requisite app dependencies — such as frameworks, runtimes, monitoring and supporting applications — creating a self-sufficient environment. Layering in microservices and other cloud-native bits may improve elasticity and prime you for perhaps making a bigger change later. 

Containers are more suitable for companies that want the flexibility to install and use software with specific version requirements. You have full control of the installed programming language and runtime version with containers. That allows applications to be moved quickly between host servers and becomes extremely useful for migrating legacy applications to the cloud because it enables developers to replicate an application’s original running environment.

Containers are ideal for organizations that don’t want to rewrite their apps in a cloud service provider’s proprietary code. Using containers, they can pull apart their monolithic application code into smaller pieces that can execute independently.

Re-platforming

The re-platforming approach consists of moving applications almost as is, while replacing or lightly modifying some components to take advantage of the cloud. Customizing code might make your enterprise app support scalability, for example, but probably not with all the desirable functionality of a cloud-native app. 

One example of a typical re-platforming modification is transforming the way a program interacts with the database to benefit from platform services that enable better scaling and higher availability in the cloud environment. Re-platforming lets infrastructure teams focus on higher value-added services for the business.

Re-platforming by migrating away from legacy databases is a common approach to modernization. Some will even look at switching to a cloud-native open-source database engine to replace costly licensed ones. When re-platforming database workloads, the goal is to release the organization from the day-to-day care and feeding of the database.