Absent Member.. Absent Member..
Absent Member..
776 views

Moving tickets/records from one HPSM server to another

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

0 Likes
5 Replies
Fleet Admiral Fleet Admiral
Fleet Admiral

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?

0 Likes
Commander Commander
Commander

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

0 Likes
Absent Member.. Absent Member..
Absent Member..

Hi Arvind,

 

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

0 Likes
Absent Member.. Absent Member..
Absent Member..

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...
0 Likes
Absent Member.
Absent Member.

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.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.