Azure Subscription Migration to CSP

[アーティクル]
08/26/2016

This blog post is outdated and won't be updated. Instead, review the official Azure EA to CSP and PAYG to CSP migration guides in Azure CSP Documentation.

I receive a lot of requests regarding traditional Azure subscription migration to CSP model. I see that CSP becomes more and more popular, and a lot of customers prefer CSP against EA/Pay-as-you-go because of its great benefits. It is easy to start using Azure in CSP if you haven't used Azure before - you deploy the solution from scratch, using latest and greatest Azure services. But what should you do, if you already have a production environment in Azure, purchased via Pay-as-you-go or Open License, but you want to have more payment flexibility and local partner support? In this case you'll definitely want to migrate your existing Azure subscription to CSP with a minimal service downtime. In this post I'll show you how you can do that.

Main idea of this post: It's impossible to just convert Traditional Azure Subscription or Azure EA Subscription to CSP, because these types of subscriptions are different. There is no simple "switch". You need to move resources from source subscription (Traditional or EA) to destination subscription (CSP). This is a manual process, and this blog will help you to get through.

UPD: In December 2016 Microsoft Center of Excellence team prepared a great set of materials called "Azure EA/Direct to CSP Migration Accelerator". It includes slide decks, migration guides and ready-to-use scripts. You can download it here. Also MigAz tool now supports ASM to ARM, ARM to ARM and AWS to ARM migration scenarios.

Current types of Azure Subscriptions

There are several types of Azure subscriptions, that customers can use:

Traditional Azure subscriptions
- Azure Direct - when customer creates an account on Azure.com and adds his credit/debit card to Azure account. He can be charged in the next month based on the amount of Azure consumed services (Pay-as-you-go), or he can pre-pay for 12 months (12-month prepay offer). Also it is possible to receive an invoice from Microsoft and pay it directly. It is called "Azure Direct" because customer pays directly to Microsoft, partner is not involved in payment process.
- Free Trial on Azure.com
- BizSpark - Microsoft 2-year or 3-year grant for startups
- Open License - customer purchases Azure credits from a Microsoft reseller and activates them on Azure portal.
- Azure benefits for MPN members and Visual Studio subscribers (aka "MSDN subscriptions")
Azure EA Subscriptions - addition of 3-year Azure monetary commitment to existing Enterprise Agreement or a separate Enterprise Agreement for Azure only ("SCE")
Azure CSP subscriptions.

Traditional Azure subscriptions and Azure EA subscriptions are pretty similar:

There are 2 management portals available - old and new.
Both ASM and ARM services are available (if you don't know what is ASM and ARM - read here). ARM services are available on new Azure Portal only, while ASM services are available on both portals, they are called "Classic" on new Azure Portal. ASM-based IaaS is usually called "IaaSv1", and ARM-based IaaS is called "IaaSv2".
Customer has Owner rights in subscriptions (aka "Service administrator" in ASM)
Technical support is provided by Microsoft
Billing and pricing details are provided by Microsoft
Customers can deploy 3rd party solutions from Azure Marketplace - without 3rd party license (Bring-your-own-license model aka "BYOL") or with 3rd party license included (Pay-as-you-go model aka "PAYG"). But anyway - 3rd party license will be charged separately, customers can use Azure Monetary Commitment in EA or Open License Azure Credits to cover 3rd party license.

But there are several differences between Traditional Azure subscriptions and Azure EA subscriptions:

Billing and payment information for Traditional Azure subscriptions is available on Azure Account Center. Azure EA customers use Azure EA Portal instead.
Traditional Azure subscription is tied to Microsoft Account (aka "LiveID"). It means that customer uses his/her Microsoft Account credentials to login to Azure management portal, his personal credit card is used for billing etc. Azure EA subscription is tied to Azure Active Directory. It means that a designated EA manager creates an Azure subscription on Azure EA Portal and assigns owner rights to the specified user account in Azure AD.

And 2nd thing is very important. There is a term called Azure Tenant (also called "Directory" on the new Azure portal). Every Azure subscription exists inside Azure tenant. Azure tenant is a domain like *.onmicrosoft.com, to which Azure subscription belongs:

For Traditional Azure subscriptions, which are tied to Microsoft Accounts, Azure tenant is generated automatically. For example, if your Microsoft Account (LiveID) is johnsmith@outlook.com, then your Azure Tenant will probably be johnsmithoutlook.onmicrosoft.com. If you use your personal domain name for Microsoft Account, then it will also work - if your Microsoft Account is kotlyarenko1111@gmail.com, then Azure Tenant kotlyarenko1111gmail.onmicrosoft.com will be generated.
For Azure EA Subscriptions, Azure Tenant name is equal to company's Azure Active Directory. E.g. my organization is called Kotlyarenko LLC and it is tied to kotlyarenko.onmicrosoft.com Azure AD (which can be connected to On-Premise AD as I've shown here). In this case Azure EA subscriptions will be created inside kotlyarenko.onmicrosoft.com Azure Tenant. It looks similar to Office 365, where Office 365 Tenant name is equal to the name of Azure AD.

