Migration to the cloud is just like a house move. The amount of preparation done before the move determines how smoothly the move goes. Similarly, there are many technical and non-technical actions that can be taken to make a move to the cloud successful and calm. Most actions (or decisions) will be cloud-agnostic and can be carried out at any time, but once a platform is chosen, it unlocks even more areas where preparations can be made in advance. In no particular importance or order, let’s look at some of these preparations.

Suitability

Some workloads may not be suitable for migration to the cloud. For example, compliance, performance, or latency requirements might force some workloads to stay on-premises. Even if a company adopts a “cloud-first” strategy, such workloads could force the change of model to a hybrid cloud. If not done initially, identification of such workloads should be carried out as soon as the decision on the platform is made so the design can cater for them right from the start.

Hybrid IT

Most cloud environments are a hybrid of private and public cloud platforms. Depending on the size of the organization, it’s common to arrange for multiple high-speed links from the on-premises environment to the chosen platform. However, those links are quite cumbersome to set up, as many different parties are involved, such as the provider, carrier, networking, and cloud teams. Availability of ports and bandwidth can also be a challenge. Suffice it to say that lead times for an end-to-end cloud migration process typically ranges from a few weeks to a few months. For that reason, it’s recommended to prioritize identifying if such link(s) will be required and to which data centers, and get the commissioning process started.

Migration Order

This is an interesting one as many answers exist and all of them are correct. It really depends on the organization and maturity level of the applications involved. For an organization where identical but isolated development environments exist, it’s generally preferred to migrate those first. However, you may find exceptions in cases where deployment pipelines are implemented. It’s important to keep stakeholders fully involved in this process, not only because they understand the application best and foresee potential issues, but also so they’re aware of the migration schedule and what constitute reliable tests before signing off.

Refactoring

Most organizations like to move their applications to the cloud and improve later. This is especially true if there’s a deadline and migration is imminent. It makes sense to divide the whole task into two clear and manageable phases, as long as the improvement part isn’t forgotten. That said, the thinking process on how to refactor existing applications post-migration can start now. There are some universal concepts for public cloud infrastructure like autoscaling, decoupling, statelessness, etc., but there will be some specific to the chosen cloud platform. Such thinking automatically forces the teams to consider potential issues that might occur and therefore provides enough time to mitigate them.

Processes

Operations and support teams are extremely important in the early days of migration, so they should be comfortable with all the processes and escalation paths if things don’t go as planned. However, it’s common to see organizations force rollouts as soon as initial testing is done (to meet deadlines) before those teams are ready. This can only cause chaos and result in a less-than-ideal migration journey for everyone involved. A way to ensure readiness is to do dry runs with a few select low-impact test environments, driven by the operations and support team solving deliberately created issues. The core migration team should be contactable but not involved at all. Migration should only take place once both teams are comfortable with all processes and the escalation paths are known to everyone.

Training

Importance of training cannot be emphasized enough, and it’s not just about technical training for the products involved. One often-forgotten exercise is to train staff outside the core application team, e.g., operations and support, about the applications being migrated. There can be many post-migration factors to consider that make it necessary to provide training on applications, such as application behavior changes, deployment mechanism changes, security profile, and data paths. Training on technologies involved can start as early as the platform decision. Application-specific training should occur as soon as it’s ready for migration but before the dry runs. Both combined will keep the teams in good stead when migration day comes.

Conclusion

Preparation is key for a significant task like cloud migration. With a bit of thought, many things can be identified that are not dependent on platform choice or the migration and can therefore be taken care of well in advance. A successful cloud migration sometimes depends on how many factors are involved. Reducing the number of tasks required can mean less stress for everyone. It pays to be prepared. As Benjamin Franklin put it:

“By failing to prepare, you are preparing to fail.”