More than 45% of IT spending will shift from traditional on-premises solutions to the cloud by 2024, according to Gartner. In this article, we look at why keeping legacy infrastructure might be worth it, and what you will need to reassess in your organization before adopting cloud migration tools and migrating applications to the cloud.
Why enterprises hesitate to opt for cloud migration services
Even though technology evolves at incredible speed, most IT systems are built to last for years — otherwise, it wouldn’t be financially reasonable to invest in them. When systems inevitably become outdated, some companies still prefer to keep them. There are a few valid reasons why:
- Some legacy systems are mission-critical and still satisfy a business need. A good example of such systems is traditional banks adhering to an “if-it-ain’t-broke-don’t-fix-it” approach and still competing with their digital counterparts. Such decisions are based on the possible risks of interrupting trillions of dollars circulating through the system.
- The investment in the legacy system might not be recovered yet, and it isn’t reasonable to switch over to a new one.
- Enterprises where operational efficiency is deeply rooted in legacy software often lack the IT expertise needed to go through cloud migration.
- Downtime, data loss, and other outage-related issues are just a few critical scenarios that make companies hesitate.
But on the other hand, cloud migration brings the following advantages to the table:
- Better resource allocation: When correctly executed, cloud migration can provide better leverage of resources, from purchasing them on a SaaS (Software-as-a-Service) basis to scaling them to fit a company’s business needs.
- Cut costs: Over time, operating expenses will drop as maintenance and hosting will cost significantly less.
- Reduced risks: The infrastructure and security features of cloud solutions are usually much more agile and well-developed than those of outdated legacy systems.
- Velocity: The operational agility of cloud tools introduces continuity and allows for ramping up to a faster time to market.
And, of course, any cloud migration framework has to tackle a few possible challenges:
- Lack of a cohesive cloud adoption strategy and migration goals
- Lack of resources — investment capital, time, and skills
- Poor cloud migration planning
- Wrong or outdated tech stack — unsuitable for fulfilling migration goals
- Wrong service model — can ruin migration at any stage
Cloud migration strategy:The 6 Rs
Let’s briefly take a look at the options all potential cloud adopters can choose from. Back in 2011, Gartner named five ways organizations can migrate applications to the cloud. Amazon Web Services (AWS) adopted this model and extended it to the six Rs:
- Rehosting means recreating the same application architecture but in the cloud, usually on an IaaS (Infrastructure-as-a-Service) basis.
- Replatforming, which is often described as “lift, tinker, and shift”, is basically a rehosting strategy that allows for some configuration changes.
- Refactoring allows the reuse of existing code and frameworks, but on a PaaS (Platform-as-a-Service) basis.
- Revising means keeping the code base but expanding or rewriting it before deploying it by either rehosting or refactoring.
- Rebuilding involves rebuilding an application from scratch using a PaaS provider’s platform. This can be more labor-intensive than other options, but it also enables developers to reap the benefits of modern PaaS vendors.
- Replacing is a self-explanatory option that usually implies switching to an out-of-box SaaS third-party solution.
A step-by-step cloud migration checklist
Here are a few mission-critical insights for you to avoid common mistakes and maximize your chances of a successful cloud migration process:
1. Establish the migration architect role to lead the effort
To provide the foundation for a successful move, you need to assign a responsible figure to the role of migration architect for the duration of the project. Their areas of responsibility will include technical decisions, planning, and execution.
2. Define the suitable level of cloud integration
There are two ways you can go about migrating your application.
For a shallow “lift and shift” cloud integration, there are no (or limited) changes to the servers to ensure the smooth running of the application. This type of integration is called “lift and shift” because the application is simply lifted “as is” and shifted to the cloud.
For deeper integration, you reconfigure and modify your application to leverage the benefits and capabilities of the cloud. The extent of the modification can vary from something as simple as auto-scaling and dynamic load balancing to something as sophisticated as serverless computing or a cloud-specific data store. These options vary in cost and complexity, so include them in the budget before you engage in any migration operations.
3. Choose between a single cloud provider and multi-cloud
It is much simpler to optimize your application for a single provider, but, at the same time, there’s the unfortunate downside of vendor lock-in. Moving your application to a new provider in the future would then be as challenging as the original migration from on-premises.
Splitting your application(s) across multiple clouds gives you more flexible business leverage in terms of pricing and configurations, but can also complicate the app development and validation process with so many provider capabilities to cover.
4. Establish cloud KPIs and their baselines
The existing KPIs (Key Performance Indicators) you have for your software might not be the best fit for the application in the cloud. Cloud-related KPIs should focus on possible migration issues and the status of the migration. Key metrics to consider include user experience, performance per component, application infrastructure, and business engagement.
Baselining defines KPIs for each of the metrics — More precisely, it’s the process of determining when the post-migration performance is acceptable. You can also refer to these baselines to diagnose any problems that arise at an early stage.
5. Prioritize components to be migrated
Depending on your resource allocation and deadlines, you can migrate your application to the cloud on a component-by-component basis or migrate everything simultaniously. In the first case, you’ll need a viable strategy to ensure your components are lined up for migration in accordance with your business priorities. You can start with the outside services — those that are closest to your end-users — and move inwards. Or you can take the opposite approach and start with the internal services that are least likely to impact your end-users’ experience.
6. Refactor your application
There are a few reasons why refactoring matters for cloud migration:
- If you refactor your application to allow for dynamic scaling, it will positively impact your future cloud service costs.
- Refactoring allows you to take your resource allocation capabilities to the next level, ensuring flexibility on demand.
- If your solution architecture needs to be service-oriented, refactoring makes moving individual services to the cloud easier.
7. Come up with a data migration plan
When the data access methods you use are tied to on-premises infrastructure, you risk damaging the performance of your application. The same is true if the service that requests the data is in the cloud but the data still resides on-premises.
To address this, you have two options. You can use a double-sided, bidirectional approach to sync data between your on-premises and cloud databases. Then, once you’ve moved all consumers of the data to the cloud, you can remove the on-premises database. Or you can switch between the databases when the time is right. Once everything is in the cloud, you can disable the on-premises database for end-user access and enable access to the cloud-based database instead. Alternatively, you can opt for a dedicated cloud data migration service.
8. Switch over the production system
What’s the best way to switch your production system to a new cloud environment? There are two options, depending on the complexity of your application’s architecture. The more complex it is, the slower you should move. You can either switch all traffic to the cloud once the entire application has been transferred and validated or test the waters with a small group of real end-users first.
9. Review application resource allocation
A fundamental purpose of moving to the cloud is to enable dynamic resource allocation for your enterprise. Otherwise, the whole migration effort won’t be cost-effective. Make sure you consider resource allocation when developing an enterprise cloud migration plan and/or re-architecting the application. With such scaling in mind, you’ll always be able to handle any resource demand at short notice.
Last but not least, consider cloud migration costs
When it comes to cloud migration costs, there are two extremes: the cloud migration solution being cheaper than on-premises, and on-premises being more inexpensive than the cloud. How is this possible?
Of course, you’ll have a monthly or yearly bill from your cloud provider, but in all infrastructure systems, there are hidden costs. Always consider how much you’ll have to pay for your own data center. Familiarize yourself with best practices for cloud migration projects, such as cloud governance and the latest DevOps practices, and don’t forget about the user experience.