Here is the example - a user, signed with his Microsoft Account, has Owner rights granted for 2 different subscriptions in 2 different tenants - kotlyarenko1111gmail.onmicrosoft.com (Microsoft Account-based Azure Tenant) and kotlyarenko.onmicrosoft.com (Azure AD-based Azure Tenant). But to work with these 2 subscriptions, he needs to switch between "Directories" on the Azure Portal.

Traditional Azure Subscriptions can be moved between tenants, now it became pretty easy and you don't even need to create a support request anymore. So the customer can move his/her Azure Direct subscription from Azure Tenant, tied to Microsoft Account, to corporate Azure Active Directory. In this case Traditional Azure Subscription and Azure EA Subscription will live inside the same Azure Tenant. I'll show you why it is so important later in this post.

Difference of Azure CSP Subscriptions

To understand the nuances of Azure subscription migration to CSP, you need to understand what is the difference of Azure CSP Subscriptions comparing to Traditional Azure subscriptions and Azure EA subscriptions:

Only ARM services available - latest and greatest. No legacy ASM or "Classic" services, no "IaaSv1".
Not all ARM services, available in Traditional/EA Azure subscriptions are available in CSP. But almost all of them.
Since there are no ASM services, there is no need in old Azure Portal
Since CSP partner is responsible for billing and pricing, customer doesn't have access to Azure Account Center or Billing menu on new Azure Portal. Customer should use billing tools, that CSP partner provides.
CSP Partner is always an Owner of Azure CSP Subscription. Partner administrators can assign Owner rights to customer IT admins, but customer is not able to revoke Owner rights from Partner. I've described how it works here.
Technical support is provided by CSP Partner. So if a customer will create an incident request for Azure CSP Subscription though Microsoft support channel, then he/she will receive an answer that "Microsoft doesn't support CSP subscriptions, go to your CSP Partner and create an incident request there".
CSP Subscription lives inside Azure Tenant, tied to Azure AD. It can be new Customer, createdon Partner Center portal (new Azure AD will be created) or it can be existing Customer (with existing Azure AD), connected to Partner Center account.
Currently there are only BYOL 3rd party solutions in Azure Marketplace. If customer wishes to buy a 3rd party solution license with Azure services, purchased through CSP, then CSP partner can sell this license separately or include it in the service cost. E.g. partner can add a license subscription to BYOL Barracuda Firewall or Citrix NetScaler, which will be separate from Azure CSP bill.
MySQL-as-a-Service is not available in Azure CSP. It's available in Traditional Azure Subscriptions as a 3rd party service, provided by ClearDB. But you can use MySQL in-app service, that was announced recently. It is already available in CSP if you use a special Web App template, or if you create a Web App and then enable MySQL in App in Properties menu.

Azure CSP Migration Scenarios

OK, now you know what are the differences of Traditional Azure subscriptions, Azure EA subscriptions and Azure CSP subscriptions. These nuances are very important when you plan a migration from a Traditional Azure Subscription or Azure EA to Azure in CSP. Keep in mind that:

