SGC upgrade: only default connection/imports gets upgraded

[marcguegueniat]

Hello,

My case here is with SG Azure, but it applies to any SGC.

We currently have 2 connections active for SG Azure: default connection + new one

We are upgrading SG Azure from 1.11.1 to 1.13.0

This upgrades some imports and data sources

Imports and Data Sources from the default connection are getting created/updated.

But imports and Data Sources for the other connection do NOT get created/updated.

For instance, "SG-Azure Kubernetes Cluster" is a new import with v1.13.0

This import/data source gets created for the default connection, not for our second connection.

What is the best practice to have all connections upgraded when upgrading a SGC?

Regards,

[AJ-TechTrek]

Hi @marcguegueniat ,

As per my understanding why It Happens
* When you upgrade an SGC (e.g., from 1.11.1 → 1.13.0), the update set and metadata shipped by ServiceNow only applies to the default connection.
* Additional connections you’ve created manually are not automatically updated, which is why you don’t see new Imports / Data Sources (like SG-Azure Kubernetes Cluster) for those extra connections.

Best Practice to Upgrade Multiple Connections
1. Always upgrade the default connection first
* The upgrade process applies schema, imports, and data sources to the default connection.
* Verify the default connection is working after upgrade.

2. Manually clone/import for additional connections
* After upgrade, review new imports and data sources created for the default connection.
* For each non-default connection, you must:
* Clone the new import set table/data source into the second connection.
* Update the connection alias and credentials to point to the correct subscription/tenant.
* Validate schedules are aligned with the new import.

Example: If SG-Azure Kubernetes Cluster is new in v1.13.0, you will need to clone that import and map it to your secondary connection.


3. Use Connection & Credential Aliases (recommended)
* Always configure your multiple subscriptions via Connection & Credential Aliases, not by duplicating imports.
* This ensures when SGC updates occur, you only have to apply changes once and then extend them via aliases.

4. Leverage ServiceNow Scoped App Upgrade Scripts (if available)
* Some connectors provide post-upgrade scripts to help replicate configs across connections.
* Check the Release Notes / Docs for SG Azure 1.13.0 if replication scripts are provided.

5. Document and Automate
* If you have many secondary connections (multi-subscription Azure, AWS, etc.), create a scripted migration/clone process to copy new imports/data sources from the default connection.
* This reduces manual effort on every upgrade.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

[marcguegueniat]

Replying to myself in case it helps anyone.

Imports and data sources are actually meant to be created for the other connections.

This is done via a fix script.

However, there is a bug with the v1.13 fix script: the SG-Azure Kubernetes Cluster import has been forgotten.

A workarround is the following:

After the install of v1.13:

- Open fix script called "SG-Azure 1.13"

- At line 106, when calling the copyNewDStoAllConnections function: replace the sys_ids , with the sys_id from the SG-Azure Kubernetes Cluster import schedule

- Run the fix script

The Kubernetes import and data sources will get created for the other connections.

You do not need this workarround if you only use the default SG Azure connection.

Regards,