Developing a Cloud Migration Framework

A Cloud migration isn’t a one size fits all proposition. It’s a consultative and analytical effort whether you are doing the migrationin house or outsourcing to a third-party systems integrator. Creating a Cloud Migration Framework – a phased cloud migration – gives you a tool for management, accountability, and status reporting whether you are going with a third-party systems integrator or your staff to work the migration. The framework should be written documentation, not an oral history of the migration. You want an audit trail to follow on your cloud journey to foster learning and accountability.

Another use for a cloud migration framework is as an educational tool for your stakeholders. As a framework, it offers many opportunities for reporting, demos, and other stakeholder touchpoints. Take advantage of these opportunities to shepherd your business and executive stakeholders through the migration process because a cloud migration framework offers you the audibility and chance to stop, take feedback, address issues, and communicate across your development, operations, and business organizations.

A typical cloud migration framework usually consists of three to four phases that take the migration from planning through operations:

Phase 1: Current IT Infrastructure Discovery and Assessment

Your organization can’t migrate to the cloud until you understand what IT infrastructure already has in place. Groups inside your organization may work in silos by business function, sometimes even unknowingly depending on factors such as your organization’s size and the number of office locations. Getting a full picture of what’s working may not be available to your IT department. For starters, your organization’s storage, network, and security teams may only work together infrequently. Getting these teams together should be a phase 1 activity for sure. 

Your cloud migration team should take form during this phase. If your organization has contracted with an outside professional services firm to run your cloud migration, they’re going to bring in their solution architects, business analysts, and other specialists. Chances are your IT department isn’t going to have these specialists on the payroll, especially if your organization is embarking on its first significant cloud initiative. In all reality, cloud migration teams should be hybrid and cross-functional teams with representatives from your solution provider, your CIO, IT, and cybersecurity teams. It’s also the time to add finance to your migration team to start working on the best ways to analyze your future cloud spending, cloud total cost of ownership (TCO), and financial models your CFO requires. Having a partner who can offer you support on the financial steps to the cloud can help you develop a business case and high-level vision to deliver to your executives and corporate board.

The processes that need addressing via cloud adoption may also sit in different departments. A lack of institutional knowledge or documentation also hinders proper assessment of a legacy application, applications suite, or enterprise. These are tidbits your organization may not know off-hand. They are the finding that can become known after a cloud migration team assesses your cloud readiness.

Your cloud migration team’s assessment may also find other issues such as inadequate network bandwidth and the over-provisioning of resources. Both problems can contribute to higher costs once your organization is in the cloud.

Having a joint solution provider and internal cloud migration team lets you answer the challenging questions about your organization’s actual state of cloud readiness. Team members from your development, operations, and security teams need seats at the table. The full team’s analyses and reports should help turn up where your enterprise excels or lags in cloud support. Those answers come from meetings and interviews with your organization’s business and application owners. Use phase 1 to spend the extra time to get their cloud requirements down on paper and set cloud migration priorities based on those requirements and your budget.

Any initial DevOps discussions should start during this phase with your developers, quality assurance, project managers, and operations stakeholders getting early input into the transformation. Considerations include process transformation, team training, and of course, continuous integration/continuous development (CI/CD) tool choice and roll out.

The security requirements that apply to your current environment also refer to a target environment in the cloud. It’s important to consider that the new target environment in the cloud may introduce new security risks. Your migration team needs to account for incident management, problem management, and compliance in their discovery work. 

Your migration team should inspect your enterprise environment for applications, data, servers, networks, and storage. This inspection should also focus on the various interdependencies between these elements. The most useful review is two-pronged:

• Automated tools to find physical infrastructure, application requirements and specifications
• Manual discovery of added requirements through interviews with application owners and business stakeholders

Inspections and discovery results can also help your organization determine migration security requirements, such as migrating applications with similar security requirements together. Other cloud security requirements may also arise at this time. Be prepared to involve your CISO and even compliance auditor at this time to get their counsel about your findings.

An optional exercise for this phase is to supply cloud training to your stakeholders through your training department using an online platform such as A Cloud Guru, Cloud Academy, or another training provider. Better educated owners make it easier for your migration team to illuminate the benefits the cloud can provide across your business. More importantly, the joint team is in a better position to assess your existing system gaps as you prepare to migrate to the cloud.

Phase 1 Outcomes

If you’re partnering with a professional service firm to perform your cloud migration, they should be delivering a recommendation report in their standard format to you as the customer. If your organization is managing its cloud migration, written documentation coming from this phase is imperative. Document your decisions and bring together your decision-makers so they can review written documentation and have adequate time to ask questions and express concerns.