It's impossible to just convert Traditional Azure Subscription or Azure EA Subscription to CSP, because these types of subscriptions are different. There is no simple "switch". You need to move resources from source subscription (Traditional or EA) to destination subscription (CSP). This is a manual process. This post will help you to do that.
Since IaaSv1 (ASM-based) is not available in CSP, it is a good opportunity (but also a challenge) to migrate customer from IaaSv1 to IaaSv2. It can cause some service downtime.
Cloud Services and Mobile Services are not available in CSP, because they are not available in ARM. So customer should think about switching to IaaSv2 and Azure App Service first.
Azure Mobile Engagement and Azure Cognitive Services are not available in CSP yet. Very few customers use those services in production, so it won't be a big issue.
If a customer uses PAYG 3rd party Azure Marketplace solutions, then he/she needs to switch to BYOL model and purchase a license for 3rd party solution outside Azure.
Partner should make a migration to CSP by himself, or at least support a customer during this process. Don't leave a customer alone here.

To test the migration process before moving the customer's production workload, I recommend to try it first in a sandbox environment. Partner Center Integration Sandbox is great for that, because it allows every CSP Direct partner (or CSP Indirect distributor) to create up to 25 sandbox customer accounts with up to 25 Azure CSP subscriptions in each. Each Azure CSP subscription in sandbox is limited to $200/month, which means 200*25*25 = $125k of free Azure every month. But be aware - it is impossible to move from Azure CSP sandbox subscription to production subscription, so you will need a regular Azure CSP Subscription on final migration stage.

I will cover 3 most popular migration scenarios from Traditional Azure Subscriptions or Azure EA to Azure CSP Subscription:

IaaSv1 -> IaaSv2 in Azure CSP
IaaSv2 -> IaaSv2 in Azure CSP
PaaS -> PaaS in Azure CSP

Migration from IaaSv1 to IaaSv2 in Azure CSP

This is the most frequent migration request from partners. A lot of customers still use old Azure portal to create VMs. Also there are some customers, that already switched to a new portal, but they use "Classic" deployment model for the purpose of integration with VMs, created on the old portal previously. It means that they still use ASM-based IaaSv1, which is not available in CSP.

Typical situation - customer's EA ends in 3 months, and customer wants to switch to CSP for better flexibility and to get local technical support. Similar story with startups, that joined BizSpark 3 years ago. Now they need to switch to commercial Azure subscription and they select CSP as a preferable option for them. Such companies started to use Azure 2-3 years ago, and IaaSv2 was not available those days (IaaSv2 was launched in 2014 and became a default deployment option in 2015).

To migrate from IaaSv1 to IaaSv2 in CSP, you have 2 options:

Platform-supported: Migrate resources from IaaSv1 to IaaSv2 inside the same subscription using Azure Platform-supported migration. Then you'll need to remove "secrets" dependency and migrate IaaSv2 in source subscription to IaaSv2 in CSP subscription. The whole process is described in details here.
Using MigAz: Using an open source tool, developed by Paulo Ramos (Microsoft Azure guru) - MigAz. That tool will help you to create the similar IaaS environment in ARM and migrate the storage account data to the CSP subscription (or even to a different tenant).

Option #1 don't require a downtime in general, it is fully supported by Microsoft, but it will require 2 steps for migration. Option #2 is not supported by Microsoft (because MigAz is an Open Source tool, supported by community), it will cause a small downtime, but it's a single step migration.

Azure Platform-supported migration is well documented on the Azure site and here, so I won't spend time re-describing this approach. Regarding MigAz migration, what this tool does:

Connects to source environment (IaaSv1)
Get the information about VMs, Networks and Storage and creates ARM Service Template (JSON file)
This ARM Service Template is used to create the copy of the environment in IaaSv2.
After the destination environment (IaaSv2 in CSP) is created, the tool migrates Virtual Disks using snapshots and boots the VMs.

It supports migration from IaaSv1 in one tenant to IaaSv2 in another tenant. Minimal downtime is 30 seconds, maximum downtime depends on the source environment architecture. Keep in mind that:

