I don't think there is, without a fair amount of work. There used to be a service that was offered called the factory migration which your support team could find out about. I don't think it's offered any more and was used to take data out of older systems and put into a fresh ServiceDesk.
What you might consider instead is making sure the MDM runs on your new database as that does a good check on the basic integrity. If you have any suspisicions then my own feeling is that you should use your support contract to get those sorted.
I have used Data Import to import incidents before, but by the time you have done notes, assignments, and all the other business objects, you are looking at a decent amount of work. Data Import would also probably get some of the dates etc wrong.
What sort of suspicisons do you have? We have a system that has been upgraded from 7.ancient and while the upgrades have needed some attention from time to time, they have worked.
I agree with Dave here. It's not as simple as dropping your old design and then importing the old Incidents into a clean database. In reality that new database has to have all of the design work in it that supported the creation and execution of the old Incidents, which seems to be defeating the objective you have.
The Migration Factory that he also alludes to is mainly aimed at customers implementing ServiceDesk for the first time, but it is a chargeable service and in reality when people review what they are trying to do, they don't go down that path, rather opting to start from scratch.
From a licensing perspective, if you switch off the old database as far as ongoing transactions are concerned, you can keep the tables and data accesible. You can then use Crystal, or even Query tool maybe to access that data when needed. I guess it depends on what value you see in being able to access them? If it's for information that can be used in future Incident resolution, then why not create some knowledge articles instead?
Thanks guys. I figured the answer would be similar to what you've said. I suspect we'll end up just keeping the existing database.
Keeping knowledge is one reason but not the primary reason to keep our history. Knowing what we've done and being able to trend and report on that data is important for our company, moreso than the knowledge contained within the tickets themselves at this point. But thats probably because up till this point we've not really used KB, heh.
As to my suspicions... they primarily stem from the history of issues I've had to work with in the past. There have been more than one case were the support guys needed the assistance of the development team in order to provide a solution or work around for some of our past database related problems. Some examples are that at one point nothing about an SLA could be modified or deleted (we've since been able to workaround by allowing modify but not delete) and currently we're experiencing an issue that the data import service is creating duplicate entries into a table in the DB which causes the service (and console if attempting to configure) to crash until the offending record is removed from the table. These are just two that come to mind.
Of course we have and will continue to work with support on our issues but it seems to me like we experience a disproportionate amount of not easily resolved issues that involve tinkering under the hood.
It sounds like the data import option would be more trouble and possibly problematic than it's worth...
Thanks again to you both for your input!
Hi Jason - for once I'm going to disagree with Andy. It doesn't happen often though.
I would certainly investigate how much the Migration Factory will cost you to migrate your data into a new database. I did a migration of historical data from Helpdesk, and doing the migration certainly gave me a steep learning curve in how ITBM and the database work!
I'd import all the metadata, ie categories, users, groups etc, and ask the Migration Factory to provide the scripts to auto create your incidents, and the collections you want to keep. And decide what you can "give up", like the audit trail.
In hindsight, I wish I had known more about the product and not used my live production server to "learn" - I now have loads of obsolete objects, relationships, statussus, actions, processes which cause me no end of grief. I'd certainly consider moving everything into a "clean" database.
Keeping the data available in another database, and create a connection to the historical database. Andy - I'm not sure how that will work - I can't see it. You have to create a connection to each table, which is not really going to give you the ability to see an incident as a whole? And if you did map multiple tables, would Console recognised the relationships?