Once you have decided which services you want to shift over to the cloud, here are some key things to consider as part of your cloud migration strategy.
Long-term vision: In addition to avoiding temptation with regards to cloud features, having a migration plan and goals for the long-term also provides clarity on the lifespan of your applications. Before moving everything over to the cloud, it’s worth considering whether you are likely to continue using these services.
Compliance: Cloud compatibility, as mentioned before, is of utmost importance in a lift and shift migration approach. This includes compliance requirements, which your applications must adhere to during migration and after it.
API tools: Similarly, the cloud environment should be such that it does not pose any issues for your existing API tools. There is no room for re-architecting in a simple lift and shift, so your APIs must be accounted for.
New services: Another aspect of thinking long-term is planning for the new services you build after rehosting your current services. The path for those services may look different than what you have already built. If they are to go on the cloud, will they be exported to it eventually or hosted there from the beginning? They will have to be built in a cloud-ready way.
Templatization and standardization: Creating templates and establishing standards for microservices can be especially useful to facilitate the process of creating new services. Your developers need not worry about whether they are on the right path. After deciding to build a service for the cloud, they can simply choose the appropriate template and start redesigning their workflow around it to have a cloud-compatible service ready. Developers already have their hands full, and these practices make it easy to both build new services as well as maintain existing ones.
Governance: Keeping track of all the different aspects of your strategy may seem like a mammoth task, but it is essential to ensure a smooth migration to the cloud. It is beneficial not only for leadership but also for developers to be in the know about their current position and understand what they must do to meet their goals. Today, there are a number of programmatic mechanisms and tools available to make governance easier. A few examples of questions that such automation can take care of are:
- If you are currently maintaining an on-premises Kubernetes environment, are there new annotations you need to add to your Kubernetes clusters or Kubernetes deployments for them to work on the cloud?
- What are the specific security policies that your development and security teams should enable? How can you take account of that?
Visibility: Relatedly, make sure you are reporting on the process. Both leadership and developers need visibility on the migration strategy to be on the same page. Leadership is also in charge of planning the product and the OKRs, so they must be kept in the loop. If they are unaware of the current status of the migration process and the projected path forward, they will be making uninformed decisions that could harm or be at odds with what is going on.
How Scorecards can help
Cortex’s Scorecards allow you to define and enforce standards across your teams with ease. Informing your team about these uniform expectations helps them prepare for the lift and shift process. Using automation to track these standards and your team’s progress towards the goals gives you an accurate idea of your current standing.
Without automated tracking, it is difficult to identify how much of your existing infrastructure is ready to be migrated to the cloud. When everyone in your team has this knowledge, the process of lifting and shifting your software to the cloud becomes much easier.