Understand where the data is written. Depending on the data size, migration can take from 5 minutes to several days, and it is not always possible to sync the data after such long migration. Stateless systems migrate easily. If you use Azure SQL Database or other Azure PaaS to store the data - then it is also OK, because it can be switched to CSP on the next step of the migration, when IaaS will run on ARM.
But if you use SQL Server or MySQL or any other DBMS inside the VM to store the data, and application servers write data frequently to database, then it will be much harder. In this case you can use a different subnet in destination environment (IaaSv2) and configure VNet peering. Now VMs in your source environment and destination environment can reach each other. Copy the stateless VMs, copy the secondary SQL Server to the new environment, wait until the data is synchronized, make this secondary SQL Server primary and then move the remaining SQL Server.
MigAz doesn't require you to shut down the VMs, because it uses snapshots to copy blob data. But if you use multiple data disks to create one big striped volume inside a VM (e.g. Storage Spaces inside Windows Server VMs or LVM in Linux), then it is required to shut down this VM and copy the data to a new environment while the VM is not running.
External IP addresses will change. Consider using Traffic Manager to minimize the downtime because of the external IP address change.
If you need to migrate Block Blob data from ASM-based storage account to new ARM-based storage account, you can use PowerShell cmdlets.
Plan everything, do a test migration to sandbox environment, and only then do a production migration.

OK, let's start the show. My environment runs in Traditional Azure Subscription, and I want to switch it to CSP. This is a 2-tier web portal, that has 2 IIS-based frontends and 2 SQL Server based backends.

2x D1 VMs with Windows Server 2012 R2 with IIS - WEB01 and WEB02. Stateless frontend servers, availability set "WEB". There is a load-balanced HTTPS endpoint - https://cspmigration.kotlyarenko.com. Azure Load Balancer distributes the traffic across these 2 web-servers.
2x A5 VMs with Windows Server 2012 R2 and SQL Server 2016 Standard with AlwaysOn Availability Groups configured - SQL01 and SQL02. All the data from front-ends is written here.
There are 2 Storage Accounts - one for WEB01 and WEB02, another for SQL01 and SQL02.
There is one vNet, all 4 VMs are connected to this vNet.
Web portal is published to the internal using a public URL - https://cspmigration.kotlyarenko.com. This FQDN is a CNAME for Cloud Service name - myapp2408.cloudapp.net, which is resolved to IP 52.178.215.175.
kotlyarenko.com domain is managed via Infobox DNS management panel, SSL certificate for HTTPS is issued by DigiCert.
All VM use 127Gb virtual disks (default size).
Everything runs in North Europe region.

Azure CSP 2-tier OK, let's start.

First of all, create a new Azure CSP subscription on Partner Center portal and save its Subscription ID. I will use my old tenant - kotlyarenko.onmicrosoft.com.As I use Traditional Azure subscription as a source, I use my Microsoft Account to access it. Open Azure administration portal as CSP Partner admin and invite Microsoft Account as an owner of that new CSP subscription. This will allow customer to use the same Microsoft Account to logon to new environment and to old environment.

Now if a customer logins to the new Azure Management portal, he'll see 2 Azure Tenants (directories) - old, generated when we signed up for Traditional Azure subscription, and new - AzureAD-based tenant, created in Partner Center.

I'll switch an old Azure portal to show you how the source environment looks like:

One of the biggest problems during such migration is an external IP address change. If you point the DNS record to a new external IP, it can take hours to replicate the changes. During all this time some end-users will be forwarded to old environment, and some will be forwarded to new environment. To minimize this issue, I'll use Traffic Manager. Go no new Azure CSP Subscription and create a new Traffic Manager profile with Priority routing method:

Go to Configuration and change TTL to 30 seconds. This is a minimal available value. It means that in 30 seconds a client will try to resolve the public DNS name again from Traffic Manager. When we'll complete the migration and switch settings to a new environment on Traffic Manager, in 30 seconds clients will be forwarded there instead of old environment. 30 seconds is much better then many hours. Also don't forget to change Endpoint Monitoring Port, which is HTTPS 443 in my case.

