The Five Principles of Cloud Migration
Published on March 19, 2018 - LinkedIn - Alex Dalwood
Cloud migration is picking up steam. Public cloud providers are growing at 16.98% annually, according to Statista, with Infrastructure services leading this growth. And for good reason – 35% of businesses nominate their legacy systems as barriers to innovation. The same benefits of cloud apply to government agencies. The recent DTA Cloud Strategyemphasises the ability of cloud to increase the agility, flexibility, and speed of delivery for digital services. To take advantage of these and make the move yourself, follow these five principles for success.
How do you eat an elephant? It’s an old saying, but it still applies. A successful cloud migration is built from tackling tasks one at a time. In order to decide what to do first, you need to define what success looks like. This is where your cloud strategy comes into play. Your cloud strategy can be broad and non-specific: move all business applications into the cloud, for example (don't overcook it). Once this is defined, break down all the steps that need to be taken to get there. Then assess the risk associated with each application, service or workload and migrate them accordingly. Easy candidates for migration can be applications like desktop productivity or applications that are already a Software as a Service, like a CRM (low risk).
Once smaller applications are moved, start planning the bigger, more complex, and riskier applications that can be broken into logical components. A service map is a good tool to assist in planning. Don't be afraid of hybrid cloud. If you have a legacy application that everybody is afraid to touch running on a mainframe, for example, move the application tier to the cloud and leave the data on premises.
Remember your virtualisation journey: the lessons you learnt then are just as applicable today in the cloud. Also, don't be afraid to make mistakes. The true value of cloud is the ability to innovate fast. If something doesn't work the first time, tear it down and try again.
Map out your services
After the planning work is done, map the business service offering as it currently looks. Use this layout to identify what parts need to be moved into the cloud, and in what order. You can also use this to decide what aspects are suitable to merge together, and what can be discarded. Then, once you have a list of applications, you can build a risk profile under each application to decide what should be prioritised first.
Define your cloud architecture
Once the strategy and plan have been laid out, map the architecture of how the organisation will look in the cloud. Questions that this map should answer are:
- How will organisational compliance and governance requirements be met?
- What will the services look like in the cloud? How will they talk to each other? How will they be managed?
- How will resource groups be set up?
- How will identities be managed?
- How will customers (internal and external) connect?
- What monitoring services are required?
- How will security be maintained?
- How do we scale (horizontally and vertically)?
- How are critical business services maintained (reserved instances)?
- What will your Business Continuity Plan look like during and post migration?
- High Availability; and
- Disaster Recovery.
The automation mindset needs to permeate the project, from planning, to direction, and finally to execution. Always ask: “can what we just did be repeated, reused, and recycled?” Examples of automating processes that save time are the initiation of a virtual machine and scaling up of capacity using scale sets. The faster the organisation can transition to infrastructure as code, the better the migration will be.
Advice is essential: if the organisation is unsure or hasn’t conducted a cloud migration before, they can benefit from an expert opinion on their cloud maturity or migration. It's a good idea to get advice from a fresh set of eyes up front especially around cloud architecture, governance and compliance. If you want to start your migration with the best possible chance of success, setting up your tenancy with this in mind will give you the best possible result and reduce the risk of failure. There are a couple of events that identify when advice is needed during the migration – if, in the execution of your plan, a migration hits a roadblock or fails, seek advice and try again, or move on to the next candidate, but keep moving forward. Another useful event is during a retrospective. When evaluating the success or failure of a particular migration, it’s a good idea to look back and evaluate with an expert eye what went well, what went wrong, and where things could have been improved. Creating a continuous feedback loop, that will make you more efficient and successful each migration.
Applying these principles
Rinse and repeat, and you’re on your way to your digital transformation. The advantage to this approach is that every application, component or workload moved builds momentum and confidence for the organisation. The benefits, in time, cost, and functionality, will become apparent and limitations of legacy applications become obvious. Also, this step by step approach de-risks larger app transitions, as risks are identified early while working on less critical areas of your business. Remember, Rome wasn't built in a day and just like Rome your Digital Transformation will not happen overnight. – it is a journey, but an easier one to start than you think.