Having the right cloud migration strategy can be a significant differentiating factor between a successful migration vs. failure of investments. It includes identifying the needs of specific applications, and then defining how to move them to the cloud.
When migrating your applications to the cloud, you need to ensure the integrity of the system across the three layers: the application itself, underlying database, and the host operating system. Based on complexity and requirements, you will need to make necessary changes to the application and/or the database.
Rehosting is a kind of “lift and shift” strategy, that means migrating the application as-is, along with its environment (Database and OS), onto a new infrastructure platform (Hardware Infrastructure as a Service or HIaaS). This may require changes to be made in the infrastructure level configurations, for which several automated and manual tools can be used. Since there are no major changes required in the application architecture, it is often considered as a faster way of migration. Organizations often use this method with small and standalone applications.
The application is re-architected using the cloud-native features. Developers may reuse the language, or use cloud-native features, frameworks, or containers (Platform-as-a-Service or PaaS). This is often expensive, but usually, it is chosen when you opt to address new business requirements by adding new features or want to enhance the scalability and performance of the application.
Revise, or re-platform is about modifications to the existing code, often done to uplift the legacy applications, as well as rehosting or refactoring the application to the cloud (HIaaS or PaaS). Examples may be moving monolithic Python-based application to Google App Engine or migrating the on-premise Oracle database to Amazon RDS. It may often require to break the business logic into smaller applications or modules. This “lift-thinker-and-shift” strategy is time-consuming and expensive as well. However, this reduces the overall management and operations costs (like licensing) moving forward.
You may completely rebuild the application on a PaaS infrastructure, by dropping the existing code and architecture. This provides opportunities to write applications by leveraging the native-cloud functionalities, or the other innovative features offered by the cloud service providers. For example, you can leverage the new technologies like DynamoDB and AWS Lambda to rebuild completely serverless applications, for which you need not manage the servers by yourself. But this leads to lock-in with the cloud vendor, as you will have minimal options in case the cloud vendor chooses to change the pricing or the privacy policies.
You may also want to consider replacing an existing application and moving to a new cloud-based commercial solution. For example, dropping an in-house developed product and adopting a Software-as-a-Service (SaaS)-based solution may often seem to be the most viable option. This is often based on simple cost-based calculations, including licensing costs, operational costs, and cost for upgrades and maintenance.
Identify and fill the skill gaps
Many organizations have an established IT department, with excellent knowledge and know-how of their existing environment, but when it comes to cloud, those skills may often seem like a square peg in a round hole. Developing and running applications for the cloud requires a new set of fundamentals for performance optimization, scaling up (or rather scaling out), and managing security and compliance. For cloud environments, QA related methodologies are also completely revamped, with DevOps and DevOpsSec riding in the front seat. Your teams need to get past the initial learning curve to understand and adapt to the new world of design and operational principles.
Keep expenses under control
The success or failure of cloud migration may have a direct impact on your Total Cost of Ownership (TCO) for cloud adoption. Besides the visible cost factors like processing power, data storage, additional tools, and security, you must also consider several additional factors. For instance, during the entire duration of migration, you will be paying for both your old infrastructure licenses, as well as the new one. Also, the productivity of the staff (IT as well as non-IT) is also impacted during the transition period (due to learning curves, system downtimes, etc.), and they might not perform their daily tasks efficiently. So if the transition period extends for a significant duration, overhead expenses may cancel out the entire value of the cloud.
Analyze the security and performance risks
Data hosted in the cloud is often considered at risk of exposure, leading to threats of data breaches, hijacking, or even data loss. With the cloud, you usually have limited options for customization (as compared to on-premise data). So you need to ensure that IT professionals and security auditors are involved in the decision making, and they are aware of all the possible security keyholes when selecting the cloud vendor and services.
Besides the basic security layers (like data encryption, two-factor authentication, etc.), there must be deep scans of the chosen services to identify the kind of vulnerabilities and level of risk. While making a choice between open source software vs. commercial applications, all risks and rewards need to be considered.
Monitor anything and everything about your cloud
To summarize, here are some best practices that can help reduce the risks and improve efficiency during cloud migration:
While choosing a cloud vendor, go with the one that optimally fits your budget, while meeting all the desired requirements. The optimal cloud platform and supporting services for your organization need not be the costliest one available in the market. Just make sure they offer or support the essential capabilities, like monitoring of resource usage, integration with third party security services, etc.
Always go with a phased approach, and migrate the low-risk applications first (as a proof of concept) to test the waters before jumping in. Also, prioritize the important ones first, and the optional ones later.
Start planning for security from the beginning, and include the DecSecOps in a loop right from the initial phases. Also, try to keep other employees in the loop, to avoid any shocks of a sudden overnight change.
When dealing with large-sized applications, try to go for a hybrid approach. Migrate some specific elements to the cloud, and keep the critical data and modules on-premise, to get better control and flexibility at the same time.
Go with the old saying, “Hope for the best, but prepare for the worst”. Always have a backup plan. Expect that mistakes will happen, and have a plan B to keep moving with those mistakes.