Once you’ve completed your assessment, it’s time to prepare for the next step: migration to Azure.
This is when, after you’ve decided on your migration goals and gathered all requirements and constraints, you can choose the best method of migration.
Earlier, we described the strategies that you can use for migration—progressing from rehosting your apps, to refactoring and rearchitecting, and finally to modernization by rebuilding or replacing apps. In the Migrate step, you’ll determine the strategy that best meets your requirements—and this is usually best addressed on a per-application basis. In this step, you’re essentially physically moving your workloads and applications (including their data) to the cloud and planning to retire the on-premises versions. Every organization will have a different approach, and you might mix rehosting, refactoring, rearchitecting, rebuilding, and replacing your applications.
This time we focus on the rehost strategy – moving applications running on traditional servers and VMs to Azure IaaS. In many cases, organizations will start with lift and shift to drive rapid migration and early cost savings.
Lift and shift requires no change in an app or workload framework or architecture. It simply means hardware and OS are managed by the cloud provider. This approach requires confidence regarding two key issues: Can you easily migrate a workload without too many manual steps? And will the workload function as expected in the cloud? As such, several decision points come into play based on what’s being moved and especially how (or if) you want to access it while the migration is taking place.
The lift-and-shift method most often employed for server or VM migration is real-time replication because of its flexibility and support for a staged migration. Real-time replication allows the workload to remain online and accessible during the migration. Plus, modern tools enable the system to cleanly migrate real-time data even when the system is actively being used.
Real-time replication
Real-time replication involves setting up a copy of the workload in the cloud and allowing asynchronous replication to keep the copy and the original in sync. This means that while you’re building and executing your migration plans, any data or server updates are synced between the copies.
Real-time replication scheme
This model also enables groups of VMs to be connected, for example, for a multitiered application or workload. This is important for testing and the final migration cutover. When the system has a map of the connections and dependencies among VMs, you can create plans to ensure the VMs are bought up in the correct order when starting. For example, with a simple web app, your database source needs to be available before the application runtime begins.
Using your assessment plans as a guide and your migration tool of choice you can configure each VM to replicate to the correct VM instance in your cloud provider. This is also when you should define the storage and network connections that you set up initially when creating the environment. Most tools have a mechanism to define the replication timeframe (usually between 30 seconds and 15 minutes). This timeframe is based on your network capability and latency.
Many tools also support application-aware replication automatically. Microsoft applications (such as SharePoint, Dynamics, SQL Server, and Active Directory) and apps from other vendors (including Oracle, SAP, IBM, and Red Hat) can be migrated with application-aware replication, which ensures the source data consistency before replication. Initial replication is also bandwidth intensive, and mechanisms discussed earlier like ExpressRoute and Data Box can help you manage the bandwidth requirements of migration. It’s something to consider when planning your migration timeline.
Testing
Testing is integral to ensuring system health before final cutover. Many migration tools have options that let you start up a set of VMs in an isolated environment, which allows you to mimic the production environment in the cloud. This means you can fully test the application without affecting the on-premises or cloud production versions. Once replication is complete, simply start your application or workloads using the isolated environment option, and take some time to test your startup script or runbook for errors. When you’re fully satisfied that both function as expected, it’s time to perform the final cutover.
Migration tools can also perform the final launch in your cloud and turn off the on-premises application. In some cases, you’ll have to update DNS records for the new cloud-based workloads. However, if you migrated to use DNS in the cloud as part of your initial environment setup, this might happen automatically.
Are there any Azure tools for migration?
Because migrating servers and VMs is unique for each organization, multiple tools are available to support specific needs. These range from Microsoft tools like Azure Site Recovery to various third-party tools. Thirdparty tools are valuable alternatives when you have needs that aren’t covered by Azure Site Recovery. For example, while there are some OS types that Azure Site Recovery can’t migrate, other partner tools can support these efforts.
Database migration is supported by the Azure Database Migration Service. By using the Database Migration Service migration workflow, you can move on-premise databases to Azure. Database Migration Service enables schema and data migrations from SQL Server to Azure, including migrations to SQL Server on a VM or to Azure SQL Database. Database Migration Service also supports to migrate databases running on MySQL and PostgreSQL to Azure Database for MySQL and PostgreSQL respectively. In addition, SQL Server Migration Assistant (SSMA) and Data Migration Assistant can help with database migrations.
Alternatively, you might have other needs, like rapid migration (migrating more than 100 VMs per day), for which normal replication might not be sufficient. In these cases, specific tools can assist you with migrating the runtime to Azure first while leaving the storage onpremises. Then, over time, the storage is replicated. Many tools can meet your unique migration needs. Customize your company’s migration approach with help from the Azure Migration Program
