Tips for planning a cloud migration of a server?

We currently have a system that we are running on-premises, that management wants to get options regarding moving into AWS (as a series of VMs)

This is my first time doing this kind of evaluation, and I'm worried about the normal stuff - cost over time, IO, storage, all that.

Does anyone have recommendations on how I can leverage Orion to do this? We have over a year's worth of data on the various on-prem servers in SAM and VMAN, so I should be able to look at trends over that time. I'm just not sure where is the best place to look.

Parents
  • Hey @ahbrook, 

    We have written a cloud migration guidance, here are some tips (so-called 6 R's) from it:

    Replatforming 

    During replatforming, also known as “lift, tinker, and shift,” developers make several minor optimizations before migration. This doesn’t include changes to the app’s core architecture, however, as that falls under refactoring. 

    Refactoring/rearchitecting

    Refactoring implies reengineering the solution in order to create a cloud-native version of it. This strategy is the most time-consuming and costly. 

    But it ensures long-term cost savings by matching actual resource requirements with cloud infrastructure. Also, cloud-native apps allow companies to quickly adapt to new customer requirements, since developers can easily add or modify existing functionality.

    Rehosting (lift-and-shift)

    With this strategy, developers simply take system components from on-site servers and move them to the cloud without changing anything. This strategy is easier, faster, and cheaper than the previous two strategies because developers don’t need to change anything in the system. It also boasts easier compliance and security management, since apps don’t change security and compliance properties.

    Repurchasing

    You can use this strategy if you have commercially licensed software and want to switch to a SaaS solution. For instance, you can move from a proprietary on-premises customer relationship management (CRM) system to Salesforce. 

    Retiring

    Sometimes in the process of developing an application portfolio, you find applications that you don’t need anymore or that have the same functionality as other apps you use. In this case, retiring them is the best option. 

    Retaining/revisiting

    Sometimes, either for security reasons, due to the need for major refactoring efforts and help plan, or because of regulatory compliance, your app needs to remain on-premises. You can revisit apps of this category later, to check if they can be moved to the cloud after a while. 

    To get more info you can visit the full version of the guide. Good luck!

Reply
  • Hey @ahbrook, 

    We have written a cloud migration guidance, here are some tips (so-called 6 R's) from it:

    Replatforming 

    During replatforming, also known as “lift, tinker, and shift,” developers make several minor optimizations before migration. This doesn’t include changes to the app’s core architecture, however, as that falls under refactoring. 

    Refactoring/rearchitecting

    Refactoring implies reengineering the solution in order to create a cloud-native version of it. This strategy is the most time-consuming and costly. 

    But it ensures long-term cost savings by matching actual resource requirements with cloud infrastructure. Also, cloud-native apps allow companies to quickly adapt to new customer requirements, since developers can easily add or modify existing functionality.

    Rehosting (lift-and-shift)

    With this strategy, developers simply take system components from on-site servers and move them to the cloud without changing anything. This strategy is easier, faster, and cheaper than the previous two strategies because developers don’t need to change anything in the system. It also boasts easier compliance and security management, since apps don’t change security and compliance properties.

    Repurchasing

    You can use this strategy if you have commercially licensed software and want to switch to a SaaS solution. For instance, you can move from a proprietary on-premises customer relationship management (CRM) system to Salesforce. 

    Retiring

    Sometimes in the process of developing an application portfolio, you find applications that you don’t need anymore or that have the same functionality as other apps you use. In this case, retiring them is the best option. 

    Retaining/revisiting

    Sometimes, either for security reasons, due to the need for major refactoring efforts and help plan, or because of regulatory compliance, your app needs to remain on-premises. You can revisit apps of this category later, to check if they can be moved to the cloud after a while. 

    To get more info you can visit the full version of the guide. Good luck!

Children
No Data