So, you’ve decided to undertake a cloud migration. Your tech is about to get faster, cheaper and shinier.
You might also be a bit worried about how you’re going to move everything over and whether it’ll all work. Or maybe you’re trying to figure out the challenges involved before you take the plunge.
Migrating everything to the cloud, or even just switching providers, can be quite an involved piece of work. It’s worth making sure you’ve planned it all out and considered all the risks and challenges up front.
Decisions, decisions
The first thing to figure out is what do you really want? What are you hoping to get out of this? What does a successful project look like to you?
I’m sure this migration isn’t being done for the sake of it. Presumably your organisation needs something faster, the ability to handle increased demand, less downtime – you’ll get these by migrating but it’s worth keeping that in mind when it comes to making your decisions.
Choosing how to design the new solution can be trickier than it sounds as well. You might have clear requirements on what you want but there’s many different ways of getting there and a fair few factors to consider along the way.
Some of them are obvious i.e., what cloud provider to use? Genuinely it doesn’t matter, the big 3 are pretty much the same.
Whereas some things are up for discussion. When you consider the general architecture of your solution, how you plan to ingest, process, store, and analyse data, there’s a few things to bear in mind. Namely, the cost, speed, reliability, and accuracy of your platform.
Presumably you’ll want cost as low as possible, and the rest of those to be as high as possible. It’s going to be a trade-off though, realistically it’s only possible to get 2-3 of those so prioritise accordingly.
For example, if you need things to be as fast as possible it’s likely to mean your data isn’t always 100% accurate and the platform might cost more. You need to be asking yourself which is most important to you?
It’s also worth considering the people who are going to be involved in this as they have to be able to build and maintain it.
What happens if something were to break? How easy would it be for a support engineer to get things running again?
All of this needs to be factored into the design right from the start. Having worked in support myself for a while, I’d highly recommend talking to them when you’re in the design stage; they’ll know from experience every possible way a user can break your system.
Acknowledging things can go wrong
Speaking of things that can go wrong. I’ll be honest, there’s probably going to be a lot of them during the migration. There’s a lot of challenges to consider and the sooner these are considered, the less of an issue they’ll be.
Assuming the simplest option – replicating what you’ve already got like for like in the cloud – also known as a lift and shift. Unless you’ve got a very simple platform there are going to be subtle differences in the two environments, and programs may even behave differently. This means tests need to be changed, some parts of your software might need changing to fit, and so on.
There’s a pretty good chance that your platform, and your migration, is more complex than that though.
I’m guessing there was more than just ”ooh clouds” that has been a factor in you making this move. You might want to utilise some of the tools available in the cloud to help you deal with your data better, you might just need to merge it into an existing system to save money or meet compliance.
Whatever the reason, I would imagine that the project ends up being more than a basic lift-and-shift. These projects are naturally more involved.
Avoiding common cloud migration pitfalls
Bearing all of that in mind, here are the top five issues I’ve seen in migrations and how to get ahead of them:
Unclear requirements
It’s a bit of a danger area with migrations because the temptation is to just say that you want it to be the same as the one you already have.
As I’ve established above though, there are going to be a lot of cases where that isn’t quite possible so requirements should still be clear as if this were a project for a new piece of work.
Testing
Especially regression testing. This has happened on every single migration I’ve been a part of; the test is that everything in the new and old solution match up 100% and behave in the same way.
Every single migration that has been the standard, until someone realised it was an unattainable standard. Things won’t match 100%, there will always be edge cases.
Your migration team might even have fixed bugs that were present in your old system, giving a completely different result. Either way, you’re very unlikely to get things behaving 100% the same.
Testing will be more complex as a result, so it’s important to break that illusion as fast as possible.
Deadlines
They will be missed. It always happens; things end up taking longer than anticipated.
Often there is additional complexity or other unknowns that surface once things are already underway. It’s not just the case for software projects, I think it happens on virtually every project worthy of the title.
Either way, it’s important to bear that in mind, consider the impact of a delay, and plan accordingly. The more prepared you are for a delay, the less impact it’ll have when it happens. It will also help you prioritise on the most important things to minimise impact.
Scope creep
Of course this was going to be in there. Scope creep is when the agreed scope keeps getting extended to include extra things.
A little bit here, a little bit there, and suddenly it’s a massively bloated project. On the other hand, there is risk in sticking rigidly to a scope and not changing it. It might turn out that an existing system needs a redesign because it’s not fit for purpose, or there are some areas where expanding the scope slightly can add a huge amount of value.
Constantly keeping your end goal in mind, the one you thought of at the top, is important so you don’t end up being overwhelmed. Similarly, any increase in scope should be considered in terms of value over effort so make sure it’s worth it. I also think it’s useful to involve the developers, particularly the support ones, at the early stage when defining the scope.
Siloed teams
This is an evergreen topic, but I’m including it because migrations often involve larger teams which increases the risk of this happening.
People in different areas will understand things differently and with siloed squads this can lead to crossed wires and misunderstood requirements.
You might for example get a lot of back and forth between the QA and development team over whether a service works, because they’ve interpreted what it’s supposed to do differently.
Here’s another one. I’m putting together a data solution but there’s something wrong with the requirements so I can’t get it to fit.
A siloed approach would be to push it back to an architect, they have a load of meetings and give us new requirements, then go through that whole process again once the solution is in UAT because they have the old requirements.
Or, if I’m not in a siloed team I can get on the phone with the analyst who’s using that solution and whoever’s going to be writing the acceptance criteria and figure out what’s needed there and then.
That way everyone’s on the same page and I’m presenting the business with the thing they actually want.
Migrating success
Well, we got there. I hope this hasn’t put you off the idea of working in the cloud, it’s not all doom and gloom!
The truth is that although there are a lot of challenges in getting started, once you’re on the way it adds so much value that it’s not surprising that’s where everyone’s heading despite the initial challenges.
I have spent the past 4 years working on a variety of cloud migrations of varying sizes and the five issues I’ve highlighted above have happened every single time. It is quite likely they’ll happen regardless of how you do things, but at least you’re aware of them and able to look out for those pain points.
The sooner you’re able to identify them, the more successful your project is going to be.
