4 Replies Latest reply on Sep 12, 2014 3:08 AM by hewy06

    Replicate ServiceDesk setup for another customer

    Expert

      Hi Guys

       

      Looking for a starting point rather than a full on step by step guide at the min. 

       

      We have an installation of Service Desk that is very mature and well configured to our setup.  We've recently onboarded another customer who are basically the same setup as us but on a different network.  Another Service Desk package (7.7.2 will be getting installed) has been purchased (just before anyone thought I was trying to be really dodgy!!) and now the fun begins.

       

      Customer 2 is going to be adopting our Incident/Problem/Change/Request processes.  We have a number of processes and other cloned modules that they will never be using so I had thought my 2 options are:

      1) Design Transfer - I'm imagining weeks upon weeks of transferring, we have a lot of configuration done in each module and to be truthful this route seems awful!

      2) Doing TTL, so transferring our whole DB and then cleansing the data from it.  2 issues here, firstly they'll end up with all the crap they don't want/need and secondly cleansing the data.  I've found scripts on community re deleting IPCs and we'd need to amend this to include all our requests/knowledge mgmt and then the 2 cloned modules as well, deleting all assests and CIs and deleting all user data.  Is this everything that would need cleansed?  I'm worried about leaving stuff in situ and it throwing up problems down the line.

       

      Just wondering has anyone done this before?  To be honest anything we've implemented previously to this has been done with the assistance of LD but due to financial restrictions I've been asked to look into it.  However, I think my boss would prefer a working instance of ServiceDesk over a hodge podge of one!

       

      Cheers

       

      Helen

        • 1. Re: Replicate ServiceDesk setup for another customer
          ITSMMVPGroup

          Hi Helen.  If you have bought a new LDSD Server and licenses,then you'd be entitled to copy your current database to a new instance and use that.  i.e. option 2. Clear down all the processes, reset the process reference numbers and you'd be good to go as long as the users were still going to be the same.  As you say, the cleardown scripts will need some attention for your user objects and cloned areas, but a diligent and patient administrator can usually battle through.

           

          LD can also provide scripts for clearing down the CMDB, although you may not need to delete the types, just the data.

           

          Personally I'd avoid using design transfer unless you were the person who actually did all the design work and have made good notes.  It is possible to reverse engineer, but it can be hard work.  More so than the cleardown scripts.

           

          You could look at the current shipping empty database as that is much better than it used to be, although it will not have the cloned areas and windows associated.

          1 of 1 people found this helpful
          • 2. Re: Replicate ServiceDesk setup for another customer
            Expert

            Hi David

             

            Thanks for the reply.

             

            The users won't be the same analyst or end users :-(, neither will the company or resolver group setup.  We currently support 10 different departments (companies), the new customer is one department, but they're on a confidential network hence us having to setup a new environment on their domain.  I've done most of the design work or at least have a good handle on pre me stuff that was done but I know if I started design transfer I'd be at it for weeks and that would only be transferring over Incident and Change as a starting point for them.

             

            Looks like it could be a case of taking our DB as it is with all the processes they'll never use and clearing it down then.  Just on a note re the users - will this cause a headache with them being different?  May be best we have another chat with our account manager - unfortunately I wasn't involved in the initial discussions prior to this I'm just being asked to look into implementing it.

             

            Thanks

             

            Helen

            • 3. Re: Replicate ServiceDesk setup for another customer
              ITSMMVPGroup

              Humm I'd certainly find out what discussion were had Helen.  It might even be that the LD account manager offered certain types of help at no extra cost in order to get this deal.

               

              Hard deleting users will be a problem if you are using SQL.  LD has too many referential widgets in it to allow for deletions.  MS have put quite a low number on the maximum allowed and stop the deletion with a 'too complex' error.  Maybe more recent versions of SQL have improved this.  You'll probably have to turn those off to do the deletes and that can be dangerous as you might end up deleting someones record when it is in use.  i.e. you really do need to have those referential checks in place to make sure you are doing safe deletes.

               

              But on the plus side if your manager wants you to do all this rather than pay our friends at LD, you will learn a great deal!

               

              It's a shame T2L doesn't allow you to pick more things you want to sync/don't sync - that would help a lot.

              • 4. Re: Replicate ServiceDesk setup for another customer
                Expert

                I'm hoping our account manager did as well lol, if not I think I'll really be recommending if they want to de-risk the implementation, and this is a big piece of critical work, then we need to involve LD.  Yep I'll certainly learn a lot but as it'll be mostly just me doing then I think the timescales will be getting increased dramatically.

                 

                Agree on your point with T2L, would be lovely to just pick out the relevant stuff as it is they'll just have to suffice with a whole load of extra data configuration that they don't need, but it's the lesser of 2 evils.

                 

                Thanks again for your advice.

                 

                H