Building a Blueprint, the 3 approaches to every migration
By Aaron Cox
The methods of migrating applications and infrastructure have been in a state of evolution over the last fifteen (plus) years. Methods that were considered best practices have been outpaced by advances in technology, commoditization of infrastructure, and an expanding focus on the application layer and the needs of the business. While at the same time most IT organizations must live in the world of yesterday and the world of tomorrow to effectively manage any enterprise scale migration. Any well run migration program typically follows a process of discovering the infrastructure, applications, and services utilized in the environment (see Matt Brown's article series on discovery methods and best practices). Followed by building an approach and strategy to the migration (we call this a Blueprint) typically including the selection of methods, migration groups, and migration execution tools. Then, using the Blueprint to build and test actionable execution plans, leading to the execution phase of the project, and finally transitioning to an operational state. Building a structured Blueprint for your migration helps to set clear direction, govern the remaining phases, and set in place a structured approach to the planning and execution of your migration.
What's in a Blueprint?
When engaging in an enterprise scale migration or transformation one of the key aspects will be determining your migration approach or guiding principles as a first step to building a successful Blueprint for your migration. There are 3 key focus areas for you to consider in selecting the right approach to your migration:
One of these elements will typically govern a defined migration approach becoming the central element of that method. As the approach is defined, migration methods and tools can be selected to operate inside of each approach. Most organizations will need to utilize one or more approach to satisfy the varying targets of Co-location, SaaS, and Private or Public cloud or may need to include awareness of an additional element (consideration of potential impacts).
The three approaches
For over a decade Data Center Relocation or Infrastructure Centric Migrations were the key to the era of infrastructure relocation, for years infrastructure was at the center of any migration project, it was the seed of the "two chucks and a truck" thinking. Expensive, complicated, and restrictive infrastructure were the lynchpins that drove the approach to any relocation. A critical storage device with extensive dependencies or a big iron unix system may define how and when the rest of the applications and infrastructure in your environment were migrated, usually with minimal or no awareness of the direct business impact. These migrations or relocations were Infrastructure-Centric and sometimes business aware (considering potential business impact). Highly dependent on a handful of engineers, a few physical movers, and hopefully a well maintained and reliable truck. With each relocation event the business would hold their breath, take highly interruptive outage(s), and hope for business as usual on Monday morning after a weekend of little to no availability of critical technology services. This always led to a negative financial impact to any company, regardless of the success of the relocation.
As infrastructure became increasingly commoditized and virtualization became pervasive, migrations although still Infrastructure Centric also became Application and Business Aware. Seed infrastructure that would allow for the migration of a virtual host and data to be logically migrated rather than physically relocated to a new target data center adjusted the perspective. Although the separation of key infrastructure was still at the center of the migration the ability to separate workloads and applications from existing hardware now required a view into dependencies of applications and business activities that could be affected by their separation to a new data center. Application mapping and business context collection now became a key planning factor in any migration.
Continued evolution in the market, stronger virtualization tools, continued commoditization, extensive transition from unix to linux in the enterprise, and expanded options for application hosting services began to drive another shift in migration focus to Application Centric and Infrastructure Aware migrations. An application centric migration focuses directly on the requirements and dependencies of the application and unhinges most decisions and activities away from the infrastructure, with exception to situations where infrastructure is prioritized due to upgrade or compliance requirements to support the business or technology needs of the application. This migration method is very common among transformation projects and takes into consideration the need for little to no business interruption. As zero downtime environments have become more pervasive with critical services, this method outlined the early stages of migrations with no downtime or business process interruption.
As we start to see more and more migrations to the cloud we see two common themes among the methods used, Application Centric and Service Aware, or Service Centric and Application Aware dominate the approach of most successful projects. Cloud migration and transformation should first and foremost be focused on the application or service affected by the business, in addition to reducing business impact or risk. The window of opportunity to bring down production services has nearly evaporated, therefore establishing critical environments and thoroughly testing them in the cloud prior to production is critical. Application Centric cloud migrations tend to adhere to an agile approach with a focus on the software development cycle. The migration itself will most often be phased through sub-production environments allowing for cloud enabled enhancements to be vetted and deployed. Complex critical applications will often require greater development time and testing. Applications of lower criticality and less complexity should be limited to minimal changes to allow for things like proof of concept, accelerated adoption, and enhanced capabilities over time, as you will find you will adapt differently to cloud as you spend more time evolving to the solutions and services available. This is also a methodology heavily advocated for by Amazon Web Services. The cloud allows increased capabilities for simulation and testing at scale. This ties in closely with the AWS Well Architected Framework which advocates frequent "Game Day" simulations and affordably setting up temporary environments to test in scale.
Application Centric migrations in various forms have been an important element to consolidations and transformations for several years. Service Centric migrations are a newer phenomenon, as organizations adopt hybrid solutions into their environment the extension of existing services or transition to new services is a critical element to overall success in your transformation. The shift from monoliths, to microservices, and now functions has adjusted the priority of capabilities like API services, messaging, queuing and workflow, etc. as a central priority to any cloud migration project. As you migrate applications to the cloud their ability to utilize common services with your applications hosted in other clouds, SaaS, or a colocation facility will need to be top of mind. Services such as Directory & Authentication, Shared Databases, Monitoring, Security, and access to Data Warehousing to name only a few will be required. You may need to determine to retire and replace certain services that cannot handle your new model. Although you may only migrate five applications to public cloud, will your API solutions support your entire model? Or will you need to migrate to a new service. These service centric migrations will increasingly become central to your overall cloud migration strategy just like understanding application dependencies and business context became critical to Application Centric migrations. As traditional data centers are carved up into several hosting strategies determining how to retire, replace, rearchitect and mesh the many complex services IT must provide to applications and business users will need to be a central function to any cloud migration or transformation.
Discerning the right approach for your migration is going to be crucial to your success. Moving beyond the infrastructure centric migration model will be necessary if you want to adopt cloud or hybrid solutions in scale. You may find that you are applying one or more of these approaches across tightly coupled affinity groups. Defining your migration approach is central to building a framework for the methods, tools, and goals of the project.