This post discusses moving applications to the public cloud in bulk, where dozens or hundreds of applications are in view. After reviewing the challenges and opportunities inherent in bulk migration, an efficient factory-based approach is outlined. Lastly, Neudesic’s bulk migration service for the Windows Azure platform is described, Azure Migration Factory. Here's what we'll cover:
The Nature of Cloud Migrations
Challenges and Opportunities Inherent in Bulk Migrations
A Factory Model Approach to Cloud Migration
Neudesic’s Azure Migration Factory
A Factory Model Approach to Cloud Migration
Neudesic’s Azure Migration Factory
NOTE: Everything described here is equally applicable to both Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) cloud computing. The term “application” refers to the IT assets that make up a software solution. When targeting PaaS, “application” means one or more sets of software code, configuration, and data that work together. When targeting IaaS, “application” means one or more virtual machines containing software, configuration, and data that work together. In either case, the “software” could refer to existing custom-developed code and/or a commercial product.
The Nature of Cloud Migrations
Before we contrast individual migrations with bulk migrations, let’s briefly review the common ground intrinsic to any production cloud migration. There are application-level activities to perform as well as organizational readiness activities.
Application Activities: Assessment, Planning, Technical Work, Support
Whether one is migrating a single application to the cloud or a dozen, certain things always need to be done. An assessment provides the business and technical analysis needed to make a sound go/no-go decision on moving to the cloud. A migration plan identifies the activities and sequence needed for an orderly and non-disruptive migration. The migration itself is technical work that entails a variety of IT, development, and QA tasks. The people, processes, and systems responsible for monitoring and management need to support the application in its new setting.
Organizational Activities: Strategy, Compliance, Integration, Adaptation
There are also organizational activities that must accompany cloud migration. These include: defining a cloud strategy and setting policies and guidelines on appropriate uses; ensuring buy-in across the company from stakeholder departments who must be satisfied about security, risk management, compliance, management, and disaster recovery; integration projects to ensure cloud-hosted assets can interoperate with internal systems; and adaptation of existing application lifecycle processes (deployment, management) to accommodate cloud-hosted applications.
Typically these organizational activities are trigged by the first production migration to the cloud, and refined over time as experience and comfort level with the cloud increases. In some ways, the first migration is the most expensive migration.
Challenges & Opportunities Inherent in Bulk Migrations
Bulk migrations bring both challenges and opportunities:
A bulk migration is a serious commitment. Whereas an individual application migration might be sponsored by a single department, a bulk migration implies broad buy-in by departments across the organization on a cloud strategy and supporting operational changes. A bulk migration isn’t likely to happen until there is a strong degree of confidence and consensus by stakeholder departments on cloud vision, platform/provider, and integration partner. A proof-of-concept often precedes a bulk migration to validate the platform and partners.
A bulk migration is challenging to estimate properly. In a single-application migration the candidate application can be deeply studied. In a bulk migration you rarely have that luxury and need to make high-level estimates based more on tribal knowledge about applications and less on direct examination of code.
A bulk migration represents a sizeable effort, one that needs to be carefully managed. Surprises can surface in the midst of any application migration; when performing a large number of migrations in parallel a mounting number of surprises could quickly put the budget and timeline at risk if not managed well.
A bulk migration may encounter product obstacles. Products your software is dependent on may or may not be compatible with the cloud. Even without technical hurdles, you may be unable to use some products in the cloud for licensing and support reasons. In these cases, development work may be needed to replace some parts of your technology platform with cloud-friendlier equivalents. This is not always bad news, as it may do away with licensing costs.
A bulk migration requires organizational cooperation. Even if a migration is being performed by an integration partner, the customer needs to participate. The migration teams will need a supply line by which they can receive, in a timely fashion, application assets (such as source code and database scripts), answers to technical questions (such as environmental information), and assistance integrating to internal systems. If the customer can’t serve in this supporting role and keep pace with the migration teams, the migration effort will be held back. The organization also needs to provide user acceptance testing to sign off on migrated applications.
Although a bulk migration does bring its challenges, it also brings opportunities. There are financial and technical reasons to favor a bulk migration over a one-app-at-a-time approach.
A bulk migration can reduce average application migration time by taking advantage of repeatable tasks, especially when there are multiple applications that share the same architecture and technology platform. Repeat work is an opportunity to increase velocity.
A bulk migration can save money. Operational costs in the cloud can be reduced by consolidating applications and data in shared cloud resources where it makes sense rather than provisioning each application individually. Analysis, development, IT, and QA activities are more efficient and less costly across a series of applications as opposed to ramping up for applications individually. “Cookie cutter work” can be codified as step-by-step procedures and handled by less expensive resources. Licensing costs could be reduced by moving to application or database platforms that don’t require licensing (for example, from IBM WebSphere in the enterprise to Tomcat in the cloud).
A bulk migration provides better insights. When applications are migrated individually, decisions about strategy and adapting existing processes and systems are based on a partial view that gets refined over time. In a bulk migration, there’s a large body of evidence to consider all at once: analysis, financial modeling, strategy, and organizational impact are all based on a fuller picture. This makes for better initial decisions.
A bulk migration is an opportunity for uniformity. As applications are migrated, they can also be retrofitted. For example, all web sites being migrated could be retrofitted to use a common analytics system. If instrumented for monitoring, applications can be configured for auto-scaling, where deployment size is dynamically altered to match changes in load.
A Factory Model Approach to Bulk Cloud Migration
Cloud assessment and migration of multiple applications can be handled well using a factory approach. The majority of personnel are allocated to migration teams that make up the factory. QA teams validate the correctness of what the factory produces. An Advance Team analyzes applications first and keeps the factory equipped for the types of work it needs to do. An Exceptions Team supports factory members, helping with problems and sometimes taking over difficult migrations directly.
Factory Model Cloud Migration
Let’s review the teams that make up this model, their responsibilities, and how they interact.
The “factory” is one or more technical teams who are able to rapidly perform migration tasks. The high velocity is due to repeatable work of the same nature (“cookie cutter” jobs), steered by concrete guidance. This type of work favors a heavy offshore component to keep costs down. Migration tasks could be complete migrations (e.g. “migrate a PHP web site”) or assembly-line style partial tasks (e.g. “update this application to use a cloud-based caching service“).
Like a physical factory, one or more supervisors are needed to oversee how things are going and ensure the factory is humming along as it should be. Problems that stop the assembly line need to be dealt with swiftly.
The Advance Team: Equips the Factory for New Kinds of Work
The factory only knows how to manufacture what is has been configured to make. Someone needs to teach it new tricks to handle new kinds of applications or variations on past patterns. The Advance Team consists of architects and technology subject matter experts who analyze applications before they are handed off to the factory, categorizing them as previously-encountered types or something new. New kinds of applications are studied, and updated migration guidance for the factory is created. If the new tasks are significantly novel, factory members may need to be formally trained on the new pattern. The advance team also sizes the migration effort required.
The Advance Team receives feedback from the Exceptions Team on how migration work is going. This feedback loop drives continual improvements into the guidance based on experiences using it.
The factory model is all well and good, but occasional surprises and difficulties are inevitable. The Exceptions Team supports the migration teams and helps them through problems with support. If necessary, the Exceptions Team will take over a difficult migration directly. Unusual, one-of-a-kind, or highly complex migrations will be handled by the Exceptions Team.
The quality assurance teams test migrations produced by the factory to confirm quality requirements are met and the migrated apps have fidelity to the original apps. Often this will consist of a cursory check (performed by the integration partner) followed by user acceptance testing (performed by the owner organization). In the case of simple web site migrations, the first-level quality check might consist of side-by-side comparisons of the original and migrated web site, walking through the site by following its navigation and ensuring pages display and interact identically.
How We Do It: Neudesic’s Azure Migration Factory
Azure Migration Factory is Neudesic’s bulk cloud migration service offering for Microsoft’s Windows Azure cloud computing platform. It implements the factory model approach as described earlier and supports both Platform-as-a-Service and Infrastructure-as-a-Service migration.
In Neudesic’s adoption of the process, a project management office is staffed by Neudesic and client managers; migration teams are primarily staffed with offshore resources; the advance team is staffed with architects, Windows Azure experts, and technology subject matter experts; and the QA/UAT teams are staffed by a mix of Neudesic and customer quality engineers.
Azure Migration Factory
Proactive, ongoing management is a cornerstone of Azure Migration Factory. A project management office consisting of Neudesic and client personnel oversee the ongoing migration effort. There are regular meetings to review how the teams are doing against projections; and to determine whether any changes are needed to the size or composition of teams. Work typically proceeds in waves, where forecasts of upcoming work are used to ramp up teams or decommission teams smoothly as the workload changes.
The Advance Team consists of architects, Windows Azure experts, and subject matter experts on application technologies such as .NET, Java, or PHP.
During the assessment process, the advance team evaluates migration candidates and performs a sizing to small, medium, or large which equates to a 1-, 2-, or 4-week migration effort. Early in the process, customers are provided with sizing guidelines so that a preliminary scoping of the effort can be roughed out; some of these findings may be revised once the applications are analyzed directly by the advance team.
Applications are categorized using an application patterns catalog for which step-by-step migration guidance has been prepared. The catalog is updated when new application architectures or technology platforms are encountered, or when a variation of an existing pattern needs to be accounted for. At the customer’s option, the assessment process can run in parallel and slightly ahead of the migration effort; alternatively, all apps can be assessed before the migration effort gets underway.
Migration teams are made up of “pods” of consultants with a set size, primarily consisting of offshore consultants. Pods can vary in their skill set and platform knowledge, for example a .NET pod or a PHP pod. The customer can balance migration speed vs. spend rate through the number of pods approved to work in parallel.
Neudesic is able to migrate many kinds of applications to the cloud by leveraging its technology practices, which include Business Intelligence, Connected Systems, CRM/Dynamics, Custom Application Development, Mobility, Portals & Collaboration.
The Exceptions Team consists of experienced consultants who keep the migration effort on track by quickly unblocking migration teams when they run into problems. They do this through support and, if necessary taking over migration of especially difficult or unusual migrations.
Neudesic Quality Assurance teams verify migration success, reporting issues back to the appropriate migration team if results do not match expected appearance and behavior. Customer User Acceptance Teams then confirm whether migrated applications meet their expectations.
The breadth of the Windows Azure platform allows migration to target the most appropriate mode for an application: Platform-as-a-Service, Infrastructure-as-a-Service, or managed web sites. Neudesic’s Windows Azure experts are experienced across the entire platform and include Microsoft-recognized MVPs.
Neudesic has unique intellectual property in the form of libraries and tools that accelerate the analysis and migration of applications to Windows Azure. This includes tools that partially automated the analysis of applications.
Customers who migrate to the cloud in bulk are often also in need of a partner for support and management. Neudesic offers support and management services for cloud applications through the Neudesic Managed Services group.
Neudesic provides Windows Azure training services for customers who wish to bring cloud skills in-house to their development and IT groups.
Once an organization has completed evaluating a cloud platform and is ready for production migration, they have the option of individual migrations or bulk migration. For companies with large numbers of applications, bulk migrations—if planned and executed properly—offer great economy of scale. The cost of migrating applications can be drastically lowered when they are part of a group effort. Operational costs in the cloud may also be lowered by finding opportunities to co-locate applications and data on shared resources.
Bulk cloud migrations are best served by a factory approach, in which similar applications and migration tasks can be made cookie-cutter and easily repeatable. In this model the “factory” are lower-rate migration teams who make up the majority of the work force. The factory is supported by an advance team, an exceptions team, and QA teams.
Applications migrated together can be retrofitted for uniform methods of monitoring and analytics; and configured for auto-scaling.
Neudesic has implemented the factory approach for the Windows Azure platform in its Azure Migration Factory service offering.
Large-scale migrations require large-scale thinking. The factory approach described here provides a scalable pool of affordable migration resources, coupled with the support of senior resources necessary to ensure success.