Create a new Endpoint with #1 priority and point it to Cloud Service DNS name in the old environment. In my case it is myapp2408.cloudapp.net. IP address is not supported here.

Then change the external DNS Record, that points end-users to your web portal. In my example end-users use URL https://cspmigration.kotlyarenko.com to get to the web portal. I will change the cspmigration DNS record in kotlyarenko.com domain and specify the traffic manager FQDN (asm2armtest.trafficmanager.net) as CNAME instead of old A-record. Traffic manager will resolve Cloud Service DNS-name (myapp2408.cloudapp.net), which will be resolved by client machine to external IP address of HTTPSWEB endpoint (52.178.215.175). Wait several hours until these DNS changes will be replicated. When we'll create a new environment, we'll add a second endpoint to Traffic Manager profile, that points clients to IaaSv2 environment instead of old one.

Check that external DNS record is resolved to Traffic Manager FQDN:

nslookup

Then download MigAz and launch it. Sign in to source Azure subscription. You will see IaaSv1 resources, that exist in that subscription. Choose which elements you wish to migrate.

2 files are generated by MigAz - export.json (ARM Service Template) and copyblobdetails.json (configuration file for BlobCopy.ps1 script, that is located in MigAz folder).

Start new Azure PorerShell session, import Azure Resource Manager if you haven't done it yet (run Install-Module AzureRM with elevated rights) and connect to the Azure CSP subscription. Create a new Resource Group.

Login-AzureRmAccount
$TenantID="kotlyarenko.onmicrosoft.com"
$SubscriptionID="07bb8a2b-bb31-6d1f-a49e-5daa0f086ebf"
Select-AzureRmSubscription -SubscriptionID $SubscriptionID -TenantId $TenantID
$ResourceGroupName="CSPRG1"
$Location = "North Europe"
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $Location

Start the Resource Manager service deployment. It should fail with an error - that's OK. That's because VM disks were not copied yet from the source environment. But the script will create the whole environment in ARM, similar to old ASM environment.

New-AzureRmResourceGroupDeployment -Name "DeploymentCSP" -ResourceGroupName $ResourceGroupName -TemplateFile "C:\CSP\export.json" -Verbose

To avoid losing the data in SQL Database during the migration, I will switch the database to Read-only mode. It means that until I will finish the migration, my solution will be available to end-users in Read-only mode.

Initiate a copy of Virtual Machine disks from the source Storage Account to the destination Storage Account. Wait until it finishes. In my case 4 127Gb VM disks were copied in 3 minutes.

.\BlobCopy.ps1 -ResourcegroupName $ResourceGroupName -DetailsFilePath "C:\CSP\copyblobdetails.json" -StartType StartBlobCopy
.\BlobCopy.ps1 -ResourcegroupName $ResourceGroupName -DetailsFilePath "C:\CSP\copyblobdetails.json" -StartType MonitorBlobCopy

Then re-initiate Resource Manager deployment from a JSON template. Now it should complete without any errors.

New-AzureRmResourceGroupDeployment -Name "DeploymentCSP" -ResourceGroupName $ResourceGroupName -TemplateFile " C:\CSP\export.json " -Verbose

Go to new Azure portal. Miracle - you'll see the environment, similar to the old one, but in ARM model. All the VMs should already be online and running.

But as you see - the external IP address is new - 52.169.226.32.

Go back to Traffic Manager Endpoints page and create a new endpoint, that will point end-users to the Load Balancer external IP, tied to WEB availability set:

When you will disable Old endpoint, all end-users will be pointed to the new one during next 30 seconds:

Switch SQL Server in the new environment to Read-Write mode. Check that everything works fine. If there are no issues in the new Azure CSP environment, then change the external DNS record. Point it using a CNAME to a FrontEnd Load Balancer FQDN in the environment instead of Traffic Manager FQDN. Done!

