Step 1 – Build a Cloud Roadmap:
One of the main issues organisations face when moving to the cloud is prioritising applications for migration. There are multiple approaches to take here, for example:
- You can identify your low business impact applications first, followed by medium business impact and high business impact applications, or
- You can migrate applications as they are, without any re-platforming or refactoring first.
Whichever approach you take, you need to analyse the application architectures, understand the application dependencies, identify the risks involved and migrate with a clear roadmap.
Step 2 – Cloud Setup, Licensing, and Governance:
Once you have a clear plan, you should identify the resources you need to manage your applications in the cloud. For example, for applications that you want to move as-is (i.e., without modification), run performance counters to identify peak loads on CPU, IO, Network and Storage. Select the right cloud instances based on this data. Make sure you determine which licensing model makes the most sense for your business. Pay-as-you-go models may give you the flexibility, but if you can predict your demand for the year upfront, reserving instances for a one or three-year period will save you money. In addition to direct licensing, you can purchase Azure through a cloud service provider that can provide additional value and cost savings. If you move your data using cloud-native services like SQL Azure or AWS RDS, be aware of all available options. Consider how you will set up your connectivity from on-premises to the cloud, your bandwidth and service level requirements, and choose the ‘best-fit options.
Step 3 – Define the Migration Process:
Align your migration strategy to your customised migration process and tailor it to each customer environment. The first step in migration is to create your subscriptions or accounts in your chosen public cloud and set up the right identity and access policies (e.g., IAM roles in the case of AWS and Azure AD in the case of Azure), including:
- Designing the best fit governance model using Identity and access management
- Designing and implementing SSO and MFA
- Implementing conditional access policies
- Creating the right resource groups and set up the appropriate resource tagging policies.
Step 4 – Plan for code refactoring
As you migrate your workloads, you may require some refactoring, especially if you are using applications or services that are not supported anymore. For example, suppose your applications use unsupported databases, authentication or business services. In that case, you may want to refactor those apps to use equivalent cloud services provided by the same or other vendors. It would help if you also refactored applications to make use of containers. Having your applications refactored makes it easy for your organisation to scale and manage microservices and gives you better agility.
Step 5 – Modernise Apps
Public cloud providers offer native cloud services that allow you to build highly scalable and readily available applications. They operate under a subscription model, so you are only paying for what you use of these native services. Once you migrate your applications as they are, you can look at opportunities to modernise your applications for the cloud stack to improve performance and scalability. The key activities in application modernisation are:
- Architecting and designing enterprise applications for cloud PaaS service to achieve high availability and ease of management,
- Refactoring the application code to the target cloud solution,
- Data modernisation, including upgrading data solutions to SQL, NoSQL, and document DB,
- Building Data Factory solutions to move data across sources,
- Building, orchestrating, and managing microservices,
- Modernising applications to leverage serverless functionality and achieve better availability and cost savings.
Step 6 – Establish Managed Services
Once the migration is complete, there must be a clear post-migration transition back to day-to-day operations, including support. Additionally, it will be well worth your time to have proactive monitoring and response levels in place to ensure that everything is operating as planned. The next step after migrating the VMs/Applications is to manage them. At this step, you need a “single-pane-of-glass” deployment and factoring visibility, governance, monitoring and management of all VMs/Apps, cloud environment (e.g., Microsoft Azure or AWS) and traditional infrastructure (hosted/data centre/on-premises) to be used. Managing cloud services is not the same as managing on-premises environments. The monitoring parameters, management metrics, troubleshooting, workloads performance tracking, network management, storage usages, and dependencies with cloud operators pose unique challenges.
Step 7 – Optimise Environment
Optimisation is the last step in the lifecycle of cloud migration. Once all Applications/VMs have been migrated and moved to managed services, organisations must closely monitor their resources to ensure maximum productivity, security, and compliance. Like all great journeys, having a roadmap is key to arriving at your destination quickly and safely. Following these seven steps to cloud migration will help you plan every step of the journey and expect the unexpected. To learn more about the best ways to accelerate your cloud migration efforts and shorten the time to value for your company and its customers, contact Techwave Australia today for a free consultation.
Techwave – Experts in Cloud Migration
Over the last few years, Techwave worked with numerous customers and performed several workload migrations to SaaS / PaaS / IaaS models to mitigate technical debt as part of their migration projects. We are drawing on our extensive knowledge and know-how and utilising our Cloud Migration Platform, with distributed architecture and automation-driven DevOps to accelerate the onboarding of applications to the cloud. Our Cloud Migration Experts were able to overcome a diverse set of migration challenges quickly and cost-effectively. Below are examples of some migration projects, but no two migrations are the same; each migration has unforeseen challenges that are there Techwave Australia’s uniqueness to solving those problems. A couple of examples are:
- Lots of legacies, expensive to maintain, on-premises applications, and they should not be
- Monolithic architectures that are hard to manage, scale when they should not be
- Too many companies view application management as an afterthought, and they should not
- Too many security breaches and cyberattacks, and that should not be
- Too much data without insights and analytics, and that should not be
- Poorly designed network architectures when they should not be
- Lots of legacies, expensive to maintain, on-premises applications, and they should not be
- Monolithic architectures that are hard to manage scale and should not be
- Too many companies view application management as an afterthought, and they should not
- Too many security breaches and cyberattacks, and that should not be
- Too much data without insights and analytics, and that should not be
- Poorly designed network architectures and should not be.