Switching Between Classic and Modern Views in SharePoint

Worth a direct correction before anything else: `-EnableContentTypes` doesn’t control list experience at all — it toggles whether a list supports multiple content types, an entirely unrelated setting. A script built around it silently changes the wrong thing while doing nothing to actually switch between classic and modern view, with no error to flag the mismatch. The real parameter is `-ListExperience`. This post also covers a real shift in the classic-experience conversation itself, worth knowing before making a long-term decision based on outdated advice: InfoPath, one of the most common reasons cited for staying on classic, is itself being retired.

In this post: The real PowerShell parameter · Switching via the UI · Finding every classic list across a site · Why “I need classic for InfoPath” no longer holds · What genuinely still needs classic · When would you actually use this? · Related reading

The real PowerShell parameter

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

# Switch to modern
Set-PnPList -Identity "LibraryName" -ListExperience NewExperience

# Switch to classic
Set-PnPList -Identity "LibraryName" -ListExperience ClassicExperience

# Or let SharePoint decide automatically per-device/context
Set-PnPList -Identity "LibraryName" -ListExperience Auto

# Check current setting
(Get-PnPList -Identity "LibraryName" -Includes ListExperienceOptions).ListExperienceOptions

`-Interactive` also replaces `-UseWebLogin` from older examples of this script — that parameter has been removed from `Connect-PnPOnline` entirely, not merely deprecated, so a script still built around it fails to connect at all. For bulk changes across many lists or sites, loop this same `Set-PnPList` call rather than clicking through Advanced Settings on each one individually.

Switching via the UI

Open the list or library, click the gear icon > List settings (or Library settings).
Scroll to Advanced settings.
Under “List experience,” choose New experience, Classic experience, or the tenant/site default.
Save.

This is a per-list/library setting, not a whole-site toggle — one library can run modern while another on the same site stays classic, which is worth knowing when auditing a site that seems to behave inconsistently between its different lists, since the inconsistency is usually intentional history rather than a bug.

Finding every classic list across a site

Before deciding what to migrate, it’s worth knowing what’s actually still on classic rather than assuming based on when a site was created — a site provisioned years ago can easily have some lists already switched to modern individually, and vice versa on a newer site with a legacy library migrated in:

Get-PnPList -Includes ListExperienceOptions | Where-Object {
    $_.ListExperienceOptions -eq "ClassicExperience"
} | Select-Object Title, ListExperienceOptions

Worth running this across every site in scope before a migration project, rather than relying on institutional memory of which lists were set up when — it’s a fast, direct way to get an accurate current inventory instead of an assumed one.

InfoPath Forms Services — one of the most common reasons cited for staying on classic — is itself being retired. “I need InfoPath” is no longer a durable justification for keeping a list on the classic experience.

Why “I need classic for InfoPath” no longer holds

Worth a direct, current correction to advice that used to be reasonable: InfoPath forms and legacy SharePoint 2013 workflows — both commonly cited reasons to keep a list on classic — are themselves being retired by Microsoft, not preserved indefinitely as classic-experience-only features. Staying on classic to keep InfoPath working buys time against one retirement while doing nothing about the other; both need a real migration plan regardless of which list experience is active. Worth treating “we need classic for InfoPath” as a temporary bridge to an actual InfoPath replacement (Power Apps is Microsoft’s own recommended path), not a permanent architectural decision.

What genuinely still needs classic

Datasheet view — genuinely has no modern equivalent; a spreadsheet-style bulk-edit grid still requires classic.
Custom master pages and script-based branding — built for classic rendering, generally don’t translate to modern pages without a rebuild.
Third-party web parts built specifically against the classic page model, where the vendor hasn’t shipped an SPFx equivalent.

Worth checking each of these against its actual current status before assuming permanence — Microsoft’s broader direction is retiring classic-era extensibility piece by piece (the Add-in model and Azure ACS already fully retired as of April 2026, SharePoint 2013 workflows and InfoPath Forms Services on the same trajectory), not maintaining classic indefinitely as a permanent parallel track. None of these three are urgent enough to force an immediate switch on their own, but none of them are a reason to treat classic as a stable, permanent home for a list either.

When would you actually use this?

A list genuinely needs datasheet view for bulk spreadsheet-style editing — one of the few remaining classic-only features without a real modern equivalent.
A site is mid-migration and some lists still depend on classic-only customizations while others are ready for modern — the per-list `-ListExperience` setting handles that transition gradually rather than requiring an all-or-nothing switch.
You’re keeping a list on classic specifically for InfoPath or 2013 workflows — worth treating this as a temporary bridge with an active migration plan, not a stable long-term configuration, given both are being retired regardless of list experience.
No genuine classic-only dependency exists — modern is the current default recommendation, worth switching to rather than leaving on classic out of inertia.

SharePoint Online Modern Script Editor and Its Consequences — the related retirement of script-based classic customization specifically.
Streamlining SharePoint Add-In Installation with PowerShell — the classic Add-in model’s own full retirement, and what replaced it.

The mechanical switch is simple — one parameter, one setting. The harder, more current question is whether the reason for staying on classic is still valid, given how much of what classic-era customization actually depended on is now itself on a retirement timeline. Running the audit script above and checking each result against a real, current justification — not an assumption carried over from whenever the list was first set up — is worth doing before the next retirement deadline forces the question rather than allowing time to plan around it.