This blog explores the issues that you’re likely to encounter when you move legacy applications to hosted Clouds. These or similar issues surface for all major Clouds, including AWS, Azure, and Google Cloud. It’s no small feat to onboard complex applications their configurations, customizations, databases, and network connections. Including an operating system upgrade adds another level of complexity.
While this blog doesn’t explore in depth all the challenges that need to be addressed in an onboarding scenario, you can think of it as a good starting point. Having successfully moved thousands of apps, we could write a book on the topic, and maybe we should. In the mean time, here are 7 steps to successful cloud onboarding with VirtaMove.
Step 1: Assessing the Estate
“You need to know what you want to move…”
To undertake Cloud onboarding projects, you need to be equipped with a strong methodology and project structure. VirtaMove has a methodology, but I’ll spare you the details here. We have courses for that.
The essential first step in a project is discovery and assessment. You need to know what you want to move: which servers, how big they are, what operating systems they use, which apps they run, and which apps you want to move to a target Cloud server. You’ll also need to discover the dependencies between servers and apps on different servers. Server and app moves tend to be organized into related migration groups, so some planning around groups will be useful. You’ll also need to determine the version of the operating system of the target Cloud VM you want to move your workload to.
Our V-Maestro and V-Monitor software can help you with the estate discovery and assessment step.
Step 2: Cloud Provisioning
“Sizing is key…”
The next step is provisioning the target VMs or Cloud servers you want to move the workloads to. Sizing is key here:
- Modern operating systems need more processor and disk resources than outdated legacy OSs do.
- You’ll need extra disk space to support the migration. To complete a migration, you’ll initially need to provision Cloud targets to be 2 times larger in terms of processor and disk size. Once the migration is completed, you can resize servers and resources to accommodate normal workload needs.
You should choose a single operating system release or “Gold” version as a target: one for Windows and one release for Linux. Gold versions will let you easily upgrade all instances to new versions using automated Cloud management tools, and will also help with server hardening or security patches.
Step 3: Moving
Now it’s time to move the app workload to a new Cloud VM. Start with a walkthrough of the app with the user and the migration team to ensure a shared understanding of how the app works at a basic level. The migration team will use this basic functionality to do initial testing of the onboarded app.
Next, consider the network or pipe between the source server and Cloud environment. If you’re moving a large workload, volume may cause significant network latency. One way to work around this problem is to do a staged migration, where you complete the operating upgrade on a locally provisioned modern server on the same network as the source system. You can then use physical and file transfers to move the upgraded workload to the Cloud.
For high volume, large-scale onboarding projects, you’ll need to develop a repeatable approach to address network latency.
Using VirtaMove tools, moving could look something like this:
- You might complete the VirtaMove migration on a local destination server.
- Compress the container. This generates a CAP file, which is a compressed version of the container with all the application(s), data, and configurations.
- Transfer the CAP file to the hosted Cloud environment.
- Using the VirtaMove Administration Console, uncompress the CAP file. This ensures that the container is functioning.
Step 4: Reconfiguring
Now that you’ve completed the Cloud move, you need to address reconfiguration. Reconfiguration may include: server names, IP addresses, permissions, database access, access listing, license keys, security controls, and more. Many of these will be unknown. While simple issues like server names and IP addresses can be reconfigured on the fly, other unknown items will need to be discovered and resolved to make the Cloud instance work properly. You can use VirtaMove’s Config-on-the-Fly (COTF) tool to automatically swap or resolve items like hostnames on the Cloud.
Step 5: Testing
You’ve moved the workload and completed reconfiguration. Now it’s time to test. A standard User Acceptance process will ensure that all components of the new Cloud workload behave the same way as they did with the original source application.
If components are missing, VirtaMove uses AI to discover the missing components and automatically rehosts those components to the Cloud instance so further testing can be completed.
Step 6: Cut-Over
Once the application is verified and passes User Acceptance testing, you can plan a cut-over into production. At a high level, cut-over might look like this: the VirtaMove CAP file is used to complete a native install of the migrated application on the modern operating system. In addition, resyncing of all dynamic data and application components is required. If a relational database is part of the migration, it too needs to be resynced. At cut-over, the Cloud app becomes the new production system, so a sequester, quiet point, or cut-over window is required. Network performance might be a challenge during the available cut-over window.
Let’s talk about syncing the container on the Cloud. Some time has passed from initial containerization and completion of User Acceptance testing. How much time depends on how long it took to complete User Acceptance testing. To resynchronize, the latest version of data and files from the source Production environment is brought over to the Cloud. If there’s a long delay between initial containerization and User Acceptance testing, resynchronization may need to be completed in the local network domain before transferring the resynced CAP file to the Cloud environment. The CAP file is then used to natively re-install the application on the new server.
VirtaMove software supports complex synchronization functionality. You can select an “update” sync to make sure that the latest files are in the VirtaMove container. The latency in the resync process depends on the amount of new data being copied into the container. You can view a Latency Report to understand available network bandwidth.
Step 7: Upgrading
The application is installed and the new Cloud version is in production, but your work is still not done. The operating system might need new upgrades. Cloud tools can help keep your operating system up to date.
If you have source code for the application, you may want to consider app upgrades. For example, you might want to change the app to support microservices or support multi-tenancy in the Cloud. Security might need an upgrade, or perhaps you want to support a Cloud version of a database. Lots of app changes are possible, including load balancing, containerization, or fundamental functional enhancements.
Many scalable, modern Cloud tools are available to make these and other enhancements. VirtaMove is your best first move to get onboard the Cloud, and we can help with new operating system upgrades and containerization steps if needed.
If you need to move your workloads to the Cloud and would like to understand more about what VirtaMove does, don’t hesitate to call or email us. We’re pleased to share what we know.