# Investigate partial state after a failed Blob immutability migration

> A failed move to version-level immutability can leave blob policies that the portal does not yet display.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-359-investigate-partial-state-after-a-failed-blob-immutability-migration/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:25:57+00:00
- Modified: 2026-09-10T02:01:56+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

A failed move to version-level immutability can leave blob policies that the portal does not yet display.

## Potentially affected

Existing Azure Blob containers being migrated to version-level immutability support.

## DSE recommendation

Inspect migration evidence and prerequisites before retrying; do not infer unchanged state from the portal alone.

## Article

## Source facts

Microsoft warns that a failed migration can leave some blobs with version-level policies not yet visible in the portal. The displayed policy scope remains at container level until migration succeeds. The storage account Activity Log’s Write Migrate operation can establish the migration failure.

The migration requires account-level versioning and an existing container time-based policy. An active lease on the container or any contained blob blocks migration; an existing container-level legal hold is also a blocker. Microsoft describes container migration as irreversible. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope).

## Applicability

Identify the exact container, migration operation and protection configuration. Review current account feature support before planning the migration; this is not advice to remove retention protections.

## DSE recommendation

DSE recommends retaining the failed operation and inspecting prerequisites before another attempt. Investigate leases with their application owners. Escalate any hold-related blocker to the responsible records or legal authority rather than clearing it to make a technical task succeed. Do not promise rollback to the original configuration or treat an unchanged portal label as evidence that every blob is unchanged.

## Verification

In an approved representative test, compare operation status, container scope and selected blob-version properties. Record unresolved inconsistencies and obtain support where state cannot be explained. Close the migration only after the successful result and intended protection state are verified together, without destructive probes against protected production data.

## Official references

[Microsoft Learn: Configure immutability policies for blob versions](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope). Source retrieved September 9, 2026.

## Primary reference

- Name: Configure immutability policies for blob versions - Azure Storage | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Investigate partial state after a failed Blob immutability migration,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-359-investigate-partial-state-after-a-failed-blob-immutability-migration/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.