Migrating from legacy platforms to AWS will often come with its challenges. If the migration process is handled well, the likelihood is that most of these issues will not be performance-related. This article will explore some of the most common AWS migration challenges and potential solutions related to business goals.
How much to change
AWS migration does not always mean altogether abandoning legacy platforms. One of the challenges customers face is deciding how much of their infrastructure should be moved. The decision depends on many factors such as:
- The cost of maintaining infrastructure,
- The availability of skilled resources,
- The risk of losing data if it’s stored on-premises,
- The security risks associated with moving data into the public cloud.
We encourage our customers to do a cost/benefit analysis of on-premise vs cloud adoption before settling on the most suitable approach.
One can start by outlining how much it would cost to continue to run their on-premise infrastructure annually. Once that has been calculated, you can also look at how much it would cost to run a hybrid cloud setup. A qualified and experienced migration specialist can help you figure this out.
Consider how much it would cost to run your entire tech stack on the cloud. Which of these options is the most economical? Which one delivers the best performance? Which one ensures continuity for your customers?
The migration does not have to be carried out in one go. It can be done in phases. This often gives customers time to train their staff for the new platform’s day-to-day running.
Developing a migration strategy
Customers often struggle to develop a sound cloud migration strategy. A lack of experience and the complexity of it all can be daunting. However, we remind customers that they can start small. You don’t need to migrate everything at once. Start with a single application or service. Then work your way up. When you have mastered migrating an individual component, move on to another. Once you have migrated multiple elements, you can migrate more complex applications.
It is important to remember that migration needs to be planned carefully. There may be unforeseen consequences that could cause downtime. For example, if you decide to migrate a database instance to Amazon RDS, you must ensure enough capacity to handle peak loads.
Most companies underestimate the amount of time required. We recommend planning with additional time allowances. It is also worth noting that migrations can take longer than expected due to unforeseen data issues, operational complexities and changes in processes
Data migration is one of the leading cloud migration challenges for businesses of all sizes. GDPR and other legislation have added an extra layer of worry when migrating. Customers are concerned about potential security issues, losing data and complying with regulations during their data migration. It is fast becoming one of the biggest challenges in IT as more customers try to unlock potential from their data. Customers want to know what measures will be taken to protect them from potential issues.
We advise customers to follow the same guidelines as those handling personal information.
- Ensure that data is encrypted,
- Use only trusted third parties,
- Use secure protocols,
- Make sure there is no unauthorised access to customer data,
- If you are using S3 buckets for storage, ensure that bucket policies are set correctly to avoid the accidental deletion of data.
This feeds into the need for data security and compliance. If you are storing sensitive data such as credit card details, social security numbers, or bank account details, you should ensure that you comply with the relevant regulations. It should be done as part of other security measures including a data protection impact assessment (DPIA)
Performance can be the elephant in the room. It is a key requirement of a successful migration. Will my application work as well as it is now after moving it to the cloud? Are there any potential performance issues I should be aware of?
Many factors affect application performance. The biggest factor is the hardware. If you are moving to AWS, you will get better performance by choosing instances that are based on Intel x86-64 processors.
You will also get better performance by choosing the correct instance type. Choose between t3.micro, m5.large, m5.xlarge, m5.2xlarge, c5.large, c5.xlarge, r5.large, r35.xlarge, r5.2xlarge, i3.large, i3.xlarge, g5.xlarge, and g5.2xlarge.
Consider whether you need EC2 spot instances. They are cheaper than regular instances but come with a few caveats. You cannot use spot instances for production workloads, unless your workloads are designed for failure. They also require a little more thought to patching, deployments and high availability – but can offer savings of up to 80% off on-demand pricing.
Nothing beats extensive testing. Our engineers ensure that everything we move to the cloud is rigorously tested before going live. This includes testing the application itself, its dependencies, and the infrastructure.
Migrating Legacy systems and application
The approaches outlined below increase in both complexity and cost as you move down the migration path, however they also increase an organisations ability to innovate, deliver at pace and take advantage of the latest cloud native capabilities.
Migrating to the cloud using a “lift and shift’ approach often results in a relatively quick and cheap migration. This usually involves copying workloads or the underlying virtualised infrastructure they sit on – block by block to an equivalent virtualised infrastructure in the cloud.
Cloud providers like AWS now provide free services which can assess, plan and implement a migration using block replication to EC2 servers – where testing can be performed before services are cut over. Whilst testing is being carried out, the replication service continues to copy data from on-premises to ensure migrated workloads have the latest data and configurations.
This approach involves a “lift and shift” with a small change to take advantage of cloud native services. For example, rather than migrating your database from VM’s directly to AWS EC2 – it would be more beneficial to migrate it to AWS RDS. Amazon’s Relational Database Service (RDS) provides automated high availability, resiliency, disaster recovery and patching. Therefore, customers can remove a lot of operational overhead by simply adopting the correct AWS service and let the cloud do the heavy lifting for you.
This approach will obviously take a little longer to complete than a Rehost migration, but aligns your workloads with cloud native features such as horizontal autoscaling, adopting AWS managed services and reducing operational overhead on engineers.
The last primary migration approach is to refactor your workloads to become fully cloud native – letting your organisation take full advantage of the cloud whilst accelerating delivery using the latest open source tooling.
As an example, instead of migrating your monolith application to EC2, it might be rearchitected into stateless microservices using containers. An AWS containerised platform such as ECS or EKS (Kubernetes) would then orchestrate services to ensure high availability and automation whilst reducing EC2 costs. Furthermore, a containerised strategy would allow developers to test code locally as if it was running in production, increase interoperability and encourage innovation using rapidly provisioned cheap environments.
Choosing the right solution
Is this the right solution for my business? Choosing the right solution is another concern that customers may have. How do I know what works best? This is where users can benefit from leaning into the experience of migration specialists. You may have access to examples and case studies of similar businesses and what they have done. This would include the challenges they faced and how they resolved them.
Managing the cost
How much is all of this going to cost? This often comes up when discussing the need or potential need to redevelop an application for the cloud. If you refer back to the cost/benefit analysis, you will note that it can also be applied to this.
While the initial cost of developing a new cloud compatible application can be higher than continuing with an on-premise one, customers must also consider the cost over several years. You may find that redevelopment costs are offset by hardware and computing cost saving over a decade or so. This includes the cost of cloud migration.
Furthermore, the ability to run services in the cloud using a pay-as-you-go pricing model should not be underestimated. Do your analysts want to try processing their latest data models using next generation compute services? Well, instead of investing heavily in new specialised infrastructure on premise – spin up an instance in the cloud, try it for a couple of days and then terminate it – only paying for the days it was running.
Do we have the skills to manage this
Upgrading your systems to the cloud without upskilling your staff is an ill-advised approach. Trying to manage your cloud environment like an on-premise installation will result in missed opportunities to take advantage of cloud capabilities – elasticity, innovation and cost-savings. Therefore it is imperative that your engineers are reskilled in cloud principles and techniques as well as DevOps or Site Reliability Engineer (SRE) principles.
If you don’t have the necessary skill set, you will need to outsource this work. Outsourcing may mean hiring a team of experts who specialise in migrating to the cloud. They could provide training to your staff. Or they could take care of the entire process themselves. Either way, outsourcing is usually the most effective option.
If you decide to go ahead with the cloud migration, ensure that you get expert advice before doing so.
Being tied to a cloud provider
What if we are unhappy with this cloud provider? We should at least have the opportunity to switch providers. This is unlikely to happen if we are locked into using a particular vendor. For example, Amazon Web Services (AWS) is today’s largest public cloud service provider. There are many others, such as Microsoft Azure, Google Cloud Platform, IBM Softlayer, Rackspace Hosting, Digital Ocean, and OpenStack. These services are very competitively priced and offer great value for money.
The main thing to remember here is to choose a cloud provider that fits your needs. There are many different types of cloud solutions available. Some are better suited for specific applications, while others are designed to meet the needs of multiple industries.
If you are able to migrate your workloads using cloud agnostic technologies, such as containers – then making a switch between cloud providers is relatively pain free, compared to migrating a serverless application for example.
Maintaining User Experience
Business continuity is vital! It is a part of core business objectives. Most businesses worry about their customers’ experience or lack thereof during their migration to the cloud. What happens to the platform while we are migrating? A good cloud provider will ensure that the user experience remains consistent throughout the transition.
This means that the data stored within the cloud environment will remain intact. Users will not lose any information or functionality when moving to the cloud. They will still have access to the same features and functions as before.
Many companies use third-party tools to migrate their data from on-premises servers to the cloud. However, these tools do not always guarantee that users will receive uninterrupted service. This is why it’s important to select a cloud solution that has been specifically designed to support business continuity. This is something to request from a cloud migration service provider.
How will we keep an eye on things? Customers worry about the challenge of monitoring their platform after the cloud migration process is completed. This can be a daunting task. It requires constant attention and maintenance. You cannot afford to ignore a problem because you’re busy focusing on another issue.
Cloud providers offer excellent monitoring options. They typically include alerts and notifications that let you know when something goes wrong. They also allow you to create dashboards that show how your system performs over time.
You’ll want to make sure that you monitor your systems closely after you move them to the cloud. The best way to do this is by creating automated checks. Automated checks are alerts that monitor your workloads at 1-minute intervals to ensure a threshold has not been exceeded (for example CPU > 80%). They can check everything from Free Memory Available to a keyword in your application logfiles and alert you to anything that might require immediate action.
You can also hire someone to perform regular audits of your cloud infrastructure. This person would be responsible for checking your systems regularly. They could spot problems before they become major issues. It helps businesses keep an eye on common cloud migration challenges to nip them in the bud.