So you're thinking about moving a legacy application to AWS ...

There are many questions about making the transition to move a legacy application to the Amazon Web Services (AWS) cloud, and Media Temple can help you with the decision and the journey to migrate. So, yes, you can move legacy apps to the cloud, but let’s dive in to what that means.

What Do You Lose from a Non-Cloud-Native Application?

After moving that legacy application to the cloud, you’ll realize that many of the cloud benefits won’t be available without application refactoring. Using AWS Security Token Service (STS) to authenticate to other AWS services; nope. Auto scaling; probably not. Attaching to Amazon S3 as your file server; not likely without a third-party helper. Consuming SNS messages, reading from SQS queues, firing AWS Lambda jobs; sure, but are those really part of your application ecosystem?

What you must consider after moving your application is that you’re going to support legacy apps in a less optimal way. You won’t have the benefit of on-premises, SAN-style shared storage that allows for database and file server clustering, or a luxury like VMWare VMotion that allows for frictionless migrations between hypervisors without downtime. To achieve similar on-prem comforts, you will have to use third-party utilities that run on Amazon EC2 instances, such as NetApp Cloud Volumes ONTAP, for SAN-like storage. Within the last few years, new offerings in AWS have increased flexibility for legacy apps. VMWare ESXi is now a supported OS, and bare-metal instances (such as the Amazon EC2 m5.metal) give you data-center-like hardware.

Consider moving your legacy applications into their own Virtual Private Cloud (VPC), away from your cloud-native workloads. They are unlikely to follow standard designs like deploying to multiple availability zones (AZs), and should have tighter security group and network access control list rules—considering they are, by nature, highly mutable. If you already use configuration management tools such as Puppet to configure your servers, you are at an advantage. If possible, deploy new server replacements into the cloud and have your configuration manager configure it, then retire your on-premises application. If you currently deploy on-prem with CI/CD, even better. If your application is manually configured and maintained, you may have to lift and shift it, which can be challenging (we’ll discuss this in more detail later).

Application Concerns

Most legacy applications rely on load balancers, shared storage, and database connections. If you utilize AWS-native services, you have some choices. AWS Application Load Balancers (ALB) can grant you the ability to use “sticky sessions,” which will help your stateful apps receive their dedicated traffic once a session is opened. Network Load Balancers (NLB) can simulate that Layer 4 Vanity IP-style endpoint if your application requires it.

For file services, if your application is Linux, you are in luck, since AWS Elastic File System is available as a scalable NFS system. However, its simplicity comes at a very high storage cost and very low flexibility (it does not back up like an Elastic Block Store (EBS) snapshot). If you are using an application running on Microsoft Windows, your storage solution will be more difficult. Either way, the challenges can be great.

Keep in mind, sticky sessions and file servers are normal for legacy applications, but are heavy departures from cloud-native architecture.

Database Concerns

Databases in the cloud are great, and Amazon Redshift, Amazon DynamoDB, Amazon RDS, and Amazon ElastiCache can all be used by your legacy application—that is, if you’re ready to depart from all the database helpers you’ve used on-premises. For one, most traditional MS SQL and Oracle database environments are coupled with utilities such as Quest’s Spotlight for SQL Server Enterprise or GoldenGate for Oracle. If you need to move those agent-based installations, you will be installing your database on an EC2 instance and migrating your data (rather than moving to Amazon RDS). AWS Database Migration Service can also help you move your data.

If your application is attached to technology such as Oracle RAC, you’ll lose that capability (since multicast and shared storage is not supported), and must consider whether that is an acceptable compromise. Microsoft SQL Server can use clustering such as Always On, but traditional clustering utilizing shared storage won’t work without third-party tools provided by vendors such as NetApp or Zadara.

Tools You Can Use to Move Your Application

If you cannot deploy your legacy applications to new servers through a pipeline, or reconfigure them completely with a tool like Puppet or Chef, then you have a few options. Each has layers of complexity and considerations.

Containers

If you’re using Docker, this may be a good option for you. One of the large challenges with legacy applications is dependencies; sometimes they are unsupported or abandonware dependencies. If you’re able to deploy your application into a container, you can move that application right to the cloud. An easy way to move it over in a bundle is to deploy it in an AWS Elastic Beanstalk environment in a container.

If you can take advantage of moving your application in a container, you will have made your installation repeatable and portable. It will extend the life of your app in a more supportable way and keep it isolated to its own environment.

Lift and Shift

Consider this your last resort in getting your application into the cloud. Tools such as AWS Server Migration Service, CloudEndure, or Tidal Migrations can help you plan and execute these lift and shifts. Tools like RISC Network’s CloudScape can help you understand your ecosystem dependencies and what must move together (often the larger challenge).

Ultimately, if you are left with a lift and shift strategy, you’re now subject to heavy discovery, planning, data migration, and cutover outages to get your legacy production application(s) to the cloud. Keep these points in mind:

• Data migration rise over run: If you cannot use a tool like Amazon S3, and need a file server instead, then you need to replicate that data to the cloud. This means using a tool like rsync, robocopy, or a third-party utility. Once you have a good copy in the cloud, you’ll need to sync deltas, and, finally, plan the cutover and stop connections to the old file servers. You can either cut over the data first or last—or better, when the application moves. If you have way too much data to move or data changes at a rate higher than your replication, you may need to consider refactoring your application and then using AWS Snowball to move your data into Amazon S3.
• Test thoroughly: Once your server is moved, you will need to perform quality regression testing (if there are no automated tests) because moving back is costly, especially if you’ve been performing replication and are performing an ecosystem move. After migrating the application, consider it as if it’s on life support. It’s still online and supporting workloads, but it’s aging architecture in a changing landscape.
• Start planning the replacement application: One of the largest mistakes companies make after a lift and shift is moving on to the next project. Instead, plan its stateless, modern, cloud-native replacement so you can put it to bed and not have to micromanage it in an unscalable way.

Will It Be Cheaper?

It depends. If the legacy app is under typical constraints (it needs backups, it’s on 24/7, it’s highly stateful, it cannot be scaled, etc.), then it will likely not be cheaper over time. If the application falls into the aforementioned limitations, you will not be able to take advantage of Amazon EC2 Spot Instances without extreme risk, so your best bet is to purchase Amazon EC2 Reserved Instances (RIs) for the life of the application. If you’re going to have the application on all day until it’s replaced, purchasing RIs can save you up to 40% of your annual cost over on-demand instance pricing.

When taking backups of your applications, keep in mind that snapshots utilize reverse incremental technology, so the most recent snapshot is the full backup. Ensure you cycle out old snapshots as they’re no longer needed, so you don’t accumulate creeping Amazon EBS storage costs.

Summary

Can you move your legacy application to the cloud? Absolutely. Will it come at a cost? You bet. If you go for it, plan the move, consider what you’re losing on the way, and also how you will manage the application when it gets there. Don’t forget to plan its replacement; and remember, the cloud is about managing services in a stateless, scalable, highly available way—not managing individual applications on servers!

Reach out to a Media Temple cloud architect to talk more about how we can help you migrate to the cloud, today.