Migrating business systems into an ‘all-in’ cloud environment is one of the most cost-efficient solutions for scaling business operations. The costs associated with the purchase, deployment, operation and maintenance of additional physical servers are replaced with the lower costs of purchasing server capacities from the cloud supplier. Cloud processing and storage capacities can be changed in minutes compared with equivalent physical changes to computing systems that can take weeks.
By opting for infrastructure migration onto a cloud solution offers businesses the ability to innovate, develop, test and deploy their conceptual software designs on the fly at a fraction of the costs associated with building, deploying and maintaining the physical infrastructure required to enable this process. This digital evolution has driven DevOps adoption and has made the issues related to managing legacy systems a thing of the past.
However, cloud migration is not a simple process. The challenges of this process bring risks which need careful management, but when completed, cloud migration brings significant rewards that more than balance out the effort required.
Start with a Strategy
Migration to the cloud can be a complex from building and deploying the new cloud environment, adapting existing workstreams and practices through to migrating data and processes. Successful migration requires a clear strategy design to satisfy business objectives, a defined scope for the new cloud environment and having effective operating and security practices in place that deliver the required results.
Any migration process should start with a clear business objective that drives the migration strategy. Without a clear goal, it isn’t easy to know what the endpoint of the migration plan should be. There are so many choices available that it is easy for analysis paralysis to set in if there is not a clear strategy that everyone is following. Clouds come in public, private and hybrid variants while solutions can be infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). It’s easy to become overwhelmed or make the wrong choice and end up paying to migrate to a cloud solution that doesn’t deliver what you need or for costs to spiral out of control and negating any savings.
Write a Migration Plan
Have a clear and comprehensive plan that breaks the migration down into verifiable and straightforward steps that all the stakeholders can review and agree. The program needs to deliver what is required and provide assurance that once all the steps are complete, then the migration is demonstrably successful, and the legacy systems can be safely switched off.
When migrating from physical infrastructure into a cloud environment, both environments will be running in parallel for a transitional period. So, you will be paying the operating and maintenance costs both at the same time. This short terms duplication of costs is necessary, so the trick is to make this period as brief as possible but make sure you don’t switch off the physical infrastructure before you’re confident that the cloud environment is fully up and running and everything (data, applications, processes) that needed to be migrated have actually been migrated. You do not want to switch off the physical servers and send them off for recycling only to find that some essential data that they held was forgotten or got corrupted during the transference process and nobody spotted the problem.
Think About What to Migrate
Only migrate the data and applications that require migration. Blindingly obvious, but it is not uncommon for organizations to hang onto legacy applications or historic data for fear that they may need them in the future. Assess the data and applications on the old infrastructure and identify data that is never accessed and outdated applications.
For every application, identify who owns the process, who the users are, what business process it fulfills, how it integrates with other applications and its criticality to the business. Then assess the priority of this application compared with the others for migration, this will depend on how it fits into the overall flow of the business processes and its dependence on other applications. Then assess how the cloud migration will impact the application in terms of changes to how it works, its dependencies and its access. As part of the migration, ensure the application owners approve the impacts of migration, and all users receive any required training to adjust to any changes.
The migration does not have to be completed in one hit. A staged migration, where the physical infrastructure and cloud infrastructure run together, maybe the best option if there are applications on the legacy systems that require significant changes before they can be migrated. It may well be the best option to maintain these legacy systems until either the applications are rewritten or replaced with cloud-ready alternatives.
These simpler migrations can also deliver risk mitigation for the complex migrations by uncovering and resolving any basic problems around the configuration of the cloud environment and adaption of the users to working in the new environment.
Migrate or Replace?
There is also often a mindset that an organization should hang on the same tried and tested applications that it uses on its existing infrastructure and that migration should appear invisible to the user base. A better approach is to consider the migration event as an opportunity to see what other options are available, and there may well be a cloud-ready application that is better, easier to use, and even cheaper than the existing legacy application. Evolution and revolution do not have to be mutually exclusive, embracing both in the infrastructure migration can at the end of the day deliver the best results.
There is quite often an inverse relationship between the ease of migration and the financial advantages, those applications that are quick and simple to migrate are usually not the ones that deliver the best benefits from migration. However, the quick wins they bring can often provide the momentum for migrating the complex applications that require significant effort to adapt. These factors should feed into the migration plan when determining the ordering and prioritization of the migration steps.
When it comes to DevOps, DevOps as a Service (DaaS) is the simplest method for ‘all-in’ migration of development processes into the cloud. Such a service provides the tools necessary for the continuous integration/continuous delivery (CI/CD) pipeline as a managed service. This option is particularly attractive if the DevOps migration requires extensive changes to existing development tools to allow their migration into a cloud environment.
Use Your In-house Experts
Migration into the cloud environment is an opportunity for an organization to make their existing business processes more agile and innovative. Careful planning against a clear objective using the available in-house expertise will ensure the cloud migration is a success.
Security and availability should be critical factors to consider when choosing which cloud environment would be best. This is where organizations with a DevOps capability come into their own. DevOps operations naturally embed security measures, so employing the DevOps approach for the migration can deliver results. Bringing DevOps engineers into the migration process to guide, review and critique decisions can help avoid costly errors in the decision processes.
Don’t Forget the Users
One of the common pitfalls for cloud migration is the failure to train employees for working in the new environment. Workers are naturally resistant to change so the organization needs to ensure that everyone understands the reasons for making the changes, how it will impact them, how they should use the new facilities and most significantly what benefits it will deliver to them. The migration plan should include provisions for training, resolving issues and users getting back up to speed.
by Stephen M.