What’s the issue?
Every SQL Server database has a compatibility level that controls which version of the query optimizer and which T-SQL behaviors apply. This includes the system databases (master, model, msdb, and tempdb), which are expected to run at the compatibility level matching the installed SQL Server version.
When SQL Server is upgraded in place, the system databases are normally updated to the new compatibility level as part of the upgrade process. A system database left at a lower compatibility level indicates the upgrade did not complete that step, or that the level was changed manually at some point.
This finding identifies instances where one or more system databases have a compatibility level below the level associated with the installed SQL Server version, detected by comparing the compatibility_level column in sys.databases against the instance version.
Why is this a problem?
System databases running below the installed compatibility level can produce unexpected errors. SQL Server’s internal code, system stored procedures, and management tooling are written for the current version’s behavior, and a system database running under older semantics can behave in ways that this code does not anticipate.
The msdb database is particularly sensitive, since it holds the objects supporting SQL Server Agent, Database Mail, backup history, maintenance plans, and Policy-Based Management. Features that depend on these objects can fail in ways that are difficult to trace back to a compatibility level mismatch, since the error messages typically describe the immediate failure rather than the underlying cause.
Because the condition rarely produces obvious symptoms immediately after an upgrade, it can persist for a long time before surfacing. The instance functions normally for most operations, and the mismatch only becomes visible when a specific feature or code path encounters the difference in behavior.
What should you do about this?
Identify affected system databases by querying sys.databases for the system databases and comparing the compatibility_level value against the level expected for the installed version. Confirm the instance version with SELECT SERVERPROPERTY('ProductMajorVersion'); to establish the correct target.
Raise the compatibility level using ALTER DATABASE [DatabaseName] SET COMPATIBILITY_LEVEL = <NewLevel>; for each affected system database. The change takes effect immediately and does not require a SQL Server service restart.
Review the rest of the post-upgrade checklist at the same time, since a system database left at an older compatibility level often indicates that other post-upgrade steps were also missed.