As IT technologies take an ever-greater role in managing business processes, there comes a time when applications, data, and processes require migration to satisfy the needs of the organization. Migrations can range in size from very small to massive, and in complexity from simple and easy, to terrifying. In this blog, I will provide a brief overview of the migration process.
There is a saying that “a digital transformation starts by migrating to the cloud”. While it is completely feasible for an organization to fully manage their IT needs on-premises, it is important to consider what your organizations core competencies are. In two previous blogs, I talk about digital transformations as a process of mapping the available tools to the competencies of the organization and leveraging new technologies to differentiate from competitors. Considering the scale and scope of cloud providers like Microsoft Azure and Amazon Web Services, it is not logical for most organizations to rely purely on internal resources for their technology needs. Hence for many organizations, there will come a time when migrating resources is on the table. Migration typically happens in three stages: Assessment, Migration, and Optimization.
During the assessment phase, time is taken to determine what can be migrated and its current configuration, what will be impacted, and to map dependencies. From this preliminary work a migration plan is developed, highlighting findings, and laying out a roadmap for the migration. Important questions to ask are: what applications and infrastructure am I currently running?; of these applications, which should be migrated, modernized, retired, replaced, or maintained on-premises?; what are the risks associated with a migration, and how long will it take?; what will be the return on my investment for migration, based on my current running costs, my post-migration running costs, and the cost of migration itself?; and what additional benefits will cloud migration bring to my organization? Ideally it is a best practice to avoid “big bang events”, prioritizing simpler, non-critical workloads for early migration. Areas of concern are regulatory compliance, security, service availability, functionality, compatibility, performance, cost, and cost flexibility.
During the migration, some early steps include the setup of subscriptions, security policies, general governance, and verifying connectivity with newly procured services. There are five common migration approaches: Retire, Replace, Rehost, Rearchitect, and Retain. With Retire, the application is at end of life and it is easier to retire, than migrate the application. Replace is very common where business workloads have equivalent offerings, especially now with a rich selection of Software as a Service (SaaS) products to choose from. Rehost or (also known as lift and shift) is where an application is migrated to a set of virtual machines as part of an Infrastructure as a Service (IaaS) offering from a cloud provider. Rearchitect requires converting the application to run as a Platform as a Service (PaaS), which is significantly more costly than rehosting, but can be advantageous as the upgraded application will likely have lower on-going management complexity and cost compared to rehosting. Applications are commonly rehosted, then updated to take advantage of PaaS. Lastly, Retain refers to retaining on-premises for when continuing in place is the only realistic option. This option is common for applications with regulatory or geographic requirements that cannot be met by current cloud offerings.
Once migration has been completed, the focus shifts to optimization. At this stage, the cloud spending is being tracked and time is spent formulating strategies for savings. If an IaaS migration was performed, an evaluation of the migrated applications for opportunities to right size provisioned virtual machines is done. The next step would be the implementation of automation to resize or stop services based on utilizations, and the identification of applications that could benefit from optimizations like moving from IaaS to PaaS.
In many ways, the migration process is never ending, as elements of the technology stack are placed into focus and assessed to discover opportunities for improvement. One could think of migrations not as a singular event, but a continuous practice that is developed over time with the core goal being the migration from a big bang change every few years to a continuous focus on refactoring in small iterations to keep the organization technology relevant.