Cloud Migration Strategy and Enablement

When embarking on a cloud migration make sure you are clear on the vision and outcomes sought. This is required to align the teams and the many stakeholders involved, for this will be a challenging journey.

A clear roadmap should be created communicating the desired end state and the initial steps to get you there. The roadmap then should be updated regularly, repeated to re-enforce, and made visible with progress reported on transparently, as this will provide clarity and build much needed trust.

Typically the main reason to migrate to cloud is for increased velocity and to get access to modern tooling and the rapidly evolving cloud ecosystem. In short, so you are not left behind and can remain competitive. A short term reason might be to exit a data centre before a costly refresh is due. 

Any cloud migration should not be for cost savings alone, as these will not materialise in the short term and will be hard fought. In fact your costs will likely increase along with your footprint if you are successful and your business continues to grow.

Strategy

First decide on what to migrate. I recommend having a single Cloud Migration Owner and decision maker who prioritizes which workloads to migrate first. This would be a senior technical person who can work with the wider business stakeholders as well as the engineering team(s) on the ground. For larger organisations you could have Business Unit Leads who work with the Migration Owner as part of a migration leadership team.

Having a clear direction and migration plan is important. Hence having a single person leading this is critical. Deciding on what to migrate first is complicated and is based on many factors, such as; licensing costs, risk reduction, building up knowledge in key areas, business criticality, stakeholder appetite and batching off apps on similar tech stacks to name just a few.

Your specific migration strategy for each application will be one of the 6 R’s.

For strategic applications you will want to invest and take your time to re-architect or replatform. Thus unlocking the benefits of modern cloud tooling.

If a rapid data centre exit is required, you might choose to lift and shift via rehost. Be warned you are shifting your legacy elsewhere which carries risk. Overtime this will cost you more and potentially be harder to support so ensure you re-assess post migration and find a more suitable longer term solution.

Retire as much as possible. Reduce your legacy footprint and consolidate. Are there other applications within your organisation which serve the same function and can be rationalised? Take a look at your licensing agreements and work out which licenses might be up for renewal soon.

Retain an application which might not be a priority or suitable for migration for now and re-visit later down the line.

Lastly, re-buy. Are there modern SaaS offerings in the market which would better suit your needs? Does an application no longer provide you a unique competitive advantage to build in house? If the answer is yes, then look for a SaaS alternative and reduce your need to manage yet another application. This will enable you to simplify your application portfolio so you can focus on the important value adding areas.

A good guiding principle to remember is to try and avoid hosting applications you have not built yourself. Or as Gregor Hohpe asks, “Why run software you didn’t build?”.

One technique I recommend using to better understand your wider landscape is Wardley Mapping. Facilitating a workshop to build a Wardely map is a great way to collaborate with others on the big picture and define a strategy which can be more easily understood and shared.

Having a good strategy enables a reduction of application portfolio debt and frees up capacity to focus on your business imperatives. Use the opportunity of a cloud migration wisely, be bold and make sure you continue to revisit your application portfolio periodically.

Manage costs

Cost management and controls should be considered and put in place early to avoid an nasty surprises. Use and implement cloud native control to keep things transparent and ensure there is clear ownership and defined accountabilities.

The ideal is to establish a profit and loss for each area which takes into account revenue and total cost of ownership including cloud costs.

To enable this you might need to look at your business structure and possibly look to transform some elements. Can cloud costs be broken down into business aligned areas so Information Technology is not just one giant cost centre? Are there shared services which benefit from economies of scale or are the platform elements that you want to keep consistent? Your cloud account structure can then be set up along these lines to enable clear reporting and accountability.

Getting these structures set up correctly is important. Further guidance can be found from the many FinOps resources available. Including this great Introduction session from Mike Fuller which we hosted at DevOps Perth

Once the migration is underway ensure costing alerts are configured so you can avoid any nasty surprises. Regular reviews should be put in place to ensure your cloud services are right sized and are retired when not in use. You should set this up early and bake this into your cloud adoption strategy.

In the cloud, cost management and resource utilization is now everyone's responsibility, regular reminders, and education will be required.

Choosing a Cloud Provider

The big players in the cloud market largely have feature parity and there is not much between them. There are certain considerations you might want to take into account, do you have an existing footprint, do you have any existing skills or experience within your organization, or are there any specific licensing requirements for the applications which are being migrated.

Going for a multi cloud strategy introduces additional complexity and will slow down your migration, so make sure you go down this path intentionally. Be clear on workload placement and when specifically you recommend certain cloud providers. Understand your architecture and the seams of applications so you can better minimise egress costs. Cloud providers do not charge you for inputting data but will certainly charge you for data leaving their platforms.

Tools such as the Terraform and containerisation platforms can be used as an abstraction layer but you might find there are certain cloud platform features and benefits that you could miss out on. You are swapping one form of lock in for another, the abstraction layer itself.

Reserving resources up front can help reduce costs.  For large scale migrations you might be able to negotiate minimum spend discounts and credits with cloud providers.

Security Controls

To limit your blast radius you should segregate your environments and use RBAC (roles based access control) to control who has access. A common approach is to separate development instances from production and only provide access to those that need it.

A nice example of how this might work can be found here - https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions

Policies can be put in place to enforce security standards. For example, only allow approved virtual machine images to be used or ensure public access is not configured for certain resources. Certain checks can also be automated with compliance as code.

Cloud auditing and monitoring tooling, if used correctly, will drastically uplift your security posture and enable you to be proactive and respond to incidents more effectively. Spend time to configure the tools and ensure your teams can utilize the new tooling effectively.

Conclusion

Be clear on why you are moving to the cloud and ensure there is alignment between your key stakeholders and application teams. Have clear ownership of the migration and use adaptive planning approaches to handle complexity. 

Use the opportunity of a cloud migration to evolve, simplify and modernise your application landscape. Only invest in applications that are required or provide you with a unique competitive advantage. Try to retire and consolidate the rest. Move to SaaS product offerings where it makes sense and try to avoid hosting applications you do not build yourself.

Intentionally design clear structures and accountabilities to manage costs and security. Taking the time to do this upfront is the foundation for future success.