Categories
Archives
- September 2024
- August 2024
- July 2024
- June 2024
- April 2024
- March 2024
- January 2024
- December 2023
- October 2023
- September 2023
- August 2023
- July 2023
- May 2023
- April 2023
- February 2023
- January 2023
- November 2022
- October 2022
- September 2022
- July 2022
- May 2022
- April 2022
- February 2022
- January 2022
- December 2021
- November 2021
- September 2021
- August 2021
- July 2021
The next phase of the migration planning is to determine how your migrated services will be built. This may be a simple lift-and-shift of one VM to a new VM in Azure, or you may take the opportunity to modify the technologies you use.
This part of the process is more than just technical decisions – you need to understand the reasons for moving to Azure; therefore, you must involve the senior decision-makers to help define the scope.
Depending on the motivation for the move, you may want to move some or all of your infrastructure. This also plays a vital role in determining how your systems migrate – not from the physical move’s point of view, but the actual process you choose.
The options available when choosing your end-state architecture can be grouped as follows:
- Rehost: Also known as lift-and-shift. This is the simplest – you simply move your on-premises VM to a VM in Azure. It will also be the easiest as no other work is required for the applications that run on the VM. However, the rehost approach doesn’t provide many automated scaling and cost-saving opportunities in Azure.
- Refactor: Depending on your application, it may be possible to leverage one of Azure’s many PaaS components. The obvious examples would be moving databases to Azure SQL or an IIS hosted web application to an Azure web app. Not all applications are quite so simple, and some systems leverage more advanced Microsoft SQL options such as SSIS, which are not as straightforward to move; in these cases, the lift-and-shift approach may still be the best option. Moving to PaaS, however, does provide greater cost efficiencies, resilience options, and scalability.
- Re-architect: If you have the time and aspiration, completely re-architecting an application can bring the most significant benefits. By employing different architectures such as messaged-based, containerization, or using other serverless technologies, you can make your solution fully cloud-native, save costs, and get greater performance, resilience, and flexibility.
- Rebuild or decommission: You may need to entirely rebuild an application from the ground up. Or you may decide the application is no longer required. Business needs change over time, and a migration to the cloud and the necessary planning can be an excellent opportunity to re-evaluate applications.
- Replace: As part of the evaluation process, you may decide that your business needs could be better served by replacing applications with other systems or third-party products.
The option you choose should take into account business motivation, budget, and timescales. It may be better to spend more time and money upfront on re-architecting services to save money and provide greater flexibility in the long term.
Alternatively, speed may be the most critical factor, in which case a simple lift-and-shift could be the best option. Finally, a hybrid or phased approach may suit – many organizations perform a rehost as an initial step in a migration project, followed by a re-architecture of systems once everything is in Azure.
Whichever path is chosen, once you know what and how you wish to move, the next step is to select a methodology and tool to perform the actual migration.
Leave a Reply