SharePoint to Purview Retention Migration: The April 2026 Deadline

On April 15, 2026 Microsoft began the sunset of in-place records retention in classic SharePoint. Sites still using site-level retention policies, information management policies (IMP), and the classic Records Center are on a decommission timeline. Purview retention labels are the successor, and they are not a drop-in replacement — the taxonomy, the trigger model, and the enforcement engine are all different.

Enterprises with regulated content that ignore this timeline face two risks. The immediate risk is that retention silently stops enforcing while classic policies are being torn down, and content that should be immutable becomes deletable. The bigger risk is a regulator or litigation event that finds retention broken during the exact window when the enterprise thought it was compliant. We have already been called in twice this year to reconstruct chain-of-custody evidence for organizations that assumed the migration would happen quietly.

This is the migration playbook our team uses for regulated clients — banks, insurers, healthcare systems, and public-sector agencies. It covers what changed in April, the five-step migration path, event-based retention worked examples, regulatory record configuration for SEC 17a-4, HIPAA, SOX ITGC, and GDPR, disposition review workflow, and a 90-day project timeline.

What changed in April 2026

Three things happened in the classic-to-Purview sunset:

• New site collections created after April 15, 2026 cannot have classic site-level retention policies applied. Purview labels only.
• Existing classic retention policies continue to enforce, but Microsoft has begun surfacing decommission warnings in the SharePoint admin center and the Purview compliance portal.
• Information management policies (IMP) on document libraries — the "expiration policy" and "auditing" tabs in library settings — are marked deprecated. Enforcement is still active but new configuration is blocked in most tenants.

There is no published hard end-of-life date for the enforcement engine as of this writing. Based on Microsoft's typical decommission cadence (12-18 months from deprecation announcement) we plan for migration completion by end of Q2 2027 as a safety margin. Regulated clients should target end of Q4 2026.

The five-step migration path

We run migrations in this exact order. Skipping steps is where enterprises get hurt.

Step 1 — Audit existing classic retention

Inventory every classic retention configuration in the tenant. There are four surfaces to check:

| Surface | How to find | What to record |

|---|---|---|

| Site-level retention policies | SharePoint Admin > Policies > Retention (classic) | Policy name, sites in scope, retention duration, trigger event |

| Library-level information management policies | Site Settings > Site Policy (classic) | Library, content type, retention rule |

| Records Center | Central admin site's Records Center | All record routers, hold rules |

| Preservation Hold Library | Site Settings > Site Contents (each site) | Contents held for eDiscovery |

Export the audit to a workbook. In our template each row is one retention rule with columns for legacy config, mapped Purview label, migration owner, and status.

Step 2 — Design the Purview label plan

Purview retention taxonomy is flat and reusable. Do not migrate one-for-one — most classic estates have 40-200 retention policies that collapse to 8-15 well-designed Purview labels.

Our default label taxonomy for regulated enterprises:

| Label | Retention | Trigger | Behavior at end |

|---|---|---|---|

| Public — 3 years | 3 years | Created | Delete |

| Business Record — 7 years | 7 years | Modified | Delete |

| Financial Record — 7 years | 7 years | Fiscal year end | Delete after review |

| Contract — Expiration + 7 years | 7 years | Event: contract expiration | Delete after review |

| Employee File — Termination + 7 years | 7 years | Event: employee termination | Delete after review |

| Regulatory — SEC 17a-4 (6 years) | 6 years | Created | Immutable, no delete |

| Regulatory — HIPAA (6 years from patient last activity) | 6 years | Event: patient last activity | Immutable, no delete |

| Litigation Hold — Indefinite | Indefinite | Manual | Do not delete |

| GDPR — DSAR Response (3 years) | 3 years | Created | Delete after review |

| Personal — 1 year | 1 year | Modified | Delete |

Reference the Microsoft Purview retention policies for SharePoint documentation for the current supported configurations and the Purview retention limits for tenant-wide constraints (10,000 labels max, 1,000 auto-apply policies max — most enterprises use less than 5% of these ceilings).

