Migration from CA service desk to SCSM 2012 r2


  • Does any one have experience with migrating from CA Service Desk to SCSM 2012 R2?
    How did you accomplish the migration
    Wednesday, July 23, 2014 11:20 AM

All replies

  • This goes for all migrations from service management tool X to SCSM 2012: Avoid trying to migrate cases other than for educational purposes. This is also a good opportunity to clear out old cases. This will make the transition much easier. Then keep both system alive and focus on closing cases in the old system.

    In order to really benefit from the change you should focus on service management processes. Clearly define how you want to work (many IT organizations doesn't really know how they actually do things).

    You sound like you are from Denmark. Try calling the guys at Coretech, they helped Copenhagen Business School migrating from CA (I was involved too).

    Wednesday, July 23, 2014 1:05 PM
  • This is a common misconception about IT Service desk software, and a common reason that most helpdesk and service desk implementation fail miserably; that this something that you can just swap in and out like an email system. A service desk system isn't just a file sharing site that you can forklift your data from and move on like before. Your service desk software is an ERP for IT. Your Service Desk software is somewhere between a model of your IT department and a 5th column manager for your IT staff.

    The typical methodology for doing this type of migration is to construct a straw model of your IT department, specifically your service book and work groups, and review your service book and incident handling procedures. once we have a solid understanding of how your department actually runs at a conceptual and work item level, we can build a model of those work flows into service manager.

    At that point, once we have a functional model of your department constructed in service manager, then we can start moving config item data. For 8 out of 10 implementations, this is better accomplished using a fresh discovery of config items from original sources, which can then be reused to create an update methodology. Provance's DMP (and to a lesser extent, the out of the box connectors, like the CSV connector) is a great tool for this, since it lets you build import templates that can be periodically run to update new data like purchases

    for work items, a Knife edge cutover day is the simplest conversion, but certainly not the only option, that is, you decide January 15th is the day that the new system is available, and all work items go into the old system until January 14th, and the old system will be locked for new requests on the 15th. any work in the old system is worked and closed using the usual process (even after the 15th) until the old system fades into obsolescence over the next 30 or 60 days.

    You might notice that for medium enterprises (5,000 employees or so), this process typically takes several weeks of prep, and a couple of months of implementation, and it scales fairly linearly based on the size of your IT department. small departments (somewhere below 20 analysts) can be done in a month or so, and very large IT groups, this can take a year or more.

    Wednesday, July 23, 2014 1:27 PM
  • So we have an experience in this business.
    I advise you to address
    Wednesday, April 25, 2018 7:24 AM