Azure-docs: What is the use of moving of App Service plan if the webspace is not changed?

[blueelvis]

I have 2 App service plans in same resource group within the same region and yet I cannot move the Web Apps from one app service plan to the other because of an arbitrary requirement that Webspaces must be the same.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 25ec88c2-d5ff-e727-cbe1-69bac94141ae
• Version Independent ID: 0b6d31a9-7767-73cb-857b-ad8aa81cdce5
• Content: Manage an App Service plan in Azure
• Content Source: articles/app-service/app-service-plan-manage.md
• Service: app-service
• GitHub Login: @cephalin
• Microsoft Alias: cephalin

[BryanTrach-MSFT]

@blueelvis Thanks for the feedback! We are currently investigating and will update you shortly.

[SyntaxC4]

@stefsch Could you help clarify so we can close this issue?

[mkvalluri]

Had the same issue and I ended up creating new app, migrating configurations. But this should be fixed as it doesn't make sense to have everything in the same location, resource group and still unable to move.

[blueelvis]

@bryantrach-msft @syntaxc4 - I got a confirmation from Azure Support professional that this is not at all supported. Moving of webspaces is not possible which makes "Change App Service plan" to have a serious limitation

[BryanTrach-MSFT]

@blueelvis Yes this is correct. Moving App Service Plans really works best if you are moving your app to a new App Service Plan (ASP). The reason for this is because Microsoft nor the customer has control over what web space is selected when creating an ASP even if you create an ASP in the same region and resource group, there are many webspaces for each datacenter. You will likely have to create multiple ASPs until one aligns with the same webspace as the original ASP.

This is a platform limitation for now. If you wish to leave product feedback, please share it on user voice.

If you are trying to move your web app to an existing ASP, your best option is to use the 'Clone app' blade located within your web app. This feature allows you to create a new ASP or use an existing ASP to copy your site files, app settings, custom domain, and other settings into the desired location.

We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and tag me in your reply. We will gladly continue the discussion.

[fschmied]

@BryanTrach-MSFT You write "Moving App Service Plans really works best if you are moving your app to a new App Service Plan (ASP)." How would this work? Since I can't control the webspace, the new ASP would likely again be in a different webspace?

I just tried creating a new app service plan in the same resource group and location as an existing one, then move my app service from the existing one to that new app service plan. I still can't select that new service plan in the app service under "Change App Service Plan". (I presume this is because of the webspace, but I don't know for sure as I don't know how I can determine the webspace.)

[BryanTrach-MSFT]

@fschmied You can determine your webspace by going to the properties tab of your web app and checking the FTP URL. The below example FTP URL, waws-prod-bay-033, is the webspace name. You'll need to continue trying again until you have an app service plan with the same webspace.

ftp://waws-prod-bay-033.ftp.azurewebsites.windows.net

For this reason, I would personally recommend you look into using the 'clone app' feature if possible.

[blueelvis]

@BryanTrach-MSFT - Thank you for the explanation. I think it would make much more sense to just remove this feature and encourage people to use the "Clone App" feature since this has got severe limitations and we cannot fix it. Don't you agree?

[BryanTrach-MSFT]

@blueelvis No worries, we appreciate your patience on this matter. I would suggest sharing your feedback at this site. The product group is actively monitoring the feedback site for feedback/product improvements.

[michaeldaw]

@BryanTrach-MSFT In this case "actively monitoring" means closing the feedback case related to this issue.

[BryanTrach-MSFT]

@michaeldaw As shared earlier, we highly suggest using the cloning feature. The 'change app service plan' feature has limitations, and in the referenced URL, the product group calls out the limitation.

If your destination app service plan is not in the same web space, your best option is to proceed with the cloning feature. Neither Microsoft nor the end user has control over what web space your App Service Plan is placed into.

[tschleining]

Sorry @BryanTrach-MSFT in advance for the pile on 😉. I think the documentation should be updated with the information from this issue, summarized. It's super confusing as it stands that, maybe-or-maybe-not I can move my Web App. I've submitted another issue with the specifics.

[joelmdev]

The fact that the cloning feature that's being recommended requires a premium app service plan is really adding insult to injury. If that's the route to take over the largely available but crippled "change app service plan" feature, it should be available for lower tiers as well.

[cephalin]

@joelmdev note that you only need to switch into premium for as long as it takes to clone and can immediately scale the plan back down or delete it, and pay minimally for the amount you. And yes, the product team recognizes the limitations of the move plan feature, however we don't have information on when an improvement will come.

Note that any higher tier feature you need can be used in the same way (only scale up for as long as you need it and back down, paying for only minutes).

[joelmdev]

That is actually what we have been doing, but it is a workaround at best
and cloning is not the push button solution that it is made out to be. We
have found that more often than not cloning fails even on simple,
straightforward app services. The error messages are cryptic and have
ultimately required us to purchase a support plan to get through them. An
operation that seems like it should have taken minutes is now spanning
days, and the abstraction benefits of using a cloud platform are lost in a
situation like this. This is all to say that changing service plans (and
cloning) need some attention for them to be useful and usable.

On Wed, Jul 25, 2018, 8:49 AM Cephas Lin [e-mail] wrote:

@joelmdev https://github.com/joelmdev note that you only need to switch
into premium for as long as it takes to clone and can immediately scale the
plan back down or delete it, and pay minimally for the amount you. And yes,
the product team recognizes the limitations of the move plan feature,
however we don't have information on when an improvement will come.

Note that any higher tier feature you need can be used in the same way
(only scale up for as long as you need it and back down, paying for only
minutes).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/7281#issuecomment-407742805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABq9n4gEDXMsCuzOVzlvb_2dBhtNOK0Mks5uKGk8gaJpZM4TYD1t
.

[cephalin]

Really appreciate you taking your time to offer this feedback. Your contribution is invaluable to us and I will make sure the product team sees this.