Today, almost every organization has some workloads in the cloud. According to Forbes, by 2020, 83% of enterprise workloads will live in the cloud. However, for many people, their cloud experience is limited to SaaS applications and environments managed by application vendors. For many companies, migrating to the cloud can be an arduous and necessary next step. In this article, I will share some insights from my experience with customers migrating to the cloud. Today, almost every organization has some workloads in the cloud. According to Forbes, by 2020, 83% of enterprise workloads will live in the cloud. However, for many people, their cloud experience is limited to SaaS applications and environments managed by application vendors. For many companies, migrating to the cloud can be an arduous and necessary next step. In this article, I will share some insights from my experience with customers who are migrating to the cloud.
1. Tons of planning time
Data execution and migration is the easy part. However, all successful cloud migrations are the result of hours of planning. There were few failures, and I found that when the organization first moved workloads to the cloud, I was surprised by the number of plans is made. If this is your first time transferring workloads to the cloud, I strongly recommend that you contact a qualified migration service provider who can assess your cloud readiness and help you plan appropriately. Even if you have played an active role in the migration, a knowledgeable guide can save you a lot of trouble.
2. Accountability in each state
There is nothing worse than the accusation when there is a problem with cloud migration. Especially when the problem is caused by a misunderstanding, it can be avoided by assigning ownership to specific tasks and deliverables during the planning process. During the planning phase with the customer, we will break down the migration into hourly, task-by-task responsibilities. Before starting, this file must be approved by the project team members. Then, once the migration begins, everyone knows who is doing what and when. But most importantly, accountability starts with your executive sponsor. If they do not provide appropriate support to ensure that the project proceeds as planned, it will be difficult to carry out the responsibility system for daily tasks.
3. Discussion about legacy applications
After discussing the challenges with the customer, we decided to suspend their migration project, and they spent some time refactoring their cloud-specific applications or replacing them with newer solutions that can be used for cloud computing. Replacing the application will increase the initial migration time (for example, choosing a new solution and migrating data takes time), but because the new application is cloud-native, it can save back-end time. Because these applications are designed for the cloud, they perform better in that environment and have built-in protection against many of the most common security threats. In addition, patches for newly discovered cloud-related security vulnerabilities may not be obtained from your old application vendor. The refactored application is not necessarily cloud-native, but at least it may be more cloud-friendly.
4. Migration
There is almost no such thing as a standalone application. For example, your ERP system may be feeding information into any number of point solutions. In turn, they may feed the information back to the ERP system. Moving workloads to the cloud without considering these dependencies is a source of disaster. In the planning stage, we discussed the dependencies between applications with the business leaders and the IT department, but we also used a tool to check dependencies. Surprisingly, we often find dependencies that are undocumented or overlooked by everyone. We then group these applications into the migration phase so that nothing will be broken when the application group is moved to the cloud. Usually, we start with the least amount of work in mission-critical workloads (for example, development and test environments) in order to discover the most unexpected obstacles caused by workloads with less downtime.
5. Several downtime issues
When organizations move to the cloud, one of the most common questions we encounter is “How much downtime should I expect?” There will always be some, but the answer depends on the complexity of the workload and the chosen migration method. When migrating workloads, we often use the same technologies as those used in disaster recovery solutions. We choose which method to use based on factors such as the size and complexity of the workload. But it is important that we take into account the recovery time objective (RTO) of each workload in the organization. Thinking in this way has another additional benefit. Disaster recovery is almost always part of the migration discussion and is often part of the final migration plan.
6. Dry run
Before migrating workloads, we use a copy of the data in the isolated network for migration. This allows us to discover any unforeseen problems and verify our hypotheses. A truly memorable example is that a European customer wanted to transfer workloads to one of our New York data centers. During the planning and testing process, it turned out that their bandwidth and connectivity were not what we expected. If we start the migration, it will take several months, so we quickly returned to the drawing board and proposed a revised plan.