In this case, customer still will use his/her Microsoft Account to access Azure CSP Subscription. But if it is a large organization, switching to Azure AD accounts, integrated with On-Premise AD, is more suitable. Migration from Azure EA Subscription will look exactly the same, except that you will need to use Azure AD account instead of Microsoft Account to access the old subscription.

As you saw, the web portal was available to end-users all the time, but during several minutes it was available Read-Only. If it is not acceptable for the customer, you can use a migration method with 2 different subnets, vNet Peering and data replication on SQL Server (MySQL, PostgreSQL etc) database level, as I've already described earlier.

Migration from IaaSv2 to IaaSv2 in Azure CSP

Migration from IaaSv2 in Traditional Azure Subscription or Azure EA to IaaSv2 in Azure CSP Subscription is much easier. Generally you only need to move ARM resources from one subscription to another. Main limitation here - subscriptions must exist inside the same tenant.

This is not a problem for Azure EA -> Azure CSP scenario, because I assume that Azure CSP subscription was created inside the already existed tenant, that was used for Azure EA. If you use Request a Reseller Relationship button in Partner Center, you as a CSP Partner will associate Customer tenant ( *.onmicrosoft.com) with your partner account, and Azure subscriptions will be created inside the same tenant.

reseller But if you migrate from Traditional Azure Subscription, which exists inside Microsoft Account based Azure tenant, then you will need to migrate that subscription to Azure AD-based tenant first. Now it became much easier - just go to Azure Account Center, choose the old subscription and click Transfer Subscription. You will need to provide new Azure AD user credentials, and subscription will be moved to Azure AD tenant, which specified Azure AD user belongs to.

