How to migrate CSDM data from lower environments to higher environments?

[Ravish Shetty]

Hi all,

We are enabling CSDM and capturing the changes in the lower environment and plan to do a phased release for different applications.

We are trying to prepare a script to capture CSDM related data like Service instance, technology management service, Business service, service offerings, dynamic ci groups, etc. by a given business application.

Did you prepare any similar script or did you directly create these data in production for the first roll out?

Thanks,

Ravish

[Mathew Hillyard]

Hi @Ravish Shetty,

It depends on the nature of the data in the instance.

• If you are creating records in the baseline tables and it's a greenfield site with no existing data to clean up then you can just XML export the data records from Dev to Test to Prod (or whatever your instance stack comprises).
• If you have Service records in the parent Service table but you want to migrate to Business or Technology Management Services (or Technical Services as in CSDM4) in place (i.e. not changing the record) then there is a related link on the Service record that can convert them - capture the code behind it and build a script to migrate the class of the desired records, then move this up the stack.
• If you are migrating from custom tables to CSDM, I'd recommend creating the new CSDM records dynamically via scripting, as some attributes may not exist on the OOTB tables, so you will need a configuration to decide which fields can be mapped and which cannot.
  • In addition, I recommend you create Data Lookup tables as a permanent record of which custom record what migrated to which OOTB CSDM record. This could help also if you need to migrate existing ITSM data (as you have a before and after view).
• If you plan to create Calculated Application Services (and possibly Mapped Application Services too) - these can be moved up the stack but the way they build a service map uses various objects like Service Layer and Manual Endpoint, and I have found this to be a bit of a nightmare to migrate as a large migration can create tens of thousands of objects in an update set. If you're going to use these class of App Services I highly recommend creating the records dynamically with a script in each instance, script adding the first level CI relationships between the App Service and its direct Child CIs to kick off population of the App Service, then clone back soon after to align all the Sys Ids

If you have anything custom, please have a read of this blog I posted on custom migration - it might prove helpful: https://www.servicenow.com/community/developer-blog/csdm-migration-from-custom-service-management/ba...

I hope this helps!

Mat