Why are we still talking about cloud migration?

By: Pedro Soares

The topic of workload migration certainly isn’t new, but that doesn’t make it any less relevant. With or without public or private cloud scenarios, moving applications and other infrastructure components to cloud can be a complex, risky journey. Even so, cloud migration can drive huge value when it’s done right; for that reason, it’s a topic you’ll continue to see for quite some time as the adoption of different cloud models and runtimes increases.

Before I discuss how to migrate your workloads, let’s focus on the importance of knowing why you’re doing it. Understanding your main driver for a migration is crucial, not just because it will be the fundamental value piece in the business case for the project, but also because it will help you decide on the best migration approach for your unique needs. At this point, it’s possible to talk about known migration use cases or patterns — but to do so, it is essential that you understand your workload landscape. And because your application landscape most likely has more than one pattern to analyze, seeking out an expert opinion is a good first step.

For a consistent and reliable approach, here are some things to consider as part of your overall workload migration project.

Know your workloads

It’s likely that your application portfolio isn’t fully documented — at least, not to the level you need it to be to make informed decisions. Building on inaccurate data in the beginning can have disastrous results later on, so it’s important to prepare before you begin. If the appropriate information is not there, create it. Use discovery processes — preferably those that can build an information repository and keep it updated and consistent over time — as things will change during the migration process and you’ll often need to go back to the source to adjust and optimize decisions.

Plan, plan, plan

No real surprise here, I hope. The data source that the discovery processes build will be your best ally here, and the plan must be tied to that source in a way that can be adjusted if something changes. This is where the initial driver will have a significant role, providing additional pattern-based experience that can reduce risk and provide insights on what the end result might look like. For example, if your main driver is an application modernization initiative and you’re building new applications or components in “cloud native” mode, you’ll most likely be using a Platform as a Service (PaaS) cloud such as Kubernetes or ICp. This will give you great abstraction from the infrastructure needs, but data move will need special focus. Other common patterns are capacity burst (quick expansion), cloud-based high availability and disaster recovery. In such scenarios, you’ll be focused on stability to prevent disruption in application behavior, because code changes often aren’t included in the cost case.

Execute accordingly

As your plan takes shape, your next hurdle is defining the mechanism for performing the actual migration. Keep in mind that this is usually an iterative process, with logical steps and rehearsals, and the migration unit planning will change before anything is physically moved. After that, there’s acceptance testing, application validation and eventually source cutoff to complete the move. The need for specific tooling will be significant if the level of transformation from source to target is high, and again, understanding the driver for moving is key. Final tool selection must be fit for purpose and will be different depending on the type of move.

All transformations will come with some risk and cost. Very high transformation needs will add complexity and risk, so the end benefits must be clear. It is usually better to make lots of smaller moves at a time and to select the best approach from the beginning, even before the assessment phase starts. The high-level strategy here is strong attention to detail at each individual step, while keeping your over-arching goals in mind. Migrating your workloads will only make sense if there is still value at the end of the road. Start your focused brainstorming with strategy specialists or check the IBM Cloud Garage. Ready to talk to an IBM expert? Schedule a consultation here.

Follow me on Twitter for updates on this topic.

About The Author

Pedro Soares

Executive Architect, IBM

Pedro Soares is an Executive Architect working for IBM Global Technology Services. He's been creating IT solutions for more than 20 years, and mostly for IBM. Started as a Systems Engineer on Operating Systems and then moved to a more Network oriented perspective, then IT Systems Management, a bit of Security, and for the last... Read more