Phase 2: Legacy IT to Cloud Operations Migration

Cloud migration is full of lessons for even long-time cloud-first organizations to learn, such as how the measuring of incorrect metrics hampers real improvement over time. For example, your company has a legacy application that’s up and running and meeting its service level agreement (SLA). The associated network usage associated with the app is also meeting its SLA. The user experience is inadequate (slow response time) and may not be measurable. In this case, insufficient storage might have been provisioned.

Another case is that the budget for running the application on the cloud is more costly than expected. Changes in architecture can be a requirement to increase performance, supply more security, or address neglected best practices. A systems integrator experienced at cloud assessments and familiar with these potential issues can help your organization solve these challenges.

During this activity, your migration team moves the actual infrastructure, applications, and data to the new cloud target environment. The first part of this activity is planning the migration. The team then takes the output of the discovery and begins developing the migration plan(s). The team develops the plan(s) by analyzing the discovery findings to group applications with accompanying estimates for their migration. The project plan should account for a pilot and testing phase before your cloud applications go live into production.

The team should also develop testing plans to verify:

• Migrated applications functionality, including back out strategies if the testing is not successful
• Application performance ensuring business aims to meet or surpass any Service Level Agreements (SLAs)
• Application security including any user access constraints or encryption of data requirements

If your cloud migration also corresponds with a move to DevOps, your organization’s DevOps toolchain comes online during this phase. It could take the form of CSP native DevOps tools, hybrid tool, or cloud-first toolchain depending on how the requirements land during the discovery phase.

Also developed during this activity are the cloud metrics your stakeholders may require to gauge overall cloud migration success. These metrics are the genesis of any cloud performance baseline. Set time aside in the migration schedule for review and approval by the right stakeholders. 

Cloud migrations happen at three levels of your technology stack:

• The infrastructure level where your migration team develops the new environment to prepare for application migration. Typical migration preparatory work at this level includes setting up Active Directory, creating a Virtual Private Cloud, and other system-level activities.
• The application-level where the migration team designs, migrates and confirms each application according to one of the six application migration strategies. For purposes of this article, those strategies are Rehost, Replatform, Replace, Refactor, Retire, and Retain. The migration team starts with your least complex applications such as team and department level custom applications and works towards migrating your more complex application migrations. All work at this level should take place using a continuous improvement approach because you want status reporting and demos for feedback to spare you any surprises post-migration.
• The data level where the migration team the application and system-level data move to the cloud and any use of SaaS services such as AWS RDS for the database are set up. Data recovery takes place in the cloud, or the team loads data in a new database. This migration happens with cybersecurity support.

Migration teams work through a prioritized list of workloads based on migration patterns, apply known migration and operational models, and reduce risk. After the movements are complete, the teams work with the customer to perform functional and performance testing, validation of the new environment, and retirement of the old systems. The final work in this activity is the cutover of Production systems to the new cloud target environment.

Security during this phase must include data protection at rest and while in transit. There’s also guaranteed to be cases where your teams will have to implement new access security measures such as identity access management (IAM).

Phase 2 Outcomes

The migration of your applications and data to the cloud during this phase usually leads to one of two outcomes. One outcome is a pilot of your newly migrated applications to give your technology a business stakeholder a trial period then the application(s) entering production. The other – less advised – outcome is to take your application(s) directly into production.

Phase 3: Operate and Optimize

Finally, once your organization migrates applications to the cloud, decommissions your old systems, and takes its first steps to a modern operating model. This phase should start with a transition period as your solution provider’s team starts to transition off the project. Your team members who’ve been on the project since phase 1 now can kick start critical cloud operations activities such as checking metrics, SLA management, cloud services optimization, and of course, cloud security.

DevOps transformation should also take-off during this phase. Treat your first projects through your new toolchain as pilot projects. Also, you should factor time into your project sprints to collecting reporting from the tools and feedback from your teams to instill a continuous improvement approach well into cloud operations.

Phase 3 Outcomes

Full or partial cloud operations isn’t the actual end of your cloud migration process. As you learn more about cloud management, security, and cost optimization, it might be time to repeat all or some of this migration process as you migrate a new wave of applications or onboard new users to your cloud applications. 

About the Author

Will Kelly is a writer focused on Cloud and DevOps. He works as a technical writer for a systems integrator in the Washington, DC area. Over his career, he has worked on commercial and public sector client projects. Will’s technology articles have been published by TechTarget, Opensource.com, CNET TechRepublic, and other major sites. He has also developed thought leadership content for industry leaders including Cisco, IBM, and Samsung. Follow him on Twitter: @willkelly