Missing SharePoint Features After an Upgrade: Diagnose Before Removing

A missing SharePoint feature after a farm upgrade is a dependency problem, not a licence to delete every feature whose definition cannot be loaded. Start with a read-only database test, identify the solution that supplied the feature, and decide whether to restore that solution or remove its remaining references.

This article applies to SharePoint Server, including Subscription Edition. It does not apply to SharePoint in Microsoft 365.

What a missing feature means

A site or web can retain a feature activation after the farm no longer has the matching feature definition. This often happens when a content database is attached to a new farm before every custom or third-party solution has been installed.

Microsoft's upgrade troubleshooting guidance says to install a missing dependency when it is still required. If the dependency has been retired, investigate how the affected site, page or component will be rebuilt before removing it.

Do not confuse this with the different Health Analyzer condition where a content database contains sites that are not referenced by the configuration database. Microsoft's orphaned-items article covers that separate problem.

Prerequisites and safety boundary

Before changing anything:

take supported farm and SQL backups and confirm that they can be restored
test against a restored copy or non-production farm first
use the SharePoint Management Shell as an account with the required farm and database permissions
record the database, site URL, feature ID and owning solution
stop if the feature belongs to a product that is still installed or whose data must be preserved

Direct SQL changes to SharePoint databases are not a supported repair method.

Step 1: test the content database

Run Microsoft's read-only database test before writing a removal script:

$webApp = "https://sharepoint.contoso.com"
$database = "WSS_Content_01"

$results = Test-SPContentDatabase -Name $database -WebApplication $webApp
$results |
    Where-Object { $_.Category -eq "MissingFeature" } |
    Select-Object Category, Message, Remedy |
    Format-List

The Test-SPContentDatabase reference documents the supported cmdlet and its permission requirements. Keep the full output, not just the feature GUIDs, because the message and remedy provide context.

Step 2: trace each feature ID

Search your solution inventory, deployment records and vendor documentation for each GUID. Check whether the solution is:

required and missing from the new farm
installed but failing to load
intentionally retired, with its sites already converted
unknown, which means the change is not yet safe

If the feature is required, restore the supported solution at the correct version and rerun the test. Do not install an old binary merely to silence the report without checking compatibility with the target SharePoint version.

Step 3: remove only approved remnants

Uninstall-SPFeature removes a feature definition from the farm. It is not a general cleanup command for unknown activations. Microsoft's cmdlet documentation makes that scope explicit.

If a retired product's own supported cleanup process exists, use it. Otherwise, build a site-by-site remediation plan with the product owner and test it against a restored database. A broad loop that calls Features.Remove(..., $true) across every site collection can remove dependencies from sites you have not inspected.

An “unauthorized operation” error does not prove that publishing-page version history is the cause. It can also reflect the caller's permissions, locks, unsupported object state or product-specific cleanup logic. Capture the ULS correlation ID and investigate it rather than deleting version history on a hunch.

Step 4: prove the repair

Rerun Test-SPContentDatabase and compare the output with your baseline. Then test:

affected site collections and subsites
pages or web parts formerly supplied by the solution
document open, upload and edit paths
search crawl and any dependent workflows
ULS logs during the test

A clean missing-feature result proves that the database test no longer sees that dependency. It does not prove that every customization or business process still works.

Sources

For practical SharePoint Server repair and governance discussions, join the SharePoint & Teams Admins Space.