Seamless Migration of Azure Cloud Services (classic) to Cloud Services (extended support)
Azure Cloud Services is a widely used Platform-as-a-Service (PaaS) offering that allows developers to focus on building applications without having to manage the underlying infrastructure. Over the years, Microsoft has evolved its cloud platform, introducing new capabilities and deployment models to better serve the evolving needs of customers.
One such evolution is the introduction of Azure Cloud Services (extended support), which provides several benefits over the classic deployment model. Cloud Services (extended support) offers regional resiliency, feature parity with the classic model, and integration with Azure Resource Manager (ARM) capabilities like role-based access control (RBAC), tags, and policy.
For customers running their applications on Azure Cloud Services (classic), migrating to the extended support model can be a strategic move to future-proof their deployments and take advantage of the latest Azure platform innovations. This article provides a comprehensive overview of the migration process, highlighting the key differences between the redeploy and in-place migration approaches, and guiding you through the necessary steps to ensure a seamless transition.
Redeploy vs. In-place Migration
Azure offers two primary paths for customers to migrate their Cloud Services (classic) deployments to the extended support model:
-
Redeploy: In this approach, customers deploy a new Cloud Service (extended support) directly in Azure Resource Manager and then delete the old Cloud Service (classic) after thorough validation. This method offers more flexibility, as customers can define resource names, organize resources as preferred, and reuse service configuration and definition files with minimal changes. However, it requires additional time and effort to orchestrate the traffic to the new deployment and delete the old resources.
-
In-place Migration: The platform-supported in-place migration tool enables a seamless, automated migration of existing Cloud Services (classic) deployments to Cloud Services (extended support). This approach is quicker and easier, as the platform handles the migration process, defining resource names, organizing deployments and related resources, and modifying the configuration files for Azure Resource Manager. The migration also retains the IP address, and the data path remains the same, minimizing disruption to your application.
When evaluating your migration strategy, consider factors like the complexity of your application, the need for flexibility in resource organization, and the urgency of the migration. If your application is not evolving rapidly and you’re looking for a quick migration path, the in-place migration approach may be the better choice. Conversely, if your application requires more customization or you need to restructure your resources, the redeploy option may be more suitable.
Migration Steps
Regardless of the approach you choose, the migration process involves the following four key steps:
-
Validate Migration: This step ensures that the migration will not be prevented by common unsupported scenarios, such as the inclusion of certain Azure services or configurations that are not yet supported for migration.
-
Prepare Migration: In this step, the platform duplicates the resource metadata in Azure Resource Manager, locking the resources to ensure synchronization between the classic and extended support deployment models. During this phase, read operations can be performed using both the classic and extended support APIs.
-
Abort Migration: If needed, this step removes the resource metadata from Azure Resource Manager, unlocking the resources for further changes or operations.
-
Commit Migration: This final step removes the resource metadata from the classic deployment, unlocking the resources for the extended support model. After this step, the abort operation is no longer allowed.
By understanding these migration steps and the differences between the redeploy and in-place migration approaches, you can make an informed decision and plan your Cloud Services (classic) to Cloud Services (extended support) migration strategy accordingly.
Supported Resources and Configurations
Azure Cloud Services (extended support) supports a wide range of resources and configurations that are commonly used in the classic deployment model, including:
- Storage Accounts
- Virtual Networks (with the exception of Azure Batch)
- Network Security Groups
- Reserved Public IP Addresses
- Endpoint Access Control Lists
- User-Defined Routes
- Internal Load Balancers
- Certificate migration to Key Vault
- Plugins and Extensions (XML and JSON-based)
- On-Start and On-Stop Tasks
- Accelerated Networking
- Single or multiple role deployments
- Basic Load Balancers
- Input, Instance Input, and Internal Endpoints
- Dynamic Public IP Addresses
- DNS Names
- Network Traffic Rules
It’s important to review the supported scenarios to ensure that your specific deployment configurations are compatible with the migration process.
Getting Started
To begin the migration process, you’ll need to ensure that you have the necessary access and permissions. This involves:
- Signing in to the Azure portal and verifying your role as a co-administrator for the subscription.
- Registering your subscription for the
Microsoft.ClassicInfrastructureMigratenamespace using the Azure portal, PowerShell, or the Azure CLI.
Once you’ve completed the setup, you can proceed with either the redeploy or in-place migration approach, leveraging the available resources and guidance provided in the Next Steps section.
By understanding the migration options, the necessary steps, and the supported resources and configurations, you can confidently plan and execute the migration of your Azure Cloud Services (classic) deployments to the Cloud Services (extended support) model, ensuring a seamless transition and the continued success of your applications.