Step 3 — Publish and simulate

Publish labels in simulation mode first. Simulation applies the labels' targeting rules but does not enforce retention. Run for 30 days minimum. Watch for:

• Auto-apply rules matching content they should not
• Auto-apply rules missing content they should catch
• Label count anomalies (one label capturing 90% of the tenant means the rule is too broad)

Adjust the auto-apply KQL queries and re-simulate until the label distribution matches the audit inventory from Step 1.

Step 4 — Validate and enforce

Move labels to enforce mode by wave. Our default sequencing:

• Wave 1 (day 1) — Non-regulatory labels (Public, Business Record, Personal). Low risk if the label is wrong.
• Wave 2 (day 30) — Regulatory labels (SEC 17a-4, HIPAA, financial records). High risk if the label is wrong — validate every auto-apply rule with legal and compliance before enforcement.
• Wave 3 (day 60) — Event-based labels (Contract, Employee File). These require the event trigger integration to be live first.
• Wave 4 (day 90) — Litigation Hold. Migrated from Preservation Hold Library manually with legal counsel signoff.

Step 5 — Decommission legacy

Only after 30 days of stable Purview enforcement do we turn off the classic policies. Sequence:

• Remove IMP configuration from libraries (library settings > information management policy > remove)
• Delete site-level classic retention policies
• Archive Records Center content (already relabeled as regulatory records in Wave 2)
• Document the retirement in the compliance program

Event-based retention — three worked examples

Event-based retention is the Purview feature that most closely maps to what regulated enterprises actually need. Retention starts when a business event happens, not when the file was created. Three configurations we deploy regularly:

Example 1 — Contract expiration + 7 years

Business rule: Executed contracts must be retained for 7 years after the contract's expiration date, per legal and SOX requirements.

Purview configuration:

• Retention label: "Contract — Expiration + 7 years"
• Retention period: 7 years
• Retention trigger: Event
• Event type: Custom event "Contract Expiration"
• Event source: Contract lifecycle system (via Graph API or Power Automate)

When the contract system marks a contract expired, it fires an event to Purview with the contract's file ID. Purview flips that file's retention clock to "expiration date + 7 years."

Common mistake: No integration between the contract system and Purview. The label is applied but the event never fires, so retention never starts. Files sit labeled but not retained. Test the event fire path before Wave 2 enforcement.

Example 2 — Employee termination + 7 years

Business rule: Employee personnel files must be retained for 7 years after termination, per HR policy and state employment law.

Purview configuration:

• Retention label: "Employee File — Termination + 7 years"
• Retention period: 7 years
• Retention trigger: Event
• Event type: Custom event "Employee Termination"
• Event source: HR system (Workday, SAP SuccessFactors, UKG) via API integration

When HR marks an employee terminated, the HR system POSTs the employee's ID and termination date to a Purview event webhook. Every file in the employee's HR site labeled "Employee File" flips its retention clock.

Common mistake: Labeling by employee AAD identity rather than employee ID. AAD accounts get disabled and deleted; employee IDs persist as immutable references in HR systems. Label by employee ID.

Example 3 — Litigation hold + open matter

Business rule: All files related to an open litigation matter must be preserved indefinitely and cannot be deleted or modified.

Purview configuration:

• Retention label: "Litigation Hold — Indefinite"
• Retention period: Indefinite
• Retention trigger: Manual apply (or auto-apply via keyword rules on matter number)
• Behavior: Do not delete, do not allow modification

When legal opens a matter, they apply the label to relevant sites, libraries, or specific files via the Purview compliance portal. Files are immediately locked. When the matter closes, legal releases the label and files revert to their prior retention.

Common mistake: Applying litigation hold only to one file version. If the hold is applied to the current version but the file is modified after, the pre-modification version must be preserved. Purview handles this correctly only if the label is applied at the item level with the "hold all versions" option enabled.

Regulatory record label configuration

The retention framework has to satisfy specific regulations for regulated industries. Configuration notes for the four regulations we see most often:

SEC 17a-4 (broker-dealers, investment advisors)