I will use similar environment, that I've used in a previous example. The only difference - it already runs on ARM-based IaaSv2. I've created 2 VMs in Azure MSDN Subscription and then transferred that subscription to kotlyarenko.onmicrosoft.com tenant. VMs are called VM01 and VM02, they sit in the same storage account and in the same vNet (I want to show you that network communication between 2 VMs won't drop during the migration). Everything is stored in MyVMs Resource Group in North Europe region.

OK, grant a user account that you will use for migration Owner rights for both subscriptions. Since they sit in the same tenant, you can use both - Microsoft Account or Azure AD Account. Go to the VM that you want to migrate from Traditional Azure Subscription to Azure CSP Subscription. Click Properties and click Change subscription. Select all the resources in the list, then choose Azure CSP subscription from the list and an empty Resource Group in that subscription.

In my case the whole migration to a different Azure subscription took ~5 minutes.

There was no any downtime - VMs were able to communicate with each other for all the time, public IP also was available. Again - 0 downtime.

Clean Resource Group in the old Azure Subscription:

And all IaaSv2 resources live inside new Azure CSP Subscription now, public IP stayed the same:

Currently not all IaaSv2 resources can be moved to another subscription, but this situation changes quickly. Application Gateway and VPN Gateway can't be moved, so you will need to recreate them in the new subscription. Virtual Machine Scale Sets also can't be moved, so you will need to redeploy the scale set definition in the Azure CSP subscription. The easiest way is to export the current resourses as JSON file and deploy them in the new subscription. Choose Resource Group, where this resource lives, click on Last Deployment to get the list of deployment, open the most recent deployment, click View Template and click Deploy. capture_26082016_221531_001 capture_26082016_221607_002

Migration from PaaS to PaaS in Azure CSP

This scenario is very frequent - customer want to migrate PaaS services from Traditional Azure Subscription or Azure EA Subscription to CSP. We've already covered IaaS part, so you should know how to migrate Storage Accounts, Virtual Networks and VMs (which can be used by other PaaS services). The most frequent request is to move Azure App Service (Web Apps) or Azure SQL Database to Azure CSP.

The high-level view of the procedure:

For Traditional Azure Subscriptions: transfer Azure Subscription to Azure AD-based tenant, created in Partner Center
For Azure EA Subscriptions: request a reseller relationship in Partner Center to add an existing customer tenant to CSP partner account
Create a new Azure CSP Subscription in Partner Center
Register the corresponding Resource Providers for the resources that will be moved in this subscription.
Move resources from old subscription to new subscription using the credentials of Azure AD user or Microsoft Account, that has Owner rights in both Azure subscriptions.

There is no resource downtime during such migration. And there is no difference if that Azure service was created in old Azure Portal or in new Azure portal - almost all PaaS services these days use ARM inside. If you create Azure SQL Database or Azure Web App on the old portal, it will be placed inside Resource Group as a resource and will be available on the new portal too.

Here are some limitations:

Remember, that Mobile Engagement and Cognitive Services are not available in CSP yet.
Application Insights doesn't support resource move. Export a resource template (JSON file) and re-deploy it in a new Azure subscription.
Cross-subscription migration for some resources (e.g. Web Apps) is available only through PowerShell and not through Azure Portal.
Migration of the whole Resource Group from one subscription to another is not available - you need to move separate resources.
MySQL-as-a-Service, which is 3rd party service, provided by ClearDB, is not available in CSP. You can use native MySQL in-app instead, but you may need to reconfigure your Web App to use MySQL in App instead of ClearDB service.

Example #1 - Azure App Service

I've created Web App on the old portal in the Traditional Azure Subscription (Azure MSDN Subscription). This is how I see it on old portal and on new portal:

I need to transfer this subscription to kotlyarenko.onmicrosoft.com tenant first. Then I will create a new Azure CSP subscription and run this PowerShell script:

$OldSubscriptionID = "82fcfabd-df0c-4ea6-9d27-2dfe5879778a"
$OldRGName = "Default-Web-NorthEurope" //this is the default RG name if you create Web App on the old portal.
$NewSubscriptionID = "0d8f7263-62cf-49f3-8578-ddde56305e77"
$NewRGName = "CSPResourceGroup"
Select-AzureRmSubscription -SubscriptionID $NewSubscriptionID
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Web //you need to register Microsoft.Web resource provider in the new subscription before moving Web App resources.
Select-AzureRmSubscription -SubscriptionID $OldSubscriptionID
$webapp = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName "App2408"
$plan = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName "Default1"
Move-AzureRmResource -DestinationSubscriptionId $NewSubscriptionID -DestinationResourceGroupName $NewRGName -ResourceId $webapp.ResourceId, $plan.ResourceId

In less then a minute Azure App service was moved to Azure CSP Subscription without any downtime. External URL and IP stayed the same.

Example #2 - Azure SQL Database

I've created Azure SQL server and Azure SQL Database on the old portal in the Traditional Azure Subscription (Azure MSDN Subscription). This is how I see it on old portal and on new portal:

I need to transfer this subscription to kotlyarenko.onmicrosoft.com tenant first. Then I will create a new Azure CSP subscription and run this PowerShell script:

$OldSubscriptionID = "82fcfabd-df0c-4ea6-9d27-2dfe5879778a"
$OldRGName = "Default-SQL-NorthEurope" //this is the default RG name if you create SQL Database on the old portal.
$NewSubscriptionID = "0d8f7263-62cf-49f3-8578-ddde56305e77"
$NewRGName = "CSPResourceGroup"
Select-AzureRmSubscription -SubscriptionID $NewSubscriptionID
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.SQL //you need to register Microsoft.SQL resource provider in the new subscription before moving SQL Database resources.
Select-AzureRmSubscription -SubscriptionID $OldSubscriptionID
$sqlserver = Get-AzureRmResource -ResourceGroupName $OldRGName -ResourceName "xzc647tfiy"
Move-AzureRmResource -DestinationSubscriptionId $NewSubscriptionID -DestinationResourceGroupName $NewRGName -ResourceId $sqlserver.ResourceId

In less then a minute Azure SQL Database was moved to Azure CSP Subscription without any downtime.

Migrate Azure CSP Subscription from one CSP Partner to another CSP Partner

If a customer wants to switch from one CSP Partner to another CSP Partner, there no need to migrate the resources - Azure CSP subscriptions in different partners are very similar, so the customer can just switch the subscription from one partner to another without any service interruption. This guide describes how to submit a move request to the Microsoft technical support and what actions need to be done on the customer and the destination partner sides.