So it is finally time to migrate from your on-premises deployment on to AWS. Like Morgan said in the prior video, it would be great to just snap your fingers and instantly you have all the elements from your existing on-prem data center magically appear on AWS, optimized and efficient. But it doesn't work that way. Every application or application groups, if they're tightly coupled, will have six possible options when it comes to your enterprise migration. We call these the 6 R's. Once you've gone through the discovery phase and know exactly what you have in your existing environment, you decide which option among the 6 R's is the best fit based on time, cost, priority, criticality. The first option is Rehosting. This is otherwise known as lift and shift. This is an easy thing for businesses to do because you're not making any changes, at least not at first, just pick up the applications and move them pretty much as is onto AWS. You may not get all the possible benefits, but some companies found that even without any optimization, they could save up to 30% of their total costs just by rehosting. Also, we find it's easier to optimize applications later once they already live in the cloud. Because your organization has better skills to do so, the hard part the migration is already complete. The second option is called Replatforming, or lift-tinker-and-shift. It's still basically a lift and shift, but instead of a pure one-to-one, you might make a few cloud optimizations. But you're not touching any core code in the process. No new dev efforts are involved here. For example, you could take your existing MySQL database and replatform it onto RDS MySQL, without any code changes at all, or even consider upgrading to Amazon Aurora. This gives significant benefit to your DBA team as well as improved performance without any code changes. Now, before we add more migration options, two of the 6 R's don't actually end up on AWS. Number three, Retire. Some parts of your enterprise IT portfolio are just no longer needed. We found as much as 10 to 20% of companies application portfolios include applications that are no longer being used. Or already have replacements, live and functional. Using the AWS Migration Plan as the opportunity to actually end of life these applications, can save significant cost and effort for your team. Sometimes you just have to turn off the lights. Number four, Retain. Some applications are about to be deprecated, but maybe not just yet. They still need to run but don't turn them off for another three months or eight months. These apps could be migrated to AWS but why? You should only migrate what makes sense for your business. And then as time goes on, these applications can be deprecated, where they live and ultimately retired, okay? Let's get back to what is going to move to AWS. Number five, Repurchase. This is common for companies looking to abandon legacy software vendors and get a fresh start as part of migration. For example, ending a contract with an old CRM vendor and moving to a brand new one. Or perhaps finally ending your licensing with an out-of-date database vendor in favor of cloud-native database offerings. Now, this sounds great, but remember, you'll now be dealing with a new software package. Some are easy to implement, some take time. The total upfront expense of this step therefore goes up. But the potential benefits could be substantial. Number six, Refactoring. Now you're writing new code. This is driven by a strong business need to add features or performance that might not be possible on prem, but now are within your reach. Dramatic changes to your architecture can be very beneficial to your enterprise. But this will come at the highest initial cost in terms of planning and human effort. Six paths to move to AWS. Once you have the inventory of all your pieces, choosing the right one for each part is critical to the success of your migration.
