Are there any changes to Legacy General Purpose v1 Blob URLs or code that posts new files?

Question

I've been getting warnings about migrating to the new GPv2 platform for quite some time, but I'm confused about the fundamental things we need to do beyond either pushing it over now or waiting for it to be automatically migrated in October.

Specifically, we have code in place that allows users to upload files such as photos, and we refer to those files like this:

https://MyAccount.blob.core.windows.net/Container/Folder1/Folder2/MyFileName.png

We have a lot of content on our web projects that expect to find our files using that URL syntax to place images and any attachments using that URL convention.

So other than potential pricing changes, it comes down to 2 main questions.

1. Do we need to change the code that saves new files to our account? If so, the shift will be a lot more difficult than simply moving the account because it could involve down time as projects are refactored while older code is still active.
2. Will our old URLs still work? This will be extemely difficult for our projects because there are embedded images throughout our proejcts, both desktop and web based.

Answer 1

1. No code changes are required for how blobs are addressed or uploaded when migrating from a general-purpose v1 (GPv1) storage account to a general-purpose v2 (GPv2) account. The upgrade is an in-place change of the account kind in Azure Resource Manager. The storage account name, service endpoints, and container/blob URL patterns remain the same. Existing applications typically continue to work because API endpoints do not change. The main changes are around pricing and available features (tiers, lifecycle management, redundancy options), not the REST API surface or URL format.
2. Existing blob URLs such as: https://MyAccount.blob.core.windows.net/Container/Folder1/Folder2/MyFileName.png continue to work after the upgrade. All blobs, containers, and metadata are preserved, and the upgrade is non-disruptive with no data movement or deletion. The account is simply reclassified as GPv2, so embedded links in web or desktop applications that rely on the current URL convention remain valid.

The main actions to plan are:

• Decide redundancy and default access tier during/after upgrade to control costs.
• Model pricing differences (per-GB and per-operation) and, if needed, introduce lifecycle policies and tiering to optimize spend.

There is no requirement to refactor upload code or rewrite existing blob URLs as part of the GPv1 → GPv2 migration.

---

References:

• About the retirement of general-purpose v1 (GPv1) storage accounts
• Pricing considerations when upgrading to GPv2
• General Purpose v1 (GPv1) storage account retirement FAQ