12 Tips for a Successful Cloud Migration
When establishing a team, avoid outsourcing and getting others to own the migration outright. Otherwise you are effectively “building out tomorrow's legacy application[1]”, as anyone who is not involved in the migration, yet left to support and manage these applications will struggle . The same principle applies for building new applications regardless of platform.
Instead, establish a cross functional team. Engage expertise from cloud solution providers and partners to assist and help you build up the required knowledge internally.
Include relevant team members from your own organisation to work alongside these experts. Gaining this hands-on experience is crucial and cannot be replaced by online training and certification alone.
Engage and include the people who are going to be impacted by the move to cloud, such as hosting ops, DBAs and sys admins as this gives them an opportunity to uplift their skills and will reduce the natural tendency to push against the change.
Use pairing and mob programming sessions to help spread knowledge. This can be done effectively by screen sharing in remote contexts.
// Build knowledge and capability internally
To start off the migration you should define an agreed process with the team and a common definition of done (exit criteria). This can include things like; what type of apps require performance testing, what approvals might be needed, how will the documentation be updated, are there any regulatory requirements, does the migration include retiring and cleaning up the old systems, etc.
Another nice idea, which came from one of the cloud providers I worked with was a “migration party”. The party involves getting the key stakeholders and migration team together to kick things off and plan the migration. This would be a good way of establishing an early relationship and building trust. It would also help connect the team with the right stakeholders and open up a direct communication channel.
// Involve the right people early
For the migration you should establish a set cadence and key events. The Scrum Framework can be used and helps teams to collaborate effectively. A complex technical migration suits an empirical process, where the team can transparently inspect progress, be able to adapt to the challenges encountered and raise issues or impediments that require support from management or external parties. Challenge the team to try and complete a migration of a simple app within a sprint. This should be possible and will help the team focus on reducing waste and minimising bureaucracy.
Avoid trying to migrate too many applications at once. Having focus will enable the team to complete a migration much faster. Multitasking is known to kill productivity and will slow the team down. It often leads to longer wasteful meetings, too much chatter and ineffective communication, and blockers or impediments being accepted rather than swarmed on to be resolved.
// Go Slow to Go Fast
When migrating several applications keep a record and monitor the cycle and lead times. The first couple of migrations will naturally take longer as you build up the required skills, code and templates. Each application will have it’s own complexities but you will find certain patterns that an application might fit into (three tier application for example). You’ll then be able to use the empirical data you have gathered on cycle times of similar applications for forecasting.
You could also consider establishing a reusable runbook and guidelines to bootstrap further applications you might be looking to migrate.
Try to keep the core of a successful migration team together and dynamically re-team if there are skill gaps or swap in and out key SMEs as required. Intentionally rotating different members of the application support or hosting team so they can also be upskilled.
// Leverage experience to accelerate and use past performance to improve forecasting
Ready for Lift-off
Deploy your application to the new cloud environment and run some tests in the soon to be production instance. This could be with a test dataset or pointing to a live back end (just be mindful that you might need to clean up any records inserted). This is the only way to truly test performance and confirm everything works before flipping the switch and updating your DNS.
It will also build up confidence with key stakeholders prior to going live. Consider approaches to trigger conditions to ensure your monitoring and alerting is working as expected.
// Test in production and trigger alerts
Ideally you will be able to test on a small scale first and direct a portion of live traffic to your newly migrated instance. Depending on the type of application this might not always be possible.
Ensure you have a kill switch or a well defined roll back strategy. Have the right people around to be able to diagnose issues and fix forward where possible. It is unlikely you will have everything perfectly integrated or configured on your first go.
// Be prepared for surprises
Run a simulated scenario workshop to confirm the process and procedure for when things go wrong. It is best to discuss this up front and confirm there is alignment or if there are gaps to be addressed. Document what is agreed, set up the relevant alerts and ensure everyone has access to the required systems and contact numbers.
// Explore and simulate scenarios before they occur for real
If you have successfully followed the above instructions then the amount requiring handover will be limited. You will have involved the internal teams who are going to be looking after the application long term, so there isn’t really anything to handover.
// The best handover is no handover!
That being said, there is still value in having a set of key criteria to review the implementation. This review should focus on potential security issues or supportability to assess if there are any gaps in key areas. For example:
Has any additional access that was granted as part of the migration been removed?
Is the monitoring and logging set up correctly?
Do the correct teams have access to support the application?
At Google they call this PRR (Production Readiness Review) which is part of their popularised set up with SRE Site Reliability Engineers. This approach has some interesting ideas that you might want to consider, even though few are running at the scale of Google.
I recommend doing the review collaboratively as a team over filling out a document for submission and offline review. Invite a third person in to review and confirm the key elements. Demonstrate the implementation in the actual systems or discuss the process you undertook, then simply document the outcomes, minutes and any follow up actions in real time. Make sure someone is on point for any further remediation actions and that there is a follow up in place.
// Collaboratively review key areas and remediate
This is just the beginning!
Deploying or migrating your first set of applications to the cloud is just the beginning of your journey. Ensure any new apps are closely monitored for issues and re-assessed for right size tuning for performance and cost savings.
// Set aside time to closely monitor and tune post go live
If your company is large enough, more than a couple of teams, I suggest setting up an engineering forum where content can be shared and discussions had around architectural choices or lessons learned.
It is also a good idea to set up a channel in your group chat tool of choice where people can ask questions and seek help from others internally.
I have seen this being particularly successful in larger enterprises where the cloud team and experts were being routinely swamped with requests. By having an active channel you might find people organically support each other rather than all the requests going to one team or an individual, which would otherwise result in a bottleneck.
// Focus on spreading knowledge and build a supportive environment
The hardest part of your cloud journey is likely to be growing, hiring and retaining good people.
The smart companies will set aside time for people to learn and acquire new skills. An easy way to do this is to build in some slack and block out a set period of time for people to upskill.
The technology and cloud space moves at such a quick pace that your engineers will always need to be on a learning journey. If you do not provide them space and instead expect them to upskills in their own free time then you will simply lose them to a place that does afford this, or provides opportunities to grow in other ways.
It is inevitable that as a company you have people who will leave, but losing good people and hiring is very costly and challenging. You should do all you can to reduce this.
A more intentional and focused approach is to set up Learning Labs, also known as Dojos, where teams can experience firsthand new cloud technologies and the specific set up and implementation at your company. Facilitating collaborative learning in this way ensures attendees can access the required systems, gives them knowledge and confidence and provides an environment for accelerated group learning. Having time focused on deliberate practice away from a delivery also enables the acquisition of new skills and will encourage innovative thinking.
// Intentionally structure group learning
Thanks for taking the time to read my post. Hope you found these tips and ideas useful for your own migration. Please reach out if you would like to talk about how I could help your organisation with it’s cloud migration journey or if you are interested in establishing a facilitated Learning Lab
References
Some inspiration and resources mentioned below.
[1] Rich Bean, Department of Transport, WA. Speaking at DevOps Perth panel on successful cloud adoptions - https://youtu.be/qqBl1IsuHWI
Google SRE book - https://sre.google/sre-book/evolving-sre-engagement-model/
DDDPerth 2019 - James Miles - Coding in Interviews - https://www.youtube.com/watch?v=XzBYGHD-llc
Learning Labs, Run by Cohezion - https://drive.google.com/file/d/1BVv_2h8k8Zzb7nq9l2JoANQlfNTO0HFG/view
Dynamic Reteaming, Heidi Helfand - https://www.oreilly.com/library/view/dynamic-reteaming-2nd/9781492061281/