Successfull migration of 12.9 to 17.1

[Pier Olivier Tremblay]

Congratulations to the SSQ team remy.jobin Steeve_Brou STBO GuillaumeM for the migration of this weekend.

 

We migrated :

 

Service Catalog 12.9 (Win 2008)

   -About 200 service options with several javascript and Java plugins

ServiceDesk-1 12.9 (Win 2008)

   -Complete workflows for incident, request, change and problem management

ServiceDesk-2 12.9 (Win 2008)

   -3 webengines

APM 14.1 (Win 2008)

   -Over 300 legal documents with complete financial workflows and reporting.

PAM-1 4.3.2 (Win 2008)

   -Over 500 workflows running per day. Several integrations to Exchange, PPM, CA Identity Minder, FileMaker.

PAM-2 4.3.2 (Win 2008)

PAM-3 4.3.2 (Win 2008)

EEM 12.51 (Win 2008)

Xtraction 15.1 (Win 2008)

   -Over 300 dashboards. Several scheduled tasks and integration to IP communications system.

MDB (SQL 2008)

 

To :

Service Catalog 17.1 (Win 2016)

ServiceDesk-1 17.1 (Win 2016)

ServiceDesk-2 17.1 (Win 2016)

APM 17.1 (Win 2016)

PAM-1 4.3.2 (Win 2016)

PAM-2 4.3.2 (Win 2016)

PAM-3 4.3.2 (Win 2016)

EEM 12.6.05 (Win 2016)

Xtraction 15.1 (Win 2016)

MDB (SQL 2016)

 

New environnment specs : 36 vCPU and 140 Gig of ram

 

 

 

We used the swingbox method for every product as we had to step on win2012 first due to compatibility issues.

 

 

We started the migration process at 8pm on friday. Everything was up and running saturday morning at 4am.

 

Everything went right on track. Users are using it in prod since saturday PM.

[Paul Coccimiglio]

Congrats on your successful upgrade to 17.1!

Are there any tips/suggestions you care to share with the rest of the community regarding the upgrade process?

[Alexander Perretti]

Pier,

 

Thanks for sharing your success story! Sounds like the new environment is a powerhouse.

[remy.jobin]

We can thank PAM for keeping us awake from 1:00 am to 3:00 am. He really did not want to integrate with his new EEM server: P For the rest, the migration went very well. Only Javascript problems in our forms.

[Raghu Rudraraju]

Thank you for sharing the success story here Pier and congratulations to the SSQ team as well.

 

Glad the swing box approach worked out great for you in this scenario. 

 

_R

[Carol Piccus]

This is great news! Thank you for sharing!

[Aamir Khan]

Welldone Team

[Legacy User]

Well done indeed!  I'd love to read any process documentation that you can share.

Regards,

James

[Grant Bruneau]

Congrats SSQ team! That’s a big accomplishment.  We will be doing a similar upgrade when 17.1.01 is available. Wonder if you can share the PAM/EEM issues that you encountered? Were they due to using the swing box method? We’ll be upgrading the servers/applications in place.

[remy.jobin]

Basically, the problem with PAM and EEM was at the product registration level. As the EEM server was also changed, PAM had to be reconfigured to the new server.

 

The problem was when we did the configuration, when performing the reinstallation PAM do not want to go to the new EEM server because of the certificates. So we tried to erase the certificates in the PAM directory (D: \ CA \ PAM \ server \ c2o \ .c2orepository \ public \ certification) but without success.

 

After several attempts and testing at PAM level. We decided to edit the OasisConfig.properties file.

We had to delete the certificates but also to modify the file (OasisConfig.properties in the directory D: \ CA \ PAM \ server \ c2o \ .config)

 

We erased the values of any element that touched EEM.

-Oasis.security.server.type=
-oasis.policy.type=
-oasis.security.activeDirectory.defaultDomain=
-certificatefolderFullpath=.c2orepository/public/certification/
-oasis.eem.backend.server.location=
-oasis.eem.application.name=
-isFipsMode=
-oasis.eem.certificate.path=
-eiamCertKeyPath=
-oasis.eem.certificate.password=

Once the values in the file were removed, PAM was more cooperative. :)

 

Pier-Olivier and I are consolidating our documentation. We will try to provide the realization steps that we have performed.

But while waiting for the document, do not hesitate to ask your questions. It will be our pleasure to answer our experiences.

 

Thanks

Remy

[Pier Olivier Tremblay]

To add on Remy's answer.

 

No, PAM did not went through the swingbox method. There is chances that your previous running process won't continue to run if you change the Orchestrator.

 

We handled PAM on it's own, two weeks prior to the 17.1 migration with a self-made method that was validated with PAM SE.

 

Basically, for PAM :

 

Cluster with 3 nodes on Win2008.

 

We added 3 new nodes on Win 2016.

 

We removed the 3 first nodes one by one. Deleting the table Properties between each steps. Testing the cluster between each steps.

 

We stopped the cluster. Moved the PAM DBs to a new Win 2016 server.

 

Reconfigured a node to use to new DB and reinstall the 2 others nodes with the PAM GUI.

 

 

So technically, this is the exact same Orchestrator as before but the three original nodes are no more.

 

 

You cannot install a new PAM instance and point it to an old or replicated database. Running process may refuse to resuscitate!

 

 

As Remy said, we will go on with a consolidation of all the steps involved in the migration and publish a document about it.

[Grant Bruneau]

Thank you Pier & Remy for sharing!  I don't think we'll run into these issues since we'l use existing servers.

[Gale_Bacon]

Excellent news - thank you for sharing!  

[SteveLaRocca]

Awesome!  Thank You for sharing your experiences and tips so others may benefit as well

[naira11]

Congratulations for successful implementation .

 

Just curious and want to know whether you were able to follow the Swing box and other migration related content outlined on CA SM DocOps. If you have any recommendations on how we can better our content, we are happy to listen and do the needful. 

 

Regards,

Rajashree

[Pablo Espinar]

Congratulations,

 

may I ask a question? 

 

I have the similar scenario: I have to migrate a CA SDM 12.5 installation to the last version (17.1). The database is currently SQL Server 2008 (remote). The problem is that CA SDM 17.1 only supports SQL Server 2012 or newer. So my question is: what version of SQL server must I install in the SWING box?
As I can see:
- If I install SQL 2008 it will not be supported for 17.1.
- If I install SQL 2012 or newer it will not be supported for 12.5 (initial clone installation), and there would be issues for migrating mdb from a SQL 2008 to SQL 2012 or never.
So what is the right way to perform the swing migration?

[Pier Olivier Tremblay]

I can confirm you that 17.1 works like a charm on SQL 2008. At least during the swing box.

 

I can't say about going in prod with it but as a migration purpose, it did the job.

 

So 12.5 on 2008 -> 17.1 on sql 2008 -> 17.1 on sql 2016.

[Legacy User]

I also found that r17.1 was fine on SQL 2008 on a swing box.

[Jason_Wolfe]

Great news, congrats guys!!