Define migration plan

Define migration plan

Organizations need to develop a migration plan, define the most efficient way to migrate the applications within their portfolio and the best way to prioritize them. With the variety of the applications involved, the complexity of migration varies accordingly. Much of it is dependent on the existing licensing arrangements and the architecture involved. As a general suggestion, it is best to begin with an application that is at the low end of the complexity scale (low-hanging fruit). The reasons is obvious, it will provide the user with immediate positive feedback and quick win for confidence.

Designing the migration plan and approach is a key component and driver for future planning. Produce a draft migration schedule and timetable of migration events. The migration approach takes input from the migration plan and all discovery activities. It analyzes these inputs to create a set of repeatable migration activities that describe the techniques and tools used for each technology and a migration approach which describes the lower level detail for each migration phase. Multiple options are possible for defining the migration strategy, e.g. data migration, storage migration, application migration, etc.

Data migrations
Data is stored on various media in files or databases, and is generated and consumed by software applications which in turn support business processes. The need to transfer and convert data can be driven by multiple business requirements and the approach taken to the cloud migration depends on those requirements.

Storage migration
The physical media will take advantage of more efficient storage technologies. This will result in having to move physical blocks of data from one tape or disk to cloud storage, which is using virtualization techniques. The data format and content itself will not usually be changed in the process and can normally be achieved with minimal or no impact to the layers above.

Database migration
It may be necessary to move from one database vendor to another, or to upgrade the version of database software being used. The latter case is less likely to require a physical data migration, but this can happen with major upgrades. In these cases, a physical transformation process may be required since the underlying data format can change significantly. This may or may not affect behaviour in the applications layer, depending largely on whether the data manipulation language or protocol has changed, but modern applications are written to be agnostic to the database technology, for example, a change from Sybase, MySQL, DB2 or SQL Server to Oracle should only require a testing cycle to be confident that both functional and non-functional performance has not been adversely affected.

Application migration
Changing application vendor, for instance a new CRM or ERP platform, will inevitably involve substantial transformation as almost every application or suite operates on its own specific data model and also interacts with other applications and systems within the cloud environment. Furthermore, to allow the application to be sold to the widest possible market, COTS packages are generally configured for each customer using metadata. Application programming interfaces (APIs) may be supplied by vendors to protect the integrity of the data they have to handle.

Define migration path

Now that we have the discovery data, and before we start planning, we need to walk through the options of migration patterns. A key takeaway from this should be that even within one application stack, it is possible to have multiple options of migration paths. What we typically see in the field is about 50% re-host, 25% re-platform, 15% re-factor/re-architect and the rest spread amongst retire, retain and repurchase.

When developing migration plans, the devil is in the details. Critical planning factors can easily be overlooked. Identify the intended use and requirements, the broad strategy, and the architectural concepts for how cloud services will be delivered. As an example, below list of topics can be take into consideration in the migration plan.

• Identify what cloud services and data will be provided
  • SaaS
  • PaaS
  • IaaS
• Define what cloud deployment model will be used
  • Public cloud
  • Private cloud
  • Hybrid cloud
• Establish how the migration will occur
  • Conducting a proof of concept (POC) before committing to further implementation
  • Full implementation
  • Phased implementation
• Develop a risk management strategy
  • Risk identification
  • Categorization of risks
  • Operational risks
  • Risk mitigation plan
  • Testing requirements
• Define the required metrics in the form of
  • SLA
  • Operating Level Agreements (OLA)
  • KPI’s
  • Specific performance metrics
  • Minimum acceptable threshold values
  • Minimum acceptable targets values
  • Tooling
  • Reporting
• Identified estimated funding required to cover
  • Acquisition costs
  • Contract costs
  • Life cycle operations
  • Staffing requirements

Tasks

1. Define the migration plan.
2. Evaluate the options (pros & cons) for each key decision.
3. Review of agile project management methods, tools, and capabilities to assess any gaps.
4. Define agile project management methods and tools to be used during the migration.
5. Define high-level cloud migration approach.
6. Define migration activities for all platforms and applications.
7. Define the overall migration approach describing the migration phases.
8. Define and create the migration communication plan, including reporting and escalation procedures.
9. Develop a risk, action, issues and dependencies log (RAID), and roles and responsibilities matrix (e.g. RACI) to manage the risks that occur during the project and identify ownership for each resource involved.
10. Review of the cloud migration portfolio.
11. Details of the application owners.
12. Contingency plan to ensure that the impact is minor if there are migration issues.
13. Review and confirm the migration event schedule.
14. Run key decisions workshop to review and confirm the migration approach.
15. Secure approval for key decisions.
16. Review and update migration plan following key decisions workshop.
17. Analyze all workload characteristics.
18. Analyze the route to live environments and tooling.
19. Procure and deploy agile project management tools to support the delivery of the project.
20. Identify key resources and leads for each of the cloud migration work streams defined.
21. Facilitate the coordination and activities outlined in the plan.
22. Outline resources, timelines, and cost to migrate the targeted environment to the cloud.

Hints and tips

• This is a critical activity that forms the heart of the job. Take care to make quick decisions but put in the staff work and consultation to make good decisions.
• Use analysis and logical processes to make decisions and follow fact-based methods.
• A key decision workshop could answer the following questions:
  • What are you moving?
  • What are the recovery point (RPO) and recovery time (RTO) of each application?
  • What are the compliance and security requirements of each application?
  • Who are the owners of each application and infrastructure component?
  • Where does all the applications and data live and how much capacity are they utilizing?
  • How is everything connected to the network?
  • Where are the dependencies and relationships, technically and operationally, between each application and infrastructure component?
• Establish a mechanism to identify and track completion of transition activities from the current as-is to the new to-be cloud environment.
• Over-communicate transition events with supported and supporting organizations.
• At the time of transition, arrange for turnover of key materials such as passwords.

Activity output

• Migration plan of approach document
• Cloud migration plan
• Migration event schedule
• Key decisions workshop output