Design cloud migration factory
A cloud migration factory provides the borders for the execution of the cloud migration strategy and which are moving the application groups to the cloud deployment model at the selected cloud provider. The cloud migration factory allows an organization to set up a cloud ecosystem that can reliably and securely deploy workloads to the appropriate cloud service at a speed to meet business demand.
What is a cloud migration factory?
The cloud migration factory with governance oversight provides a holistic view into and coordination of the cloud migration initiatives that is enabling the organization. With the migration plan in hand, the factory needs to be set up with migration services established as well as their service providers, tools, resources staffed and trained, and oversight in place. When the migration strategy, plan, and factory are established, simply start executing a repeatable, efficient, flexible process that can provide provisioning, migration, testing, rollbacks, training and cutovers with monitoring and reporting. During pre-migration it will validate the completed migration to ensure the workload is properly secured, performs adequately, and implement any maintenance, backup or disaster recovery tasks needed to support the application in the cloud.
Depending on the volume and complexity of migrations progressing through the cloud factory migration, a third party that provides services, execution resources and subject matter insights may be brought in to provide some combination of setting up the factory, running the factory and or overseeing the factory. The third party is able to provide a blueprint and process for moving to the cloud in a secure and reliable manner that is linked to providing value to the business.
The setup of the cloud migration factory is similar as the factory assembly line process and can be divided into gates. The cloud migration factory model relies on a set of well-defined activities, steps and associated performance measurements that provide visibility into how the workload migrations are conducted, how many there are, and how the types of workloads are being executed by the factory in terms of speed and scale.
The cloud migration factory helps organizations evaluate how the operating model must change and prove the new way of working as they migrate. Utilize this type of approach, and do not run the risk of migrating workloads to the cloud and realize the organization is not fully-prepared to effectively manage and govern provisioning, usage and performance. Example of the cloud migration factory framework is as follows:
- Gate 1) Eligibility criteria:
- Determine the workloads that are going through the cloud migration factory based migration.
- Gate 2) Factory readiness:
- Develop low-level designs
- Develop architectures
- Develop migration plans
- Develop proof of concept reference
- Identify the right cloud migration tools
- Develop runbooks, playbooks, test plans, success criteria, best practices, and create blueprints.
- Gate 3) Environment build:
- Develop target shell
- Build compute, storage, network, database, middleware, golden images, containerization
- Begin storage replication
- Setup security
- Monitoring tools
- Gate 4) Migrate workloads:
- Play runbooks
- Migrate workloads
- Move containers
- Build applications
- Configure data
- Integrate data
- Synchronisation of data
- Accessibility
- Gate 5) Validate workloads:
- Run test cases
- Validate functional and non-functional parameters
- Validate security compliance requirements
- Compare benchmarks
- Request approval to the business via the go / no-go call.
- Gate 6) Certify workloads:
- Sent out validation summary report
- Sent out application functional testing report
- Sent out performance testing report
- Gather reports signed-off by the business
- Gather 3rd party certification (optional)
Communication Plan
During the execution of the gates the cloud migration factory is following a regular communication plan during each phase of the cloud migration which is clearly defined.
- Pre-check completion status mail: Send pre-check completion status mail to get the sign-off for migration of the applications and/or infrastructure completed. This will happen one or two days prior to migration date.
- Confirmation to initiate migration: Couple of hours prior to migration schedule, request for confirmation to start the migration as per schedule. Once confirmation is received migration engineers will initiate the migration as per the schedule.
- Post confirmation: Send post-migration status mail once the migrations are completed to initiate post migration checks. Once get the confirmation, post-migration check will be done and then applications and/or infrastructure will be handed over to support team for their validation.
Setup the cloud migration factory
The cloud migration factory would be involved in all types of cloud build and workload migration activities wherein resources will be provided with a set of standard operating procedures (SOP) to follow the during cloud migration.
As a cloud migration factory the workload will be provided in application groups. The migration factory is normally driven as a model wherein there will be a technical single point of contact (SPOC) who will be guiding on the technical aspects and migration time windows. Each of the workload which comes into the cloud migration factory will go into the quality assurance process for providing quality deliverables. Post migration handover, the cloud migration factory team will be supporting on troubleshooting and roll-back processes based on need.
The first step in building a cloud migration factory team is to determine the number of associates required. Resource management is determining the number of people needed to provide IT services specified in the SLA. Resources are one of the primary cost components, so planning the headcount and profiling of the cloud migration factory becomes a key consideration. Decide on the skill set, roles and headcount the following:
- Scope of the cloud migration factory
- Communication methods (for example phone, email, portal, messages, etc.)
- Structure of cloud migration factory
- Business expectations and signed SLA on resolution targets
- Weekdays, weekends and holidays to determine load pattern and the shift roster requirements
- Budget and resources
- Complexity of current application and infrastructure landscape.
The resources once arrived must be constantly reviewed and realigned by doing trend analysis on SLA achievements, business feedback, and work load patterns.
Team huddle
Team huddle is an activity that would happen in a frequent interval. This is an opportunity to make the team aware of the changes or any updates. This is an effective way of doing it as the queries related to the change can be answered then and there which is one thing that cannot be done through any other means of communication. Following are the various activities that could be discussed during the huddles, however this is not a definitive list. Project teams need to add any other topics that will be discussed in the huddle:
- Previous day statistics
- Complaints and compliments
- Process changes and updates
- Allocation of work
- Service improvements
- Performance metrics
- Learning and development
- Updates for the day
- Plan for next week
Tasks
- Split cloud migration phases into smaller application groups and workloads to efficiently manage the cloud migration.
- Plan the cloud migration during application non-peak business hours with sufficient downtime and user notification given to business users.
- When planning for cloud migration ensure the VMware ESX Server network interface card speed is sufficiently free for the VM hosted in VMware ESX to be moved swiftly.
- Do not plan to move multiples VM’s from the same VMware ESX server host together, since it may lead to a bottle neck.
- Use storage swing kit to migrate workload data wherever possible.
- Take a full backup of the workload before migration and rollback mechanism in case to overcome any failure.
- Backup policies and/or procedures have to be revisited based on the target cloud.
- Improve the operational posture, and enhance SLA’s and OLA’s.
- Develop runbooks and design guides for operational silos such as backups, monitoring, and deployments.
- Update operational playbook.
- Develop business continuity planning (BCP) / DR playbook.
- Document and define the cloud IT service management (ITSM) model. Based on the criticality of the application and downtime, choose the best cloud migration tools. E.g., Double Take, Racemi, Plate Spin, VMware convertor.
- Have multiple cloud migration tool options for every workload and choose the best to suit the scenario in a heterogeneous OS environment.
- Plan sufficient amount of tool licensing for parallel workload migration.
- Assess bandwidth availability between datacenter and cloud provider for migration and if required upgrade it during migration.
- Assess the application traffic is lesser than the network traffic for migration. If the rate of change for the server is more than the network bandwidth, the migration will likely fail.
- When designing for cloud migration, decide a replication methodology considering underlying hardware/firmware compatibility.
- Verify the discovery data repository from application to infrastructure to business user level so that it is clearly understood what the migration risk and communicate to stakeholders is.
- Determine changing OS licensing provisions. Target cloud might not support and/or follow the same kind of licensing that is in source.
- Check the close coupling and/or dependencies between the applications based on which cloud migration grouping must be made.
- Plan the migration based on the disk format. Make sure how the conversion is done or if required conversion tools are available if migrating entire virtual disks (like VHD to VMDK).
- Patch update (OS, application, antivirus) tools / procedures / documentation have to be revisited based on the target cloud.
- Having a planned exit strategy would ensure we have all our configurations, performance statistics and metadata leaving with us at any time while moving out.
- Make sure the target state cloud SLA are in-line with the overall requirements.
- Target compatibility check like virtualization cloud feasibility. Prior to migration (in case of P2V), software tuning and legacy software removal that do not fit into the virtualization environment must be done.
Hints and tips
- Remediate initial footprint target cloud and increase efficiency through cloud migration competency.
- Maintain compliance with BAU process and artefacts, but engineer cloud migration factory to optimise throughput.
- Identify areas of automation for build and migration services and run parallel automation tracks for identified areas.
- Execute the test plan in coordination with the testing team.
- The infrastructure will be shared with the cloud migration factory team and pre-migration checks are to be completed.
- In case of any issues related to pre-checks, communicate to onsite project managers and get them addressed.
- Data received into the cloud migration factory from the application and infrastructure discovery phase should be detailed and of high quality to avoid another assessment and/or validation activity.
- Access rights to the provisioning tools must be granted.
- The factory should be able to run independently.
- All business decisions and/or approvals must be available upfront before the application goes to the cloud migration factory.
- Availability of communication plan covering planning, scheduling and migration execution.
- Setup a command and control center as a single accountable team to provide end-to-end visibility of migration process and current status.
- Maintain steady velocity and forecast based on the defined application groups.
- Leverage automation and accelerators as much as possible.
- Use a partner to help with resource constraints as the team supports regular business activities.
- Have a prepared skilled staff on hand. Staff needs to know all the new technologies and processes.
Activity output
