Best foot forward: tales from lockdown cloud migrations

One of my creature comforts during lockdown was learning how to make myself a café-style coffee at home, given that my favourite local haunts had literally closed overnight. This process included working out the best method of grinding the beans, how to froth milk properly, and what different types of coffee drink to actually make. While there are relatively few “top level” options, the lower level options such as bean type, grind amount, syrups, sugar, chocolate, ice, cream, milk type and other decorations quickly balloon the possible permutations. 

If one desires, there are many experiments to be undertaken in achieving a morning’s caffeine hit. Likewise, there are nearly as many ways of deciding how to approach a cloud migration and rarely are two use cases absolutely the same.

To help navigate through the choices, cloud providers are always ready to lend a helping hand. For example, AWS provides some excellent guidance on the “7 Rs” of migration as the fundamental “top level” options, as well as lots of other migration collateral. But how do you make sure that you choose the right approach and tailor it to meet your precise needs? As an As an AWS Partner, BAE Systems Digital Intelligence has been involved with many cloud migrations for our customers, and we’ve identified some recurring themes that are worth looking at to help ensure success.

Good planning is critical
Tales from lockdown cloud migrations planning icon
It is absolutely worth spending time up front identifying everything and everyone that might be affected by the migration. Only then will you be able to decide which migration strategy is right for you. There may even be more than one answer depending on the scale of the migration and on the application landscape. Approach with an open mind and don’t restrict yourself.
 
Start small and learn
Start with a small system or service if this is your first attempt with a team or organisation. This has been critical to success in several migrations we’ve been involved with. Not biting off more than you can chew is a good approach – particularly in the early stages where the environment is new to everyone.
 
I’m very much a fan of the concept of piloting, which I’ve found extremely valuable for proving some fundamental elements: 
•    that the defined migration process works for that service
•    that the underlying target technology works
•    that your teams can work in the new ways required to support the new cloud environment.  

Image caption: Start with a simple application architecture to prove the architecture, deployment and supporting processes all work as intended

The final element is particularly important. While not necessarily fitting into the category of “small”, this people factor should be addressed early as adapting the ways of working to support your new cloud services is fundamental to the success of a cloud migration project. Here are a few key steps to follow:

• Ensure senior leadership buy-in and sponsorship. Everyone, from the top down, needs to be pulling in the same direction and be able to effectively communicate why the migration needs to happen. A tug-of-war contest will make any business activity more difficult, if not impossible, and cloud migrations are no different.   
• Define your goals. What do you want to actually achieve? How will you know you’ve met your objectives? It’s important to quantify these since you want to be able to measure success.
• Put in place a clear governance model. This model should clearly identify roles and responsibilities, and align with your organisation’s information security policy. If this isn’t in place, finger-pointing will take over as accountability will not be clear.
• Train your teams so they know what they’re doing. There’s nothing worse than having teams shrugging their shoulders, at any level. Team leads should be empowered and be accountable for their deliveries. Most cloud providers have certification programmes that can be used as a basis of this training, dependent on their role.

Finally, don’t be afraid to pivot during this phase; find out what has worked well and what is causing pain. It’s better to change to a working approach rather than persist with one that might cause ongoing issues throughout the migration.

Leverage those cloud benefits

Taking advantage of cloud-native services takes away some of the “heavy lifting” associated with running and managing those services yourself. And this is where I would urge caution with the lift-and-shift approach. Yes, it will probably get you into the cloud in the shortest possible time, but you’re essentially moving the application as a monolith, including all its existing support processes, into the cloud. In this situation, you may end up needing to do more than you were doing before. Let me explain…

One of the frequent misconceptions I often come across is that as soon as you’re in the cloud, monotonous (but very necessary!) security patching work becomes the responsibility of the cloud provider. This isn’t the case for Infrastructure-as-a-Service elements such as virtual machines. The cloud customer (that’s you!) is responsible for applying those patches aligned to the policy, whereas the cloud provider is responsible for managing the underlying services. This is known as the Shared Responsibility Model. It could be the case that your data centre provider managed the patching for you in your previous environment, so be aware that this critical aspect will need a strategy within your team (and a good way of reporting whether it’s being done). As always, tools are available to help manage this such as AWS Systems Manager.

The more you adapt cloud-native services within your applications, the more responsibility is placed on the cloud provider to do this heavy lifting for you. It is very much in the interests of cloud providers to offer secure and performant services, since if they aren’t up to scratch customers will simply go elsewhere. This is where the benefits of migrating to the cloud start to become more apparent – more time can be focused on delivering innovation and value for the business as opposed to looking after infrastructure.

If an application is on the roadmap for re-architecting or replacing in the short to medium term, then lift-and-shift might well be a good stop-gap to help centralise the management of infrastructure. If it’s there for the long haul, then it is worth considering a programme of work to (at the very least) re-platform certain components, such as a database, to take advantage of those cloud native services and remove some of the maintenance headaches.

It's not all about cost saving

One of the drivers of moving to the cloud that I hear all too frequently is that “it’ll save us money”. While costs are always an important consideration (particularly the expected costs via a Business Case), it should not be your key motivation for a migration. While not as immediately tangible, the main other benefits of moving to the cloud are:

• Increasing your business agility – make incremental changes that will deliver business benefit more rapidly than before. No need to wait for new servers or other hardware to be ordered and provisioned.
• Increasing your operational resilience – more easily scale to remove single points of failure or increase capacity.
• Boosting staff productivity – where they can focus on delivering business value, rather than managing infrastructure (but see the previous section for caution here).
• Driving sustainability – moving to the cloud can prove very efficient in terms of your sustainability and net zero targets. Tools are also available to track this.
• These are important benefits that need to be called out and agreed, so be sure to include them in the business case.

Talk to us

As an AWS Partner, we have been involved with many cloud migrations. With our experience, we can help you navigate through a cloud migration programme and work with cloud providers to ensure success. This will ensure that your new platform strikes the balance of being secure yet agile – while providing real business benefits. 

About the author

Chris Dudley is a Solution Architect at BAE Systems Digital Intelligence
chris.dudley4@baesystems.com