Have you ever made a business decision without weighing all your options first? If so, did you achieve the results you wanted? Or, do you prefer to look at the pros and cons of the options before you, analyze the effect each path would have on your business, discuss with critical team members, and conduct diligent research prior to making that decision? I’m willing to bet the answer is the latter. When making a decision that will impact your entire business, it’s important to look at all the options in front of you and give careful consideration to how each will help you achieve the goals you’re aiming for. Well, moving to the cloud is no different.
Our last 2 blogs have focused on cloud migration and how to make the move painlessly, as well as the information you need to do so. Last week, we introduced 2 paths for migrating to the cloud and a brief overview of both approaches— or re-architecting. This week, our 2-part series is focusing on each approach, why choosing a migration path matters, and how to determine which is right for your organization.
Earlier this week, we discussed the lift and shift method, but today we will zero in on the ins and outs of re-architecting.
Re-architecting Your Cloud Environment
In our last blog, we compared moving to the cloud to moving into a new living space. In this analogy, the lift and shift approach was akin to moving all your furniture you currently have into a new space and working within the confines of your new walls. The re-architecture approach, however, is more customizable. It’s like moving into a house and building furniture that’s custom to the exact contours of your new home.
As you can probably assume, re-architecting (or, redeploying) can be more costly up front and take more time than rehosting (aka: lift and shift), but is worth the effort in the long-run. This is because you’re completely customizing your environment to meet your business and cloud needs. Re-architecting allows you to reap the benefits of cloud-native functions, adopt DevOps early to build applications into your environment, and optimize operational costs and efficiencies in the cloud.
Organizations that choose to go the re-architecting route are typically motivated by the scalability offered by customizing your own cloud environment, as well as enhancing performance, agility, or business continuity. Furthermore, redeploying your environment allows you to bake your cybersecurity measures into the applications in the beginning, as opposed to tacking them on at the end.
Cloud Migration and the Shared Responsibility Model
Speaking of cybersecurity in your new cloud environment, it’s important to remember that the safety and security of the cloud is everybody’s responsibility—that includes during the migration period.
Regardless of the route you choose—rehosting or redeploying—you’ll need to outsource a vendor to host your cloud environment. Cloud security is a shared responsibility between the cloud service provider (CSP) and the customer. The CSP is responsible for “securing the cloud itself” and the customer is responsible for “securing what is in the cloud.” While it’s critical to ensure the provider has ample security for their infrastructure, controls, and applications, the buck does not stop there. As the customer, you should be doing the same. Keeping this in mind is a key factor in choosing the right migration path for your organization.
How to Determine Which Path Is Best for Your Environment
In order to effectively determine which migration path is the best for your organization it’s critical to understand why you’re moving to the cloud in the first place (i.e.: cost, agility, performance, modernization of infrastructure, etc.), and then research your various options in doing so.
As mentioned in our last blog, remember that it doesn’t have to be all or nothing. Just as you’re most likely not going to move over every single workload you have all at one time, you’re also likely to have some applications that make sense to re-architecture and others to lift and shift. Assess your current environment and your goals for each workload, then determine what makes sense for each one, or if you should migrate everything at once and how.
If you’re prioritizing speed and cost, lift and shift is the way to go. Remember the potential downsides, though, with technical debt, reliability, and the improvements that come with modernizing your application architectures.
However, if you want to leverage the advantages of cloud-native services such as serverless functions, containers, managed database, and PaaS services, and are moving your own application to be SaaS-based, re-architecting is likely best for you. As mentioned above, this takes longer but often leads to a more reliable architecture that operates on services that take advantage of the cloud’s many benefits: elasticity, scale, and reliability.
Your cloud migration will only be as successful as you plan for it to be. Consider your current environment and your overall organizational priorities for moving to the cloud, and weigh the options in front of you wisely before moving forward.
If you’re on the fence about which path is best for you, or how to start your migration to the cloud, reach out to an Armor representative today.