4 Replies Latest reply on Jul 14, 2009 10:20 AM by elizabethcombrink

    Migrate incidents to another database


      Hi all...


      We are excited for the new 7.3 release and it's actually coinciding with some other major changes we have planned for our SD. We've started to brainstorm some of the plans for the project and I wanted to see if this is plausible...


      Build a completely new system/database in version 7.3 and migrate only the incident history from our current database into the new one, ignoring configuration/settings, etc.

      Or build up a clean 7.2 environment, migrate the incidents, then upgrade.


      The idea behind this is that I'd like to start with a completely clean database but retain our incident history. Other config/design doesn't matter that much at this point. The reason for this is because I have reason to question the integrity of our current database as it has been upgraded and modified many times since it's original inception; we are at a point where we are looking at a significant amount of work to redesign it in many ways and it seems like it would be a good time to do this if possible.





        • 1. Re: Migrate incidents to another database
          dmshimself ITSMMVPGroup

          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.

          • 2. Re: Migrate incidents to another database
            aparker Employee

            Hi Jason,


            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?



            • 3. Re: Migrate incidents to another database

              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!



              • 4. Re: Migrate incidents to another database
                elizabethcombrink Expert

                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?