How do you perform a data dump?

[humblecommitted]

Hello Community,

I was wondering if there was a better way to export the data in a servicenow instance.

I am needing to export data, including relationships, custom variables/variable sets, and subcategories, in preparation to migrate to a new servicenow instance.

I know there is the list and record export to excel and xml, but excel exports does not capture information that is not listed in view and the export of records looks like it is on an individual basis.

Is the only way through xml export and does it capture relationship and other additional data?   Is there a DB export method?

Please let me know if there are other methods and the steps needed to carry them out.

Thank you!

[rishireddy]

Any attachments on the records would get stored in sys_attachement table in back-end with correlation sys_id's.Make sure to include this table and its corelated table while doing the cloning.

You might find the below link helpful to better understand the cloning procdure

What is Cloning, How it Works & Best Practices

Please mark as correct or helpful if this made any impact!!!

Regards,

Rishi Reddy

[vant]

I'm sure you already saw this wiki article regarding various methods of data export.

Exporting in generally only exports the target table, and not any related relationships, so you will need to figure that out yourself for whatever you are exporting. If you are exporting Incidents, for example, you'll need to export potentially CIs, Groups, Users, Locations, etc.

If your goal is to put the data in a new ServiceNow instance, I would first ensure, which might already have been done, that all the source data is cleaned, and you're only exporting exactly what you need (and not carry over whatever is the reason you are moving to a new instance), to leave that bad practice behind to keep the new instance clean. Also if there are any custom fields on your source table being exported, those fields may need to be created or exist in the exact dictionary name in the target instance before importing with the XML method. And because the number of columns on the task table, and extended tables can get very large very fast, be careful how much you export/import at once.

I believe an XML export will automatically capture all related columns on a list view of records, but the file will get large very fast. This is the most complete export method for a source table, but you will also need to export related tables as mentioned in the example above.

Cloning is another option, but once again, if there is a reason you are leaving the old instance behind, do you want to carry that to the new instance?

I hope this helps, good luck!

[humblecommitted]

hello van,

yes i did see that wiki multiple time as i ventured google, and this community, for a solution.

i am currently exporting xml because of the related records that need to be captured.   everything you mentioned was things that i have considered and it seems to be a nightmare!   definitely seems like its going to be a process when it comes to validating custom fields, related columns, and associated records... but the situation is, we use to manage a client's servicenow instance and now they are purchasing and overseeing their own and would like us to transfer all their records to it.

[vant · Accepted solution]

Oh, I see the situation. Not easy like you said, but I would do it very methodically as follows, which may need to be practiced a few times as I have never done this on a large scale.

Starting from the lowest level of table data that does not have any reference to other tables, export it as XML and move it to the target instance after making sure all custom fields exist.

For example, export Choice list table that touches all the table you want to transfer. (ie choice list for Incident, like priority, resolution code, etc)

Then look at dictionary and pick out all the reference tables that are touched from the table you want to transfer. (i.e. CMDB, location, assignment group, user, etc)

Export those reference tables as XML after making sure all custom fields exist and import it to target.

Then go up to the main table you wanted to transfer in the first place, export that and transfer it to the target after all custom fields are created. (i.e. Incident, change, etc).

You may also want to consider exporting any custom update sets that have been created, and transfer those first to the target instance also.

And i think also important is a list of Requirements from the customer, that says Incident should have these minimal items, and they should do validation that you got what they expected, and sign off that the transfer is successful so they dont come back later and say you didn't do this or that, especially when they signed off saying you did transfer everything.

You can also ask Hi to see what other customers have done in regards to this situation, they may provide a service to does something like this 'automagically'.

This is the task you were made for. Go forth and good luck.

[humblecommitted]

van,

very detailed and well explained.   you confirmed all the things i thought would need to be executed.

I did do a test from our prod to dev instances.   i exported an xml of a user, with custom fields and attachments, that was in prod and imported it to dev.

dev did not have a custom variables, that i created in prod, for testing purposes.

the result:

1. attachment carried over (since it was existing in both instances)
2. data from custom fields did not carry over, even after i created the same fields that were in prod AFTER the import, in dev.
3. once i created the same fields in dev, re-ran the xml import, the information was captured and upload to dev.

another way is the client could maybe spend time reviewing the xml record to see all the custom variable names as well, and they can do the work for filling in the gaps >:) but that would just be evil.

Thanks again for taking the time to thoroughly explain and write all this out!