• Label: "Regulatory — SEC 17a-4"
• Retention: 6 years for most records, first 2 years easily accessible
• Behavior: Mark as regulatory record — immutable, no deletion or modification permitted
• Compliance: Purview retention labels marked as regulatory records satisfy 17a-4(f) WORM requirements when combined with Purview's compliance boundary

HIPAA (healthcare)

• Label: "Regulatory — HIPAA (6 years from patient last activity)"
• Retention: 6 years from creation or the last activity date (state law may extend — check your jurisdiction)
• Behavior: Event-based on "patient last activity" — requires EHR integration to fire the event when patient records are last touched
• Compliance: Combined with sensitivity labels for PHI and DLP policies for exfiltration prevention

SOX ITGC (public companies)

• Label: "Financial Record — 7 years"
• Retention: 7 years from fiscal year end
• Behavior: Standard retention, disposition review at end
• Compliance: Covers financial reporting workpapers, journal entries, reconciliations, controls testing evidence

GDPR (EU personal data)

• Label: "GDPR — DSAR Response (3 years)"
• Retention: 3 years from creation
• Behavior: Delete after disposition review — GDPR requires justification for retention, so review confirms ongoing purpose
• Compliance: Combined with data subject rights workflows in Purview eDiscovery

Disposition review workflow

Regulatory records cannot just be deleted at the end of retention — someone has to review and approve disposition. Purview supports up to 5 stages of disposition review, each with its own reviewer group.

Our default 3-stage workflow for financial and employee records:

• Stage 1 — Records Manager — confirms the record is eligible for disposition (retention period elapsed, no active litigation hold)
• Stage 2 — Business Owner — confirms no ongoing business need (an M&A due diligence room may extend retention if a deal is pending)
• Stage 3 — Legal — final signoff and disposition execution

Reviewers get email notifications, review in the Purview compliance portal, and can approve, extend retention (with justification), or apply litigation hold. All actions are logged for the compliance audit trail.

Our team helps regulated clients design and deploy Purview label taxonomies, event-based retention integrations, and disposition review workflows. Learn more about our SharePoint consulting service or how we handle document management deployments.

90-day migration timeline

The compressed timeline for regulated enterprises with April 2026 exposure:

| Week | Milestone | Owner |

|---|---|---|

| 1-2 | Audit classic retention (Step 1) | Records Manager + IT |

| 3-4 | Design Purview label taxonomy (Step 2) | Records Manager + Legal + IT |

| 5-6 | Publish labels in simulation mode | IT |

| 7-10 | Simulation observation and rule tuning | IT + Records Manager |

| 11-12 | Wave 1 enforcement (non-regulatory) | IT |

| 13-14 | Event-based integration build (contract, HR) | IT + application owners |

| 15-16 | Wave 2 enforcement (regulatory) | IT + Legal signoff |

| 17-18 | Wave 3 enforcement (event-based) | IT |

| 19-20 | Wave 4 enforcement (litigation hold) | IT + Legal |

| 21-24 | Classic decommission and documentation | IT + Records Manager |

Twelve weeks is aggressive. Fourteen to sixteen is more realistic for a first-time deployment. Add 4 weeks for enterprises with more than 500 classic retention policies to consolidate.

The mistake that guarantees a compliance incident

Skipping simulation. Auto-apply rules that look correct in the design workbook routinely misfire in production because the KQL query catches unexpected content types or misses expected ones. Simulation is where you find out. Enforcement without simulation on a regulatory label is how you end up with 40,000 files incorrectly marked as SEC 17a-4 records that cannot be deleted for six years — or worse, the inverse.

Expert help from our SharePoint consultants

Our team has migrated retention for regulated clients in banking, healthcare, insurance, and government — including a broker-dealer with 2.4M SEC 17a-4 records and a hospital system with 8 years of HIPAA-covered clinical documentation. If you want help scoping the audit, designing the label taxonomy, or building the event-based integrations, book a call with us through our SharePoint consulting service or contact us and we will send back a migration scope and timeline within five business days.