SSISDB catalog schema version remains fixed at 5 regardless of Managed Instance update policy/compatibility level changes

Jim Evans - DBA 0 Reputation points
2026-07-13T12:18:11.47+00:00

We're trying to determine whether the SSISDB catalog schema version can be advanced beyond its current value, and whether it's expected to track our Managed Instance's update policy.

Steps taken:

  1. Original SSISDB catalog reported SCHEMA_VERSION = 5 (via SSISDB.catalog.catalog_properties), with MI on the SQL Server 2022 update policy, compatibility level 150.
  2. Changed the MI update policy to Always-up-to-date.
  3. Raised master, model, msdb, tempdb compatibility levels to 160 (now eligible for 170 given the updated policy).
  4. Dropped the existing SSISDB database.
  5. Stopped and restarted (reconfigured) the existing Azure-SSIS IR, which recreated SSISDB.
  6. New SSISDB still reports SCHEMA_VERSION = 5 — unchanged.

Questions for support:

  1. Is the SSISDB catalog schema version tied to the Azure-SSIS IR service release rather than the Managed Instance's SQL engine/update policy? Can you confirm this?
  2. Is there a newer SSISDB schema version available or planned for Azure-SSIS IR on Managed Instance, and if so, how would we obtain it (new IR release, region rollout, opt-in, etc.)?
  3. Is there any supported, customer-facing method to advance the SSISDB catalog schema version, given check_schema_version/upgrade_catalog procs aren't present?
  4. Are there any known functional implications of running at schema version 5 with an Always-up-to-date/2022-policy engine underneath it?
Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Christos Panagiotidis 81 Reputation points
    2026-07-14T09:22:01.1133333+00:00

    Hi, the SSISDB catalog schema/build number does not necessarily track the SQL Server marketing version, so a value that remains 5 is not by itself evidence that the upgrade failed. Verify the Database Engine version, SSIS service/runtime version, project deployment model, and the catalog's actual upgrade status/errors rather than manually changing catalog metadata. Run the supported SSISDB upgrade workflow for your SQL/SSIS installation if the setup documentation requires it, and test by deploying/executing a package built for the target runtime. Never update SSISDB internal version tables directly. If setup reports success but package execution shows a compatibility mismatch, collect the setup and SSIS catalog logs and open SQL Server support.

    Was this answer helpful?

    0 comments
  2. Alex Burlachenko 24,385 Reputation points MVP Volunteer Moderator
    2026-07-14T08:15:00.2166667+00:00

    hi Jim Evans - DBA & thx for sharing urs issue here at Q&A portal,

    based on what you've described, this looks like expected behavior. The SCHEMA_VERSION of the SSISDB catalog is managed by the Azure-SSIS Integration Runtime implementation, not directly by the SQL engine version or the Managed Instance update policy. Changing the MI to Always-up-to-date, increasing compatibility levels, or recreating the catalog won't by themselves change the SSISDB schema version. The absence of procedures like check_schema_version and upgrade_catalog is also expected in Azure-SSIS IR. Unlike on-premises SQL Server, customers don't manually upgrade the SSISDB catalog in Azure.

    Actually I'm not aware of a newer SSISDB schema version being available for Azure-SSIS IR, nor of any customer-facing mechanism to advance it. If Microsoft introduces a newer catalog schema, it would typically come as part of an Azure-SSIS IR service update rather than through a database upgrade operation. As long as the catalog is functioning correctly, I wouldn't expect SCHEMA_VERSION = 5 to have any negative impact simply because the underlying Managed Instance is running under the Always-up-to-date policy. If the product team has changed this behavior recently or has plans for a newer catalog schema, hopefully they can confirm that, but I believe the catalog version and the SQL engine version are intentionally decoupled :)

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    and at my blog https://ctrlaltdel.blog/

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.