IdentityIQ 8.3 to 8.4 Upgrade: SQL Server 2022 Migration Requiring Schema Change to dbo

Which IIQ version are you inquiring about?

Identityiq Version: Identityiq8.3 p3

Database: Microsoft SQL Server 2016

We are upgrading SailPoint IdentityIQ from version IdentityIQ 8.3 p3 to 8.4. Currently, IdentityIQ 8.3 is running on SQL Server 2016, and since IdentityIQ 8.4 supports SQL Server 2022, we are migrating the database as part of the upgrade.
We restored the IdentityIQ 8.3 p3 database backup to SQL Server 2022. However, after the restore, IdentityIQ is not up and running. As part of the troubleshooting process, we changed the database schema to dbo, after which IdentityIQ started working.
The challenge is that many existing reports, tables, and rules reference the IdentityIQ schema explicitly. If the schema must remain dbo, it will require extensive rework across these artifacts.
Could you please clarify why it is necessary to change the IdentityIQ schema to dbo after restoring the database to SQL Server 2022, and whether there is a supported way to continue using the existing IdentityIQ schema?

Please share any images or screenshots, if relevant.

[Please insert images here, otherwise delete this section]

Please share any other relevant files that may be required (for example, logs).

[Please insert files here, otherwise delete this section]

Share all details about your problem, including any error messages you may have received.

[Replace this text with the problem that you are facing]

@Nara have to tried with ?

ALTER USER [identityiq] WITH LOGIN = [identityiq];
ALTER USER [identityiq] WITH DEFAULT_SCHEMA = [identityiq];

Replace [identityiq] with your actual SQL login and database user names.

The issue occurs because after restoring the database to Microsoft SQL Server 2022, the database user mapping and default schema were not preserved correctly. As a result, the application started resolving objects under the dbo schema instead of the original identityiq schema, which caused IdentityIQ to fail until the schema was changed.

To fix this, we need to correct the database user mapping and explicitly set the default schema back to identityiq:

ALTER USER your_user WITH LOGIN = your_login;
ALTER USER your_user WITH DEFAULT_SCHEMA = identityiq;

This ensures that SailPoint IdentityIQ continues to use the existing schema without requiring any changes to reports, rules, or database objects.

Hi @Nara ,It is an interesting use case, Can you share a screenshot of how the new database looks like? That will help us share our input.

Thanks,

PVR.

@Nara Is your issue resolved? In case yes, could you please share what’s the resolution?