How to Implement Workload Migration in Enterprise IT
The topic of workload migration isn’t a new one, but that doesn’t make it any less relevant. With or without public and private cloud scenarios, moving applications and other infrastructure components is complex and prone to risk. However, it’s also a task that can bring huge value when done right, and with the increasing adoption of cloud models, the need to migrate workloads isn’t going anywhere.
Before we look at how to get the job done, let’s focus on knowing why you’re doing it. Understanding the driving factor for a workload 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 approach. At this point, it’s possible to talk about known migration use cases or patterns. But to do so, you’ll have to understand your workload landscape.
When you’re feeling ready for a change, consider these steps to help you to plan your workload migration project.
Know Your Workloads
Chances are your application portfolio isn’t fully documented, at least not to the level you’d need it to be to make informed decisions. Building on the wrong data at the beginning can result in a few disasters later on, so it’s always better to prepare in advance. If the appropriate information isn’t there, create it.
Use discovery processes — preferably ones that can build an information repository and keep it updated and consistent over time — as things will change during the migration project, and you’ll often need to go back to the source to make adjustments and optimize decisions.
Plan, Plan, Plan
This recommendation isn’t really a surprise, I hope. The data source that the discovery processes build will be your best ally here, and the plan must be tied to it in a way that can be adjusted if something changes. This is where the initial driver will have a significant role, as it will provide additional pattern-based experience that can reduce risk and provide insight into 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 the cloud-native mode, you’ll most likely be using a platform-as-a-service cloud such as Bluemix. This can provide you with effective abstraction from the infrastructure needs, but the data migration will need special focus.
Other common patterns include capacity burst (quick expansion), cloud-based high availability and disaster recovery. In such scenarios, it’s important to keep everything very stable to prevent disruption in application behavior, as code changes often aren’t included in the cost case.
Execute Workload Migration
As your plan takes shape, you must define the mechanism for performing the actual migration. Keep in mind that this is usually an iterative process, with logical steps and rehearsals. Based on those, 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, the driver behind the project is key. Final tool selection must be fit for purpose and will differ depending on the type of migration.
Very high transformation needs will add complexity and risk, so the end benefits must be clear. It’s usually better to move small lots at a time and select the best approach from the beginning, even before the assessment phase starts. All transformation will have some risk and costs. Migrating your workloads will only make sense if there is still value at the end of the road.
IBM Cloud Brokerage can help you plan a migration and understand all the costs from end to end. There’s even a component called Application Screener available to support you through the decision process.
For more on this process, follow me on Twitter @pgspsoares.