Moving tickets/records from one HPSM server to another

[mark_wade]

Hi,

Apologies in advance, as I'm a HPSM newbie, so I'm still getting to grips with the terminology.

We have two HPSM servers for differing customers which we are trying merge. One has a small amount of ticket/record data (interaction, incident, change records), as well as the standing data (customer, location etc), so this is the candidate to move to the other server.

Is there a mechanism to move the data, without impacting on the data that currently exists. I was thinking of duplicate ticket/record numbers, for instance.

Any help/guidance would be most welcome :-). Thanks

Mark

[Vadim Gorda]

Hello,

I have not done such thing and cna not even imagine what will be proper approach. Maybe you can rename the unique keys in one of the systems so you wont get duplication?

[anatt170407]

Hello Mark,

Try the below in test environment before moving to prod,

unload the ticket information into and excel spreadsheet including the ticket number. Change the ticket number data to ensure that there is not conflict, go to db and choose "Text Import Wizard" and follow the steps to input the data. Alternatively you ca use Connect-it to integrate the Excel Spreadsheet to the HPSM to created the tickets in SM.

Regards,

Arvind NR

[mark_wade]

Hi Arvind,

Thanks. I'll give that a try and see how it goes 🙂

[tiagoc]

Remember to make sure you don't have duplicate user names in contacts and operators tables.

Also, consider the naming conventions you may have for departments and locations, and it's impact on the "moved" data.

If you change ticket numbers, you will have inconsistences in the related records and activities tables.

Instead of merging the 2 HPSM instances, can't you create the new master-data (locations, departments, users) on the "bigger" instance, and start creating new tickets there? The "smaller" instance would be used to close active tickets (normal use) but creation of new ones would not be possible (restrict the permissions in the operator profiles). Then, when all tickets are closed, just leave it there for history purposes. This would be much simpler and have a lot less risk...

[-m-]

Merging two or more systems is the most complicated thing you can do with Service Manager. Even if you didn't describe yourself as a newbie, I'd recommend getting professional assistance with this endeavor. Service Manager is intended to be tailored and customized. While moving the data records will be difficult, there is a potentially larger issue of managing the different work-flows and solutions designed in each system.

Gathering and organizing the requirements of the merge will help determine which options make the most sense. For example, if the Change Requests from each system are only needed for historical purposes, then an option is to create two separate files (cm3rSystemA and cm3rSystemB). An even better option is to not load them into the new system and simply retain the older databases for reporting purposes.

There will be technical issues when managing customizations from each system. Each customization will have to be analyzed to determine how it works before designing a solution which meets the needs of users and managers from both systems.