CA Service Management

Hello sai,

Sounds like you have a few questions here. Let's go through them. 

I do recommend that you speak to a CA Business Partner or CA Services though, as you'll get better business use out of the new features and avoid some of the pitfalls of upgrading.

1. What are the pre and Post up gradation Steps.

Start with the ITSM 17.1 Upgrade documentation:

Pre-Planning for an Upgrade - CA Service Management - 17.1 - CA Technologies Documentation 

2. What are the common issues faced?

There is no getting around that there is a significant amount of planning that needs to go in to get an upgrade to go smoothly. It is usually cutting corners that causes an issue, such as not checking compatibilities or not scoping the system to handle the new version (it does use more resources). Luckily you're asking some of the right questions here.

In short, check, check and double-check. Make sure that you can upgrade a test environment smoothly as a minimum test.  My personal No.1 tip would be to try this out on a virtual system, that you can quickly restore a snapshot to if needed.

3. Can we follow the swing box approach to upgrade directly from r12.7 to r17.1?

Yes.

* You can upgrade SDM 12.7 to 17.1. See here: 

Upgrading - CA Service Management - 17.1 - CA Technologies Documentation 

* The Swing Box method is documented here:

Use the Swing Box Method to Upgrade to CA SDM 17.1 - CA Service Management - 17.1 - CA Technologies Documentation 

4. As per supportibility matrix mssql 2008 is not supported so what to do and how to upgrade please provide me guidelines step by step

Upgrade the database to a version compatible with ITSM 17.1 first, and then upgrade the ITSM application from SDM 12.7 to ITSM 17.1. Remember, you don't need SDM 12.7 to be running for the upgrade to work (in fact, it can't), so this is why the database can be upgraded first.

* Upgrade the database.

* Upgrade SDM via the Swing Box method.

Current database versions are here:

Supportability Matrix - CA Service Management - 17.1 - CA Technologies Documentation 

Thanks, Kyle_R.

Hi  Kyle_R,

We have gone through all the steps mentioned in the document you have shared earlier. Briefly, I want to describe the way we have selected for migration-

We have done the migration using Swing box method. Our present Production environment is as follows-

OS- Windows Server 2008 r2 and MSSQL 2008 and CASM 12.7

UAT Environment is as follows- OS- Windows Server 2012 r2 Std, MS SQL 2014 and CASM 17.1

First of all, we have created production replication in UAT Server then we have migrated the Database from 2008 to 2014. After migration of database 2014 we have tested all the functionality, it was working fine. But after upgrade CASM 12.7 to 17.1 we are facing some issues. Although Upgration process completed with a successful message. Please help us with proper resolution asap.Please find below error screen shot

After Creation ticket, it is not opening -

Hello sai,

It looks like you have the same question open in another spot, so I'm going to leave it to those threads to continue this, as it looks like we have moved away from the original question in this thread regarding pre and post steps.

I see that removing/reviewing the data partitions has been recommended, and I would start there.

After ticket Creation from Employee ,Employee unable to open tickets 

when user trying to open their won ticket showing error 

Thanks, Kyle_R.

Hi Kyle_R,

Hi,

My problem has been resolved. Thank you all for your support.

Regards,

Sai

Hello sai,

That does not look like the out-of-box r17 employee interface.  I think you have some customised r12 forms in site\mods\www\htmpl.

Examine the contents of site\mods\www\htmpl\web\employee and site\mods\www\htmpl\web\employee\Employee.  If any htmpl files are present, zip them all as backup, delete the htmpl files and either run pdm_webcache or restart the SDM service.  Do the same for site\mods\www\htmpl\web\analyst and the subfolder Analyst. Also look in site\mods\www\htmplweb\\default.  Check site\mods\www\wwwroot as well for javascript and css mods.

Once everything works with the out-of-box forms, use a good file comparison tool (personally I use 'CompareIt!' but you'll have your own preference) to compare each customised htmpl with the equivalent r17 form, from bopcfg\www\htmpl\web\employee, bopcfg\www\htmpl\web\analyst, etc.  Re-apply to the r17 base forms those mods that are clearly customisations.  If you have trouble working out what is a customisation and what is an r12 -> r17 upgrade, compare the out-of-box r12 form from your original r12 host with the customised r12 form and it should become clear.  Once you become familiar with the contents of the forms it isn't usually hard to distinguish between a customisation and an upgrade mod, especially if the customisations have been well commented.

Hope that helps :-)

Regards,

James