Migrating to AWS: 5 Common Migration Mistakes

As an AWS Partner, we regularly assist customers looking to migrate their workloads – either from on-premise or from another Cloud provider.

While no two customers or migration projects are truly alike, there are some agonisingly common pain points. We feel these ought to be shared for the benefit of migration first-timers, as well as the more experienced, senior professionals amongst you.

What follows are 5 themes where we see these areas for improvement and by avoiding some of the pitfalls you can greatly improve the success of your migration to AWS.

1. Improper Due Diligence

This sounds far too obvious, which is precisely why it’s top of the list. Despite staring us all in the face, it’s often either overlooked or incomplete and sometimes rushed.

That sounds obscure though, so let’s clarify what good migration due diligence looks like.

Start with ‘why?’

The first step to a successful migration is to ensure that your whole team understands and agrees with the reasons for it.  This must include executive stakeholders, technical stakeholders, heads of department, finance controllers, your engineers, anyone who will come into regular contact with the migrated workload, and anyone else accountable for its business value.  Feedback from these individuals could very well shape the outcome of the migration itself, such as which migration strategies to adopt and which elements to decommission or refactor, not to mention the case for doing the migration in the first place.

Use the migration as an opportunity for collaboration and discovery, and you may be very surprised by what you learn. Many companies look forward to modernising during their migration projects, thus improving ROI.

Regardless of how you answer your “why?” question, be strict with yourself to avoid the trap of solutionising at this stage.

Understand current costs

Make sure you have detailed, itemised cost reports from all those responsible for your incumbent workload. Scrutinise them obsessively.

Understanding which resources are generating the most cost, such as under-utilised servers or storage media, should be your first consideration. But other factors, such as excessive network traffic caused by a lack of caching in your application layer, for example, could be driving data transfer costs higher than should be reasonably expected.

In summary, high costs are often a key indicator of inherent architectural mistakes, so be sure to turn over every metaphorical rock that appears on your bill to determine if these costs depict an acceptable baseline, or whether costs could be reduced further without impacting quality-of-service.

Prove current usage and performance

Gather as much historical data as you can about the performance of your infrastructure and any workloads running on it. Use this data to determine what your real, up-to-date baseline usage looks like. Ensure you know when your load peaks and what the maximum ceiling for those peaks looks like – from network traffic, to demands on compute, to application performance. The more information the merrier. If you don’t know your numbers, it will be impossible to form a correct migration strategy, period.

Gather data requirements

Migrating compute is relatively easy, but migrating data can present several problems, particularly if you have highly volatile data. And that’s just for a kick-off.

How much data do you have? Where is it stored? When is your data least volatile? Is it encrypted, and if so, how are the keys managed? Can the keys be migrated or will you need to re-encode the data on the target platform? Can your current system handle data synching to another platform in parallel to its current loads? What about streaming data? What about data lakes, if you have them? What about object storage? What about CDNs and their datasources? What backup strategies do you currently employ, and are they adequate?

Those are just some of the basic questions you will need to answer. Data migration is a highly complex field. In fact, data migrations are some of the hardest operations to perform, so it’s not surprising that services like AWS DMS (Database Migration Service) and its SCT (Schema Conversion Tool) were created, among several others.

Review security & compliance requirements

Assuming you have established security and governance controls for your organisation, you will need to align the target state to adhere to these when performing a migration to another platform. You should become as familiar as possible with the various AWS security services, and how they can be used for both single accounts and multi-account organisations.

Security is one of the most common reasons for engaging with AWS Partners in general, certainly based on our experience. We routinely work with security teams to align AWS Well-Architected best practices for security and compliance, with AWS Security Hub, GuardDuty, AWS Config, AWS Macie and others.

Project future usage and performance requirements (growth)

With your current costs and usage now fully understood, you will need to make some educated predictions about growth. There’s little point in moving something that’s potentially inadequate to a new home, only to face the inevitable consequence of living with the same old problems once it settles in there.

Set some data-driven growth targets for compute, storage, bandwidth, network requirements, etc, to help shape your migration’s ‘target state’. Your AWS partner will help you with this also.

Determine types of migration required

