Welcome Login

You are here

Inquiry #4: Please help us with market research regarding cloud migration.

The Cloud ConFIG team continues to work feverishly on the forthcoming Draft RFP. As part of such, we're forging ahead with market research on topics salient to a successful draft.
 
In this Interact post we'd value your feedback on cloud migration. Please feel free to respond to the post and become a valuable part of the conversation. Alternatively, you may email your feedback to us at CloudConFIG@gsa.gov.
  • Question: How do you define "migration" as it relates to cloud services (perhaps including but not limited to what are the high level steps required for success)? By "migration" we mean moving infrastructure, platforms, and/or software from a traditional or on-premise set up to a cloud solution.

Your response is critical to Cloud ConFIG's success. Please be a part of the conversation and share your insights!

Thank you,

The Cloud ConFIG Team

Groups audience: 
- Private group -

Views: 12449

Comments

rlewis88
<p>Cloud migrations can be as complex or simple as the customer needs it to be based on what they have done already, how many applications they are migrating, what kind of &ldquo;operational model&rdquo; they are using (DevOps vs. Traditional), and how complex those applications are.&nbsp; Typically migration services are broken into 3 phases that work in tandem with one another:&nbsp; pre-migration, migration, and post-migration.&nbsp; It is important to conduct all of the activities in each phase, but it is entirely possible a customer has done (or will do) some or all of them.</p><p>To that end, there are a number of tools that allow you to &ldquo;draw a box around&rdquo; an application and then essentially &ldquo;drag and drop&rdquo; it to a cloud service - which would be the most basic version of a migration.&nbsp; That said, experience tells us that conducting a migration in that manner without conducting any pre-migration or post-migration activities can be dangerous - mainly if you don&rsquo;t have an actively maintained source for all of the other information you need to know outside of the physical or logical characteristics of the application.&nbsp; Without that source of information the &ldquo;drag and drop&rdquo; method often times results in failed migrations or application downtime.</p><p><strong>Typical activities for a traditional migration would include:</strong></p><p>Application Discovery (Pre-Migration):</p><ul><li>Conduct application inventory to include attributes like admin privileges, app owner, or anything else related to the governance of the app</li><li>Establish a data repository for project awareness and maintaining customer data</li><li>Develop app inventory with characterization of interdependencies</li></ul><p>Cloud Migration Planning (Pre-Migration):</p><ul><li>Define applications targeted for migration to the Cloud</li><li>Define mission drivers and organizational constraints</li><li>Define/document application interdependencies and network connectivity</li><li>Develop detailed migration plans</li><li>Prepare hour by hour relocation schedule with specific resources</li><li>Develop cloud migration roadmap and project schedule</li></ul><p>Migration:</p><ul><li>Conduct pre-relocation risk mitigation using best practice processes</li><li>Conduct logistical planning required for migration to cloud</li><li>Prepare target locations in the Cloud</li><li>Perform application migration to the Cloud</li><li>Communicate with stakeholders and end-users</li><li>Operations Integration</li></ul><p>Acceptance (Post-Migration):</p><ul><li>Test application interconnectivity (IPs, DNS, etc&hellip;)</li><li>Execute acceptance testing plans</li><li>Communicate acceptance and resumption of normal business</li></ul><p>These activities, however, assume the application is not already in a cloud.&nbsp; If the application is already based out of a cloud the steps can change slightly &ndash; though one could argue they all still exist in some form.&nbsp; <strong>A good example is an application managed in a DevOps model making full use of PaaS technologies.&nbsp;</strong> The point of DevOps is to be able to make changes on the fly and give developers the flexibility to deploy workloads as needed to wherever they need.&nbsp; Rather than cutting an application over all at once, developers can deploy dev and test workloads under the new model, allowing testing while an old version of the application (on the old stack and/or cloud service) remains in production.&nbsp; It isn&rsquo;t until testing (most likely automated) has been completed that the &ldquo;new&rdquo; app would be deployed in production and appropriate cutovers made.&nbsp; In this case there still needs to be a gold source of information to ensure the governance of the application continues normally, and there would still need to be some level of acceptance testing post production deployment, but overall it is a much less rigid methodology, and much quicker &quot;to-market&quot; system than the traditional one.</p>
CAFE Team Blogger
<p>Mr. Lewis,</p><p>Thank you so much for the thoughtful and comprehensive response. It is just this type of feedback that contributes to a better prodcut on our end.&nbsp;</p><p>Many thanks and please keep the information coming.</p><p>- The Cloud ConFIG Team</p>
  • gbudati2586
  • angielienert
  • Robin S Gardner