My Top 10 Mistakes to Avoid in Cloud Migration

As I mentioned recently on Linkedin, not every Cloud Migration goes smoothly. Sometimes, despite our best efforts on occasion, we still end up in a state that feels decidedly underwhelming, stressful, or requiring significant modification. Today, we have a comprehensive checklist to avoid falling into the same pitfalls, but here are ten mistakes to avoid in cloud migration.

Lack of planning.

It is easy to get caught up in go fever and “just ship it”™, but in reality, a detailed plan of action, a fundamental understanding of the scope of what’s required and a detailed migration plan covering:

• software
• hardware
• networking
• security
• access/permissions
• administration post go live
• development

And more all need addressing. People need to be assigned roles, and they need to be given detailed instructions on what is required of them. There needs to be a timeline; clearly, you can’t move everything instantly, so when does the data move, and where does the data go? When do the applications move? Who moves them? How are they synced up at switch-over-time? Who’s doing the security audit? And so on.

Lack of in-house experience

Another critical component of cloud migration is experience. Who’s running the show? What experience do they have? How well do they know the internal systems? How well do they know the target cloud platform?

Sometimes, it’s easier to offload the cloud migration process to a team that knows what’s required, can train on the internal side and effect a clean cloud migration and then hand the reins over to the in-house team after a time and cross-training.

Picking the wrong vendor

You’re planning a cloud migration, but which Cloud? Let’s assume you will move to one of the big 3. How do you pick? Well, there are a few issues at play here. Firstly, do you already use a Cloud vendor in another part of the business? If so, does it make sense to shift to that vendor, as there will be some in-house experience? If you don’t use a cloud vendor or don’t want to stick with the incumbent, how do you pick?

• Workload
• Integration
• Cost

There are a number of factors, and we’ll go over them in more detail in a future post. But at a high level, what workloads are you running? Do they lend themselves better to a specific vendor? What integration points do you need? For example, are you already heavily invested in the Microsoft or Google ecosystems? Do you use Amazon Virtual Desktops or other things that would make using a specific vendor easier? Also, of course, another aspect is cost. Each vendor has its nuances, and Google, for example, announced a few days ago that egress costs for people wanting to shut down their accounts would be free; aspects like that would reduce risk but shouldn’t be a driver; you’re expecting this to be a success as it is. Indeed, taking into account the overall cost and the requirements you have put on the deployment is important; HA, Fault Tolerance, DR, etc, all add costs, so what is essential to the migration you are carrying out?

Trying to lift and shift

Lifting and shifting might seem like a good idea, but not building out for Cloud-based architecture will almost always incur higher charges; it will also make the administration more complex and more involved as you aren’t leveraging the managed services, which makes Cloud computing an appealing choice in the first place.

Not lifting and shifting.

Bear with me; I’m not reversing course. There are, on some infrequent occasions, times when lifting and shifting make sense. For legacy services, which are very inflexible older processes, sometimes it makes sense to lift the whole thing, stick it onto an EC2 server or multiple EC2 servers, and keep it running how it always has.

However, this is different from the norm; please only take this route if it makes sense.

Lack of Testing

This is a big one. Just because you migrated the services and data, do they work as you expected? Do they provide the resiliency and response you expect when aspects fail? When things fail, what happens? Does the team know what happens? Is it all documented in policies and procedures?

Testing, of course, means a number of things; what are you testing? Data and service migration: is everything where it is and showing what it should be showing? Have you tested what happens when parts of AWS fall over? It does happen. What effect does this have on operations? Does this fit the SLA, and is it acceptable for business operations? What about security and testing external access? Have you exposed services to the outside world that should be internal only?

There are many things to test, each reasonably specific to the migration.

Migrating for the wrong reasons

What are your reasons to migrate? Cost? Leveraging Managed Services? Reliability? Cool factor? They all play a part and can be right or wrong. A business needs to look at what they are planning and ask themselves what the benefits will be if they migrate to the Cloud, and do they outweigh the current setup? If you’re doing it because it sounds fun, that’s probably the wrong reason. But if you’re doing it to allow for “elastic load capacity at key times whilst our product gets extra usage”, that is probably a legitimate reason. Just make sure you ask yourself what the reason for migrating is. Also, ask yourself what you need to migrate. Do you need to move it all, or can you move a little at a time, see how the migration performs, and make a call from there in the future?

Lack of budget or bad budgeting

How much is all this going to cost? That is a regular question, and with the planning at the top of this project, it is also possible to project. To ensure the plan is detailed enough so that sensible cost estimates can be made. This also allows for some optimisation before the product is launched. On top of this, data into the Cloud is usually free, so that’s not a big deal, but staffing costs will also need to be accounted for, as staff will be working on the migration and not their usual daily duties.

Inadequate security posture and cross-training

What does your security look like? How are external service users going to get access to the system? Where do these users reside? How do developers securely develop new Cloud-centric services? This all takes careful planning and crosstraining to ensure that new and old users are all on the same page when it comes to Cloud security procedures, not only how to keep it secure, but also how to deal with any security breaches detected. The Cloud is not inherently insecure but depends on administering effectively and adequately with the correct guardrails in place.

Lack of Automation

Lastly, another thing that can bring down a Cloud migration is a need for more automation. This manifests itself in several ways. Trust me, I’ve seen them all. Firstly, there needs to be more automation when it comes to deploying services and how the resources end up in the Cloud account in the first place. Hopefully, you will use something other than the web UI to deploy this stuff. Because then, when it comes to moving, changing, and scaling, it remains a manual operation, leading to time-consuming changes and errors. Next up, we’re talking automation when it comes to managed cloud services. For example, EC2 autoscaling groups leverage the automation the Cloud offers to drive down the price only to use the capacity you need or allow HA or Fault Tolerance plans to work seamlessly with auto switchover or replacement of services. Automate as much as you can; you’ll thank yourself for it. As discussed in the previous section, it also helps the framework’s testing.

So, there are 10 top points to consider when planning a cloud migration. There are more. We’re only scratching the surface here, but when it’s critical to the business, you must get it right before, during and after the migration.