Companies moving to the cloud can’t wait to take advantage of the many benefits the medium offers. They look forward to saving on costs, scaling up to meet sudden surges in demand, making the work force more mobile and setting up more secure backup capabilities. So they blaze ahead, migrating as many applications as they can, as fast as they can.
Anybody who’s done a cloud migration knows what happens next. The project stalls when IT discovers hidden dependencies that complicate the migration.
Some call this the challenge of “migrating the monolith.” The intertwining of apps, business logic and infrastructure is often hard to identify prior to a migration. Sadly, this means many hoped-for post-migration improvements don’t appear – or worse, something breaks during the move.
There are steps organizations can take in response to the most common “gotchas” when migrating their monoliths. Here are a few.
Be brutally honest when evaluating a legacy application’s suitability for cloud deployment. Some legacy applications may be resource intensive, and the cost of cloud infrastructure, even if one leverages the discounts available via the purchase of reserved instances, could deem it unsuitable for cloud deployment.
Legacy applications may sit on legacy operating systems that don’t have a cloud alternative. Same goes for apps designed for proprietary hardware systems. These include apps running on mainframes, apps on engineered systems that can’t be rehosted, or apps that require the purchase of an appliance like a load balancer. These applications will need to be re-platformed before being moved to the cloud.
Other applications, or the infrastructure they depend on, may not have been designed with the level of security that your Chief Information Security Officer (CISO) may have put in place for cloud deployed applications.
The risk of being attacked by an LDAP injection or a cross-site request forgery are far higher when the application moves out of the data center and out from behind the corporate firewall. Make sure to do a thorough security review as part of the cloud-suitability evaluation process.
A third set of applications are ones that can be moved to the cloud but probably shouldn’t. Any apps that depend on high performance and low latencies to generate value should either remain in the data center or possibly should be shifted out to the network edge. Those with high-availability requirements aren’t good fits for the cloud. While cloud security has advanced significantly over the years, most companies – particularly those in highly regulated industries – keep systems of record in house and out of the cloud.
While large applications tend to deliver the most value when migrated to the cloud, they can also be the hardest to move. The bigger they are, the more complex connections they tend to have, with tentacles extending into various other business systems and processes.
Start by moving the simplest applications to test the process and build confidence within the organization. These include low-hanging fruit like email, collaboration programs and apps where data has been decoupled from main servers.
Next, refine the process by feeding in learnings from early migrations. No matter how well planned out a migration project is, there’s a lot that can go wrong. Staff training is critical, and organizations often underestimate how much preparation is needed. Tackling more complex projects that are bigger and have underlying dependencies will go smoother after organizations stub their toes a few times.
Then, after your organization has comfortably moved the first two rounds of workloads, tackle the monster apps when the process and the team are battle-tested. You don’t want to move mission-critical apps – including those dealing directly with customer implementations – without a significant amount of practice.
Migrating legacy applications to the cloud is, in many ways, at least as complex and difficult as a heart transplant. While a heart has a fixed and known number of blood vessels, the data sources that feed an application can be numerous, and failure to reattach one data source to the transplanted application can put the patient at risk.
The key to successfully migrating a legacy application to the cloud is to have a detailed plan that includes an evaluation of the applications and their myriad dependencies, including data sources. Enterprises undergoing a migration should develop a checklist that ensures all of those sources are attached to the transplanted application and in the correct sequence. They should set aside a time block where both the on-premises and cloud versions of the applications run side by side, so, if anything goes wrong, a backup is still in active operation. They also should develop a set of acceptance criteria that can signal when it’s safe to decommission the on-premises application.
Once the application has been successfully running in the cloud for a period, then you can start planning the next evolution of the application leveraging cloud native capabilities and services.
There’s no question that enterprises are embracing the cloud. Studies show 90% are using the cloud, and 60% of all workloads are running on a hosted cloud. Still, a 2020 Actian survey shows they still see value in keeping targeted apps on premises; only 15% of respondents moved all of their data into the cloud.
Bottom line: Hybrid landscapes are here to stay.
For companies to optimize their resources and take best advantage of their moves to the cloud, they need to take a strategic approach to cloud migrations. Picking the right apps to move, proceeding at a reasonable pace and planning the project out can help them get where they need to go.
As SVP of Engineering at Actian, Emma McGrattan leads research and development for Actian’s Portfolio. Emma has over two decades of experience in high-performance analytics, data management, integration, and application development technologies. She is a frequent speaker at industry conferences.