Data migration from Software instances table to Software installation table

anandsaurabh47
Tera Contributor

We have a custom discovery tool - "Systrack" that is being used to get the software installation detail and is populating the software instance table. Now after enabling SAM Pro, when we run migration to migrate the data in CMDB_SAM_SW_Install. I have below questions:
1. If post migration, Software instances table will get empty as the data will be migrated to software installations table. Or we will have two sets of data in both table.
2. I can see the target table is set as Software instance table in discovery tool mapping, so post migration do we need to change the target table in order to get the future data coming directly to Software installation table.

I am using ServiceNow Xenadu version. Your help will be appreciated.
Thanks

2 ACCEPTED SOLUTIONS

pavani_paluri
Giga Guru

Hi @anandsaurabh47 ,

 

1. Will the Software Instance table be empty after migration?

No, it won’t be emptied automatically.

The migration job copies/maps the data into cmdb_sam_sw_install.

You’ll end up with data in both tables unless you choose to clean up the old cmdb_ci_spkg_instance records.

Out of the box, SAM Pro only uses cmdb_sam_sw_install going forward for compliance calculations.

Best practice: after validating that migration worked, plan a controlled cleanup of old Software Instance records to avoid confusion.

 

2. Do you need to change the target table in your custom tool mappings?

Yes. After migration, you should reconfigure Systrack’s import/mapping so that new data flows directly into cmdb_sam_sw_install instead of cmdb_ci_spkg_instance.

Otherwise, you’ll be constantly dependent on re-running the migration job to move new records, which is inefficient and error-prone.

In your case (Xenadu release), the recommended target is cmdb_sam_sw_install because that’s what SAM Pro consumes.

Additionally, check whether Systrack needs transformation logic (e.g., discovery_source, publisher/product/version normalization) so that the SAM Pro Normalization Engine can process it correctly.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

View solution in original post

Hi @anandsaurabh47 ,

 

That table is part of SAM Pro plugin (Software Asset Management Professional).

Unlike normal CMDB tables, it’s not exposed as a default target in Import Set Transform Maps because ServiceNow protects it. We can load raw discovery/import data into staging (Software Instance / Discovery Model) and let SAM’s normalization engine process it.

So, out of the box, you won’t see it in dropdowns like you do with cmdb_ci_computer or cmdb_ci_spkg_instance

 

ServiceNow provides Import Set Tables and Transform Maps designed for SAM Pro.

Your dev team should be able to load Systrack data into the import staging table (samp_import_sw_install or equivalent).

Use the provided transform maps to move data into cmdb_sam_sw_install.

This way, you stay supported and compatible with the Normalization Engine.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

View solution in original post

4 REPLIES 4

pavani_paluri
Giga Guru

Hi @anandsaurabh47 ,

 

1. Will the Software Instance table be empty after migration?

No, it won’t be emptied automatically.

The migration job copies/maps the data into cmdb_sam_sw_install.

You’ll end up with data in both tables unless you choose to clean up the old cmdb_ci_spkg_instance records.

Out of the box, SAM Pro only uses cmdb_sam_sw_install going forward for compliance calculations.

Best practice: after validating that migration worked, plan a controlled cleanup of old Software Instance records to avoid confusion.

 

2. Do you need to change the target table in your custom tool mappings?

Yes. After migration, you should reconfigure Systrack’s import/mapping so that new data flows directly into cmdb_sam_sw_install instead of cmdb_ci_spkg_instance.

Otherwise, you’ll be constantly dependent on re-running the migration job to move new records, which is inefficient and error-prone.

In your case (Xenadu release), the recommended target is cmdb_sam_sw_install because that’s what SAM Pro consumes.

Additionally, check whether Systrack needs transformation logic (e.g., discovery_source, publisher/product/version normalization) so that the SAM Pro Normalization Engine can process it correctly.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

Hi @pavani_paluri 

 

Thanks for your response.

Having more query. I tried changing the target table to cmdb_sam_sw_install. However, surprisingly; I am not able to find this table in available options hence, unable to select this table. Any idea how can I change this.

Please note that I don't have the development knowledge, but I am working with development team. And, I can share these insights with them so that it can be achieved.

Hi @anandsaurabh47 ,

 

That table is part of SAM Pro plugin (Software Asset Management Professional).

Unlike normal CMDB tables, it’s not exposed as a default target in Import Set Transform Maps because ServiceNow protects it. We can load raw discovery/import data into staging (Software Instance / Discovery Model) and let SAM’s normalization engine process it.

So, out of the box, you won’t see it in dropdowns like you do with cmdb_ci_computer or cmdb_ci_spkg_instance

 

ServiceNow provides Import Set Tables and Transform Maps designed for SAM Pro.

Your dev team should be able to load Systrack data into the import staging table (samp_import_sw_install or equivalent).

Use the provided transform maps to move data into cmdb_sam_sw_install.

This way, you stay supported and compatible with the Normalization Engine.

 

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for
Kind Regards,
Pavani P

anandsaurabh47
Tera Contributor

@pavani_paluri 

Thanks a lot, it helped!