The Definitive Guide to Cloud Migration in the Enterprise: Here Be Dragons!
Cloud migration is a big, fat dragon of a problem!
Many enterprises have tried to slay the dragon, few have succeeded.
At least not without getting burned!
But today, we’re going to show you how to dance rings around the fiery beasts!
The Cloud Migration Dragons: The Traps You MUST Avoid Before You Begin
The public cloud is the biggest disruptor that the business world has ever seen.
It allows you to bypass years of legacy technology, processes, thinking and culture.
But lying between you and your successful cloud migration are four dangerous dragons:
- The Lift-and-Shift Dragon: moving workloads straight to the cloud with no changes
- The Divided Cloud Dragon: each team executing on their own vision of the cloud
- The Big Bang Dragon: planning everything upfront and trying to do it all at once
- The Bureaucracy Dragon: implementing too many controls in an attempt to avoid problems
They have the power to send your time and resources up in puffs of smoke, burn down your environments and generally create chaos wherever they go.
But forewarned is forearmed.
In this blog post, we’ll explore the biggest traps (or dragons!) to avoid before getting stuck into your cloud migration journey and we’ll talk you through our battle-tested Momentum Framework for large-scale cloud migration.
This is the process that we used at National Australia Bank to help them migrate 30 apps to the cloud in 50 days. It’s the same process we’ve used to complete over a hundred cloud migrations at some of the world’s largest enterprises.
The Dragons!
Alright, time to get up and close and personal with these beasts.
1. The Lift-and-Shift Dragon
The most common (and most deadly!) of the dragons goes by the name of lift-and-shift.
Definition: The Lift-and-Shift Dragon emerges when you take your existing data centre workloads and move them to the cloud without any changes
This dragon rears its ugly head when the leadership decrees that you must adopt the cloud…and that’s about it.
In the face of tight deadlines and a back-of-a-napkin strategic vision your teams inevitably attempt to get to the cloud in the quickest, bluntest and most efficient way possible.
Lifting and shifting your workloads, as they are, into the cloud is without doubt the fastest way to get to the cloud, and showing fast progressive is attractive. However this approach is quick only in the sense that driving straight across pavements and through red lights is the ‘quickest’ way to get to work.
Both result in disaster.
The Consequences
You Will Set Fire to Your Budget
This dragon will burn your operating budget to cinders.
One-to-one lift and shift is fast but extraordinarily expensive. On-premises workloads are designed for the maximum possible load, which will only be in use for a fraction of the time in the cloud.
You Will Give Technical Debt Eternal Life
With lift and shift, you bring your problems with you.
Your existing systems are most likely riddled with various hacks, bugs, and various other critical aspects of the system held together with duct tape and super glue.
You Will Completely Miss the Biggest Benefit of the Cloud!
The real benefit of the public cloud is that it allows you to break away from legacy ways of working.
By lifting and shifting you keep all of your existing processes, with all of the related lead time and operational costs.
The only thing you will save on is the cost of one-time infrastructure purchases, and the operating costs associated with keeping a data centre running. This is not enough to justify a cloud migration!
2. The Divided Cloud Dragon
The Divided Cloud Dragon is less deadly than the Lift and Shift Dragon, but it can still ensure that your migration creates a quagmire of mismanagement and confusion.
Definition: The Divided Cloud Dragon rises when there is no cohesive vision uniting the leadership and the teams. They each pursue their own individual strategy, resulting in fragmentation and confusion.
There is little thought for shared services, reusable code bases, common lines of communication...meaning that opportunities for re-architecture and collaboration are missed.
Being scorched by the Divided Cloud Dragon means that you will be introducing significant confusion and uncertainty in your organization.
The Consequences
Confusion Will Reign
There will be much confusion over what exists, where it lives, and why things are the way they are.
Systems will fragment, environments will drift, and your cloud provider bill will increase faster than you planned for. You will have to use shortcuts to make everything work, and this creates significant technical debt.
Untangling these threads at a future date can be very expensive!
Your Organisational Health Will Suffer
The lack of a centralised strategy will make it difficult for teams to share operating patterns and data with other teams in the organisation.
Employees will be confused as to what they should do and how they should operate. This reduces employee satisfaction and increases burnout and turnover.
You Lose Critical Opportunities to Learn Lessons
With everyone doing whatever they feel is best in a vacuum, there is little to no opportunity to share lessons learned, best practices, focus on reusable assets, or be collaborative as a group.
This makes your cloud programme much weaker than it otherwise would be, with expertise and knowledge lost in silos. It significantly reduces your agility, and makes it difficult to react to market forces in a speedy way.
3. The Big Bang Dragon
The leadership knows what their strategy is and has a clear vision of how to get there: namely, move everything, all at once. The big bang!
Definition: The Big Bang Dragon stirs when the leadership carves out a detailed vision, tries to plan everything upfront and execute all at once – typically with great fanfare and no margin for error.
The Big Bang Dragon is the opposite of the Divided Cloud Dragon and will set up your entire cloud programme for massive failure.
The central error is the idea that, with sufficient planning, any risks or unknowns can be overcome in advance!
In an attempt to control the future, traditional project managers draw up reams of roadmaps, charts, dependency lists, 24-month schedules, responsibility indexes and so on…
Instead, it stops you from doing anything!
The Consequences
The Inorganic Approach Courts Failure
It is impossible to predict the best strategy for the successful migration of every piece of business logic in your organisation. Trying to do so upfront will most likely fail.
Your strategy needs space to learn and pivot in response to the emergence of unknown unknowns.
You Won’t Have the Space to Learn from Mistakes
In the big bang scenario, when a mistake is made, the shortest, most direct solution is implemented to keep the project on schedule.
The quick fix is very often not the best solution in the long term, and it deprives the wider team of the opportunity to learn something valuable from the mistake that could improve the next migration wave.
You Won’t Have Space to Be Data-Driven
When proceeding in a big bang style, you can’t collect all possible data points before starting a project of this magnitude. Nor will there ever be any time on the timeline to capture data as the project continues.
Everything will be to the letter of the plan and new data points that should give you pause will be ignored in favour of driving the project through to completion.
You Ignore Technical Debt
Even if a significant opportunity to rearchitect a core component of an asset is identified, it will be thrown into the cloud with no regard for the trouble it could cause down the road.
A deadline slips here...then another there, at which point the requirements are tweaked, which then throws another team out of whack...and so on in perpetuity.
These minor problems compound until the grand cloud vision is left in tatters with nothing meaningful delivered.
Your Employee Empowerment Suffers
During big bang cloud migration projects, schedules are tightly controlled, directions are set, and individual contributors are thrown into the process headfirst.
With little to no control over their own day-to-day tasks or the strategy of their initiative and no space to experiment, employee burnout sets in.
4. The Bureaucracy Dragon
Policy in and of itself is not a negative, but when it is used to suppress the symptoms of the problem, rather than the root, it turns into a deadly dragon!
Definition: The Bureaucracy Dragon awakens when governance teams overreact to changing conditions, creating new policies that stifle innovation.
Policies are usually created at the onset of a new strategy, or after the occurrence of some significant problem. The goal is always to prevent future problems from occurring.
The issue with this approach is that often policies attempt to limit what people can do, rather than enabling people to act however they need, but in a safe environment.
Example: it is very common for an organisation to dictate that developers should never—under any circumstances—have access to a production environment. This is to theoretically prevent some developer from unknowingly breaking a production build.
The issue with this approach is two-fold:
- You don’t trust your developers
- Your policy is focused on the wrong thing
If your intent is to prevent anyone from breaking a production build, then your policy should not be to stop your developers, but to create automated tests and checks to make it impossible for anyone at all to ever possibly break the build.
Your policy should be focused on the production build process itself—not your developers.
The Consequences
Lack of Ownership Depresses Your Developers
Good developers need to be given ownership of their products. They desire a functional, reliable, bug-free application to nurture and care for.
When policies unduly remove developers’ authority over their application or team it’s incredibly disheartening. The devs will feel that lack of ownership and this will be reflected in the final product.
Bureaucracy Grows and Stifles
Policies are created to address and prevent problems, but since problems will always continue to occur regardless of how locked down your organisation is, you are in effect signing up for an ever-expanding network of policies and controls.
Bureaucracy intentionally restricts the movement of your employees and is antagonistic to learning how to work in new ways.
It’s all well and good knowing what dragons you might encounter on your cloud migration but next, we’ll give you the tools you need to slay them.
The Definitive Guide to Cloud Migration in the Enterprise: Here Be Dragons!
Cloud migration is a big, fat DRAGON of a problem.
Many enterprises have tried to slay the dragon, few have succeeded. At least not without getting burned!
In this white paper, we'll explore the four dragons that are most likely to burn your transformation to the ground and the tools to slay them.
How to Slay the Dragons With Our Momentum Framework
Momentum is a dragon-slayer.
Derived from Contino’s experiences across hundreds of enterprise cloud migrations,
Momentum is a data-driven roadmap for transforming enterprises to a cloud-native operating model.
The framework consists of five phases (Nurture it, Plan it, Prove it, Scale it and Improve it) and is designed to facilitate an organic, delivery-first cloud migration that proceeds wave by wave, gaining momentum each time.
What is the purpose of each phase and how is it carried out?
1. Nurture It
When focusing on your next big IT programme, whether that’s cloud migration or application rearchitecture, you need to take time to outline your objectives and align strategies.
A goal of “migrate to the cloud” is very vague. It’s not a strategy or vision.
This phase exists to make sure that everyone understands what the intents and goals of the program are.
Objectives:
- Educate stakeholders on the implications of cloud and get full buy-in from all critical stakeholders
- Develop and seek alignment on why you are moving to the cloud and the benefits of doing so
- Present the Art of the Possible: what could your cloud migration potentially do for your organisation as a whole?
- Refine cloud migration objectives to align with business goals and drivers
How:
Educational Workshops
Stakeholder workshops are an opportunity to unify the understanding of the cloud, align on what you want to achieve and how you will get there.
Discern what best practice looks like, what dragons to watch out for and get excited for the changes to come!
Stakeholder Alignment
If the stakeholders aren’t aligned on the high level strategy, the initiative will definitely be hindered.
We’ll work together to ensure that all stakeholders know what is happening, why it is happening, and how it will happen to ensure alignment before we get started.
Discovery Sessions
You need to know what your current state is before you try to change it.
These sessions consist of interviews with your architecture and application teams to better understand what the current landscape looks like, so you know where you’re starting from.
Cloud Readiness Assessment
It’s important to know exactly how cloud-ready your organisation and teams are to move to the cloud.
We’ll perform assessments with your teams, which will help us make better decisions in the next phase of this framework.
DRAGON ALERT: Key stakeholders must unite to fight the dragons!
The Nurture It phase is absolutely critical to ensuring that we don’t run across any of the dragons, in particular the Lift and Shift and Divided Cloud dragons.
These dragons thrive on chaos and confusion. Getting alignment between all the stakeholders as to the overall intent of this initiative, and clearly setting expectations will help the migration be a success.
2. Plan It
Now that everyone is on the same page, a pragmatic plan is necessary.
This plan needs to be limited in scope to minimise the potential blast radius and provide the best environment to gather lessons learned.
The best way to target this is via a lighthouse-style approach. By targeting a particular workload or application for migration, we can run an end-to-end migration but within a limited timeframe, and within a limited budget.
The outputs of this lighthouse project can then be applied elsewhere in the organisation, thereby creating the opportunity for viral growth.
Objectives:
- Plan a lighthouse project to test a given migration approach
- Get a transparent view of what workloads exist and where
- Identify a ROI-driven hierarchy of applications within the portfolio and business units for cloud migration
- Develop the business case with a full total cost of ownership and benefits analysis
- Develop high-level solution architecture and technical considerations for the cloud platform build
- Develop cloud strategy and cloud governance development considering information security and data governance
How:
Discovery and Assessments
Before a scaled migration, it is critical to understand the current landscape in terms of applications, cloud readiness, levels of automation and also working practices and skills.
This is also the phase where it is critical to perform app discovery and rapid assessments of the technical landscape:
- What exists and where?
- What other systems are they tied to?
- Are there any monolithic centralised processes or systems that are in scope?
- What greenfield opportunities could be targeted to showcase best practice?
This helps us to determine a reasonable timeline for migration and identify which systems can be targeted first as low hanging fruit.
Identify Initial Workloads for the Lighthouse Project
Once you have completed the discovery phase, map out which workloads will be best suited to your lighthouse project.
Certain applications will be very complex to migrate but won’t add that much extra value once in the cloud. Others may be quite simple to migrate and will benefit greatly from their new-found scalability.
Mapping the complexity against the potential ROI will help you to isolate those applications that are most suited for the first wave of your cloud migration.
Modelling, Scoping and Writing a Business Case
Now that we’ve identified the work to focus on, we will need to scope that work, as well as discuss high-level technical solutions. The goal here is not to solve all the problems, but to get everyone on the same page as to what is going to happen, and why.
Once we have focused on our strategy and approach, it is prudent to build a business case for our initiative. This effort will highlight the benefits, risks, and technical solution needs before the initiative kicks off, and will serve to reduce the leadership’s anxiety.
DRAGON ALERT: Everyone has their own ideas—centralise your strategy
By this point, we’re on our way to solidifying our strategy.
The dragon most likely to set fire to our plans now is the Divided Cloud Dragon.
Even assuming we’ve successfully aligned leadership’s expectations around cloud migration and what it is and can be, that doesn’t mean that every stakeholder has the exact same personal goals for the initiative.
Using the lighthouse approach is a great way to organically move your migration forward, but we also need to be aware of any other parts of the organisation that may be performing their own migrations with their own strategies in place. Everyone will need to do their due diligence to ensure that your efforts don’t take place in a vacuum, and that your strategy has buy-in across the board.
3) Prove It
After we’ve put together our plan, we need to prove its principles before we go all-in.
It’s impossible to predict what problems and issues will arise in practice until you start moving workloads.
During this step we will identify and execute a lighthouse project migration, upskill the relevant app team(s) to work with a cloud-first, DevOps mindset, and focus on total team transformation and maturation to best realise the benefits of the cloud.
Then there will be actual functional production code running in the cloud. This is your first big step towards realising a great cloud migration!
Crucially, we then learn what we can from the problems that arose and shift our approach accordingly for the next wave.
Objectives:
- Limit the blast zone by executing a limited-scope lighthouse project, thereby de-risking migration while demonstrating progress
- Learning key lessons from the problems and issues that arise from an actual migration
- Significantly change the way the team operates by taking time to try different technologies and methodologies
- Focus on healthy migration by addressing tech debt immediately, and addressing problems head-on. No quick fixes!
- Upskill the team via pair programming and learning sessions as to why we utilise DevOps best practices, and how to apply them to your day-to-day
How:
Migrate the Chosen Workloads to the New Cloud Environment
Use output from the discovery phase to identify areas of the system to ‘break off from the monolith’.
These candidates for migration should be initially limited in scope. Test the migration process in a smaller box—see what works, what doesn’t and adjust accordingly.
Take some time to re-engineer your workloads--utilize cloud native architectures and techniques to migrate individual sections of business logic to the cloud. Think about what other parts of your organization could utilize the business functionality you own. Continue to address tech debt as it appears, limiting or eliminating any lifting-and-shifting.
Reconnect with Rest of the Business
Connect cloud assets back to existing core system to maintain functionality.
This encourages the use of microservice architectures, and introducing concepts like Test Driven Development to automatically ensure that changes to the system do not retroactively break something.
Upskill Your Teams in Cloud-Native Ways of Working
Have your internal teams do much of the migration work to build skills across the organisation and federate the cost.
New workloads will be proactively built on the cloud, while existing workloads will be migrated in an ROI-driven manner.
DRAGON ALERT: Disrupting the Traditional Governance Model Creates Anxiety
When teams break away from the monolith and go to the cloud they suddenly realise they have their own path to production.
We’ve seen this everywhere: teams begin speeding up their release cycles, reducing their time to market, and massively increasing the speed at which they can develop new functionality, and respond to issues.
This naturally causes disruptions to traditional governance models. It is here that the Bureaucracy dragon can appear, when enterprise QA teams and Change Control Boards get anxious and can disrupt or even halt progress.
To address this, it is critical that you adopt an operating model that is suited to the new-found speed and agility of the cloud.
4. Scale It
Now that we’ve proven a route to the cloud it’s time to scale our initiative.
This means taking what we learned in the Prove It phase and applying it to the next wave of migration.
This expansion can take many forms.
Some organisations are most suited to establishing a Cloud Centre of Excellence (CCoE), some scale best using a viral approach that has the upskilled team during the Prove It phase go and upskill their peers on another team. Sometimes it is a combination of these two, among other methodologies.
Each organisation is different and scaling your cloud migration strategy will never be a one-size-fits-all solution that can be prescribed.
Objectives:
- Take the lessons learned in the Prove It phase and apply them to new waves of migration or other areas of the business
- Expand the lighthouse project to other applications and workloads
- Expand cloud-native skills to other teams
How:
Now that we have proven a path to migration in one area, we can expand that approach across the business.
You need the right mindset, the right teams, the right model, the right skills, and then you let the migration continue to unfold in organic waves.
Move from a project to a product approach
Projects create problems.
After a project is completed, the ownership of the assets gets assigned typically to an operations team. The project is then considered “done” and any new functionality requires new discussions, new budgets, new pain.
Maintaining a product mindset means your organisation is always ready to upgrade and improve.
Foster a DevOps mindset
DevOps is a way of working. Working with a product mindset implies that the teams doing the development work are also the same teams doing the operations work. This is the core of DevOps.
Encourage your teams to own their product from ideation all the way through production. This will ensure that the teams design, architect, and develop with the long-term in mind.
Utilise Cloud Native Architectures
A huge benefit of migrating to the cloud is the ability to utilise cloud-native managed services.
These tools allow you to focus on application logic without the need to worry about the underlying infrastructure. Instead of spinning up a new VM and installing database software on it, you can click a button (or use an API) to spin up a database, instantly getting access to the full range of tooling you need, with no delay.
Everything from network and databases to artificial intelligence and data analytics are suddenly available at the push of a button.
Create a New Governance Model
New platforms mean you need to rethink your governance policies and procedures. QA, security, change control...all need to be revisited to focus on how to enable development teams while reducing risk.
A good first step is to look at infrastructure-as-code and compliance-as-code.
By minimising the number of manual steps needed to deploy infrastructure, code, and manage compliance, you enable your governance teams to put automated checkpoints in place that manage policy without a single person needing to be involved.
For instance, if your cloud security policy is to ensure port 22 is disabled on all cloud VMs, then an automated check as part of your CI/CD pipeline can catch any violations and prevent them from being deployed.
Establish a Cloud Centre of Excellence (CCoE)
A CCoE is a cross-organisational group of cloud practitioners sharing knowledge and best practice.
This is great to build the necessary centralised automation and put into place best practices such as account structures, environment design, security, key automation processes.
The cloud platform team is a centralised department that provides templates and a shared CI/CD pipeline to federated development teams to begin onboarding onto the cloud.
Make Waves: Scale It Organically!
This is the final piece of the puzzle. To avoid that Big Bang Dragon, we’ll focus on scaling our transformation organically in iterative waves.
No two IT organizations are the same. Each must learn their own lessons by experimenting within their own businesses.
Our first lighthouse during the Prove It stage was wave one. We’re going to take what we learned from wave one and apply them to wave two. Then we’ll take what we learned from wave two and apply it to wave three, and so on. Each wave getting bigger and reaching further as lessons are learned and changes solidify.
A Final Word on Scaling
Bear in mind that you are moving to the cloud to take advantage of cloud-native ways of working.
When migrating a particular system, carefully deconstruct its functions and then determine the best possible way to utilize the power of the cloud to recreate that functionality—primarily through cloud-native development.
This means that these migration efforts should take advantage of managed services and the like. The future of your current legacy system could be one where your business logic doesn’t require any infrastructure at all!
DRAGON ALERT: Don’t try to regulate everything
At this phase we run the risk of being attacked by the Bureaucracy Dragon again.
Scaling requires a lot of involvement from senior architects and executives—especially as you continue to collect more data about what’s working and what’s not.
These senior employees will use their many years of experience to predict hurdles and attempt to address them sooner rather than later. The only potential issue is that these problems will be viewed in the lens of the existing operating models rather than the new models we are introducing. This means that you have to be very forward-thinking when contemplating new policies and procedures—think about the way you wish for your organization to holistically operate and you will begin to envision the policies that need to exist.
5. Improve It
Now your migration is done!
If only.
Now that we’ve gone from a project to a product mindset, your teams will realise that there is always something to improve.
Naturally, during a massive migration effort—no matter how organic it may be—there will be some work that was performed that didn’t take full advantage of the cloud, that introduced some flawed logic or even created the opportunity for future improvements by way of utilising autoscaling features that can make your applications more responsive and more redundant.
This improvement work will be identified by the development teams themselves as well as by the collaboration through your CCoE.
The teams can then sync with the business at regular intervals to understand future feature requests and how best to balance those with the regular, continuous improvements to be performed in this new environment.
Objectives:
- Continuously identify and work on opportunities to become more cloud-native
- Balance new work with cloud-native improvements to existing workloads
- Maintain alignment with business objectives
How:
Continue Enabling Your Teams
Ownership and enablement at this point is the most important thing to internalise in your newly transitioning organisation.
Teams will begin directly asking for time and budgets to focus on new ideas, new tooling, new research and development work. It is your job to find the best way of enabling this behaviour while ensuring you maintain a semblance of order. This will require a project to product paradigm shift, as well as financial finesse to reorganise budgets to suit.
Don’t Build Ivory Towers
A typical outcome of a successful cloud migration is a mountain of praise being thrown at the team members and leadership involved in the migration. That’s great!
What you have to watch is that the successors of this migration do not become the lords over the rest of your organisation. When you form your CCoE, you’ll want some of your biggest movers and shakers to be involved, but their rotations in this CCoE should be short enough to identify other prime candidates, and get them moving and operating under the new paradigm.
Ideally, your CCoE will have an ongoing rotation of those that are cloud experts, and those that are eager to learn but don’t know how.
Always Be Dissatisfied
The Improve It phase never ends.
You must embrace Kaizen (continuous improvement) and apply it everywhere you go. Justifying the status quo by claiming that that’s just “the way things are” should be forbidden!
Always change, limiting the scope of those changes to reduce any potential fallout. This way your organization truly evolves by keeping what works and discarding what doesn’t.
DRAGON ALERT: Amidst the warm glow of accomplishment that follows migration success, be careful not to let your guard down! Any and all of the dragons can reappear at this stage.
The Lift and Shift Dragon can reemerge because the successes of one cloud migration means that other areas of the business will want to move to the cloud and to do so as fast as possible!
The Divided Cloud Dragon can reemerge if the migration is now deemed “complete”, with the longer-term vision and strategy slipping as individual teams go off doing their own thing.
The Bureaucracy Dragon shows up after your successful migration attracts the attention of the rest of the business. Players who weren’t interested in the past will show up at this point to tell you what you’ve done wrong. The first team to successfully migrate to the cloud may have had full admin privileges, but now the legal department is telling us that no developer should ever have any form of access to a production environment.
These dragons will devour and raze even the most successful migrations, and leave an entire IT organization feeling devalued and hopeless! Executive championship is absolutely critical at this stage. Obtain it ahead of time.
So that’s how we use the Momentum Framework to slay the vicious cloud migration dragons and live happily ever after.
Sounds good, right. But where’s the proof?
We used the Momentum Framework to help National Australia Bank to migrate 30 apps in 50 days.
There we have it, folks.
We hope that we have managed to point out the very real danger of the cloud migration dragons as well as how you can quench their fire!
Good luck!
Of course, this is far from all that is to be said on the topic.
You’re going to need to develop a cloud operating model as well as a proper business case. Maybe some help with DevOps or SRE.
