scale up azure app service plan from B1 to P1V3

Question

scale up azure app service plan from B1 to P1V3. will there be no downtime. what problem will occur?. In my app service paln 8 apps are running and only one instance.

Answer 1

There may be brief downtime. Usually it can be up to 1–2 minutes, but ultimately this depends on app size, startup time, and internal complexity. Scaling between SKUs (especially from Basic to Premium v3) is not a simple resize — it's a migration to different infrastructure under the hood (different VM sizes, hardware, network, etc). Azure will move your apps to new hardware behind the scenes. Since you only have one instance, there’s no other instance to serve traffic while the move happens. If you had multiple instances, Azure would drain connections and migrate instances one by one — avoiding downtime.

Regarding potential problems during or after scaling:

Problem	Explanation
Brief downtime / reset	Because you have only 1 instance, clients/users will see brief disconnection, app reset, or HTTP 5xx error temporarily.
Cold start	After move, your app will "restart" cold — if you have a heavy startup (e.g., big dependency loading, EF Core database contexts, etc.), it can delay availability.
Configuration mismatch	Premium v3 supports newer features (VNET integration, private endpoints, newer App Service Environment capabilities). If you had old workarounds or missing settings, some behavior might change.
IP Address Change	If your apps are accessed via outbound IPs and those are hardcoded in firewall rules, your outbound IP addresses might change (check them before and after scaling!).
Pricing	P1v3 is a lot more expensive than B1. You're moving from "budget" to "enterprise" tier — make sure it's intended.

To minimize the possibility of these problems:

• Scale out first, if possible:
  • Temporarily increase your instance count to 2 before scaling up.
  • Then scale up to P1v3.
  • Then scale back down to 1 instance later if needed.
• Plan a maintenance window, announce downtime to users if it's production.
• Warm up your apps after scaling:
  • Enable Always On (only available starting from Standard and Premium plans, not B1) so your apps don't go idle.
• Check outbound IPs before/after if firewall rules are in play.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

HiMohideen Ansari,

There may be a small, minimal downtime during the scale-up process. While the Azure does its best to reduce the obstructions, as your app service plan is running on the single instance, the platform needs to move your apps to a new compute resource (P1V3) and temporarily stop them during that infection.

This downtime is generally brief, but since there is no second instance to handle the load when the infection occurs, your apps may experience a few minutes of unavailability of a few seconds.

Scaling is replaced by the underlying infrastructure, including calculations size, memory, and storage.

Azure will have to rebuild its apps on the new premium V3 hardware.

With only one instance, there is no way to shift traffic or run services while switching.

To avoid downtime, I advise here:

Temporarily scale out (increase instances) to two or more instances before scaling up.

This allows the azure to move the traffic to a healthy instance when upgraded to another.

Then, scale till P1V3.

Once the upgrade is completed, scale back to the instance count if necessary.

This strategy ensures zero or near-zero downtime, especially in the production environment.

You can check the below document which may help you
https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up

if you have any further concerns or queries, please feel free to reach out to us.