- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
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 as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
@pavani_paluri
Thanks a lot, it helped!