With the clarity provided by the above activities, you can now decide if you need to perform a lift-and-shift type migration – sticking to a minimal like-for-like target state – or if there’s room to modernise as you go. Make sure you fold this back into your “why?” question when you present your findings back to your team, and make sure everyone agrees with your chosen migration strategy. Gather their feedback once more, then refine your collective understanding of the migration you would like to perform.  Rinse, repeat, iterate, refine. If it doesn’t feel right, go again.

This brings us neatly to our next common mistake, so keep reading!

2. Improper Migration Strategies

When it comes to modernising rather than lift-and-shift, migrating can be far harder than it first appears.

Ageing proprietary solutions with self-hosted components – such as firewalls, load balancers and databases – can be so fragile or incompatible with the target platform, that sometimes only an all-out replacement will suffice. This can prove quite daunting for many, as the number of unknowns is slowly realised. Sadly, planning for ‘the unknown’ is impossible without expert advice.

As a result, self-migrated workloads often fall back onto excessive use of self-hosted solutions, or design patterns that fall short of recommended best practices. Unfortunately, this belies the many benefits that a well-strategised migration can bring.

Learn the 7 Rs

AWS prescribe a framework called the ‘7 Rs of migration’, which is designed to help you choose the correct migration strategy for your workloads or workload components.

They are as follows:

• Retire
• Retain
• Relocate
• Rehost
• Replatform
• Refactor/Re-architect
• Repurchase

Don’t be fooled by the apparent simplicity of this list – each R covers quite a bit of ground, so we recommend that you read our accompanying blog article, Migrating to AWS: Understanding Migration Patterns and Why They Matter.

3. Fighting ‘Vendor Lock-In’

We hear this all the time: “I want to remain vendor agnostic and minimise vendor lock-in”.

Once again, start with “why?”. Why do you want to avoid vendor lock-in? Is it because you want to ensure fault tolerance, by deploying to multiple Cloud providers? Or is it because you want to be able to hot-step to another provider if they offer services at a more competitive price point?

The AWS global network is already highly fault-tolerant, with dedicated ‘Regions’ all around the world. Each region consists of several ‘Availability Zones’ (isolated data centres), with dedicated fibre lines between them. Inter-regional networking is possible, with configurable DNS failover between regions. Even a number of under-sea cables are now laid and owned by AWS outright, so fault tolerance for large-scale enterprises is really not a problem on the platform.

If you want to be able to migrate agnostically between Cloud vendors, then the only genuinely effective way of doing this is to completely self-host all your resources. Even the likes of Terraform cannot deliver a truly agnostic, one-size-fits-all Infrastructure-as-Code solution, so you’re already fighting a losing battle. The TCO of self-hosting will likely prove prohibitively high, and you will also lose the agility that comes with leveraging the managed service solutions that AWS has to offer.

Why not seek expert advice from an AWS Premier Partner like Ubertas Consulting? We routinely conduct cost modelling exercises alongside our architecture consultancy, which offers a balance between leveraging managed services, preserving or protecting proprietary solutions and improving overall scalability, performance, security and cost optimisation.

4. Leaving it Too Late

Another obvious point, but sadly all too common.

We have encountered many customers who have arrived at the decision to engage in migration or seek migration advice, far too close to a critical deadline. While imposed deadlines may be a strong driver for migration, cutting things too fine will negatively impact both migration planning, execution and even the post-migration experience.

If you choose to engage with a migration consultant, you should do this as early as possible.

5. Lack of Experience

There’s no shame in it.  You can’t know what you don’t know.

However, this doesn’t always prevent teams from carrying out their own migration projects, only to find that their lack of AWS skills or experience has drawn them up short of delivering the value they envisaged at the start.

We are often called in after a failed migration attempt, by which time our options become somewhat limited by growing commercial pressure and lack of time remaining before a go-live deadline. When this happens, we get forced into a ‘triage’ mode of engagement – a cure, if you will. That’s not what you want.

Prevention beats cure, as they say, so the best thing you can do if you don’t know how to plan or deliver your migration, is to involve someone who does. Someone who has experience. AWS offers a vast range of resources through the Migration Acceleration Program, including leveraging partners like Ubertas Consulting to assist with every stage of the migration journey.

Jim Wood
Solutions Architect, Ubertas Consulting

LinkedIn