K2 & SharePoint Upgrading & Migration: Your thoughts ?

  • 16 September 2015
  • 2 replies
  • 2 views
T
Badge

Hello Forum,

 

My environment details are:

 

SQL Server 2008 R2
Windows Server 2008 R2
K2 4.6.6 (4.12060.1560.0)
SharePoint Server 2010 enterprise edition with service pack 2

 

The environment contains a bunch of custom solutions (K2 solutions, SharePoint solutions, and InfoPath forms).

 

I aim to upgrade the entire environment and have the latest platforms:

 

SQL Server 2012 with service pack 2 or SQL Server 2014 with service pack 1
Windows Server 2012 R2
K2 4.6.10 (4.12060.1560.0)
SharePoint Server 2013 enterprise edition with service pack 1

 

My questions are:

 

1) Are there any documentations or resources that provide instructions on the upgrade process. I have already gone through: (http://help.k2.com/kb001700), But, I am wondering if there is more?

 

2) Which is better/safer: Option-A or Option-B:

 

Option-A) In the same existing SharePoint 2010 environment, I upgrade K2 4.6.6 to K2 4.6.10, then, Upgrade to SharePoint 2013 ?

 

Option-B) Upgrade to SharePoint 2013, then, I upgrade K2 4.6.6 to K2 4.6.10 ?

 

 

3) How can I handle the existing K2 custom solutions and the InfoPath forms during the K2 and the SharePoint upgrading processes? Any recommendations?

 

My goal is to complete this entire migration successfully, and I would be thankful for your valuable inputs !

Thank you and hope to hear from you !

 

2 replies

M
Badge +3

We did a similar migration last year:

- migrate from SharePoint 2010 to 2013

- upgrade to K2 4.6.8

 

However, we set the new platform up in parallel: the "old" environment was up and running while we set up an entirely new one with new servers.

With this approach you are able to test everything, re-develop and optimize while the users are not affected.

 

At the weekend, we migrated only the data, i.e. SharePoint DBs and K2 DBs.

 

Conclusion:

1. no matter which way you go, you will be confronted with the claims id within InfoPath forms (which is different from the username used before). A lot of post migration tasks were necessary to keep running porocess instances alive. Before the migration, we re-developed all of the InfoPath Forms and Processes to use handle the new claims id, e.g. when automatically populating people picker or querying SMOs.

2. as we are having a quite complex installation  (i.e. K2 backpearl & K2 Connect), there was not standard procedure available for the migration. Consultants from K2 supported us on site (which I would highly recommend).

 

If you will keep the existing K2 Server, the upgrade to 4.6.10 should not be a big deal.

 

HTH

Markus

 

VictoriaD
Badge +9

We migrated from SP2010 to SP2013 and we were also using InfoPath.  I hope it goes better for you than it did for us :)  I can tell you I learned a lot about K2 after that experience!

 

1) Regarding the migration, I think you should look at http://help.k2.com/kb001380
We went as far as to have a call with K2 for guidance on a best approach for our needs but it still blew up in our faces.  They gave us guidance of what to try and what to look for, but no assurances.  If you can spare the expense, I recommend consultancy services as well.

 

2) We were advised to update k2 before migrating to SP2013 and I think it's good advice.  The last thing you want to hear is "that was fixed in version so-and-so" when you're trying to fix an issue you encountered during the migration.

 

3) We had active InfoPath workflows when we migrated and after months of trying to salvage them, we ended up having to drop all of them and users had to resubmit.  Our test environment worked great but we later learned k2 encrypts some infopath stuff in their database.  So even though it was our SP2013 test server and even though we found no references to the SP2010 test server in the k2 database, when you opened the form it decrypted on-demand and connected to the SP2010 test server.  All our tests ran swimingly!  Isn't that hilarious?  The only solution they could suggest was something another customer did that I can't recall but we couldn't do it ourselves.  Thankfully we save PDFs of all our forms so our users could just copy & paste their field values to new instances, but it was still a blow to productivity.  There was no way to salvage them without consultancy services.  We sure tried though!  But eventually we just ran out of ideas and had to cut our losses.  Talking to other people after we were told it was generally recommended not to have any active processes running lol

Victoria D'Auria, PMP CSM

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings