A few K2 Five Upgrade questions...

  • 28 August 2018
  • 5 replies
  • 3 views
S
Userlevel 3
Badge +16

Background is we have a Dev and Live Server, both are K2 v4.7 and running on Windows Server 2012 R2 and SQL Server 2016

 

1) For the DEV Server, we are thinking of doing an in-place Upgrade to K2 Five, but which is the correct order that everything should be done in? So for instance we plan to upgrade IN-PLACE the

  1. Operating System to Windows Server 2016
  2. K2 v4.7 to K2 Five

Taking the above into account, which is the correct order to do this upgrade and can you foresee any issues?

 

2) For the LIVE Server, i'm thinking a new fresh server with windows server 2016, sql server 2016, K2 v4.7 and all patches, fixpacks, coldfixes, then migrate forms and data from old server (using package and deployment), and then K2 Five upgrade in-place.

 

My question is...... Can you advise if we should create a NEW K2 Admin account for the new fresh server or use the existing one? - This is a very important question, because when we did the previous upgrade from v4.6.9 to v4.7, we used the existing K2 admin account, but all hell broke loose and all the workflows and forms ended up getting re-submitted because somehow the new K2 server thought the existing and completed forms had never been sent.... So just imagine the chaos this caused us (and there was nothing in the k2 documentation about this either).

 

I never got a straight answer from k2 about why this happened, so please advise whether we should create a new K2 admin account and also more importantly:

HOW DO WE AVOID ALL Migrated Forms and Data being re-sent and potentially thousands of approvals being sent out.

 

Thanks

5 replies

T
Userlevel 5
Badge +13

I do not believe you would need a new admin account. While I can't say for certain what happened with your previous upgrade, in the past I have not had this issue if I made certain that the old K2 server had the blackpearl service stopped and disabled (so it doesn't accidentally start back up) before I install K2 on the new server pointing to the same SQL database. If two blackpearl services are running against the same K2 database at the same time it would certainly cause some unusual behavior.

While this may not be needed, I also go through the K2 database tables looking for references to the old K2 server and eliminate or rename them to the new server. Just to make sure there aren't any lingering links to the old K2 server.

 

T
Badge +10

Personally, I would be a bit more cautious and would make sure that you upgrade the Dev server the same way that you're planning to upgrade the Live server.  That way you hopefully will work out and document all the issues during the Dev upgrade before you attempt Live.  You shouldn't need to redeploy forms or workflows as they exist at the database level and you'd be connecting the new server to the existing K2 database for their respective environments.

 

I also don't think changing the admin account had any affect on the last upgrade problems.  Changing the service accounts could cause access issues but even then I couldn't see it sending out previous completed tasks and such.  Makes me wonder if the K2 database was restored to an earlier date for some reason?  Or if you have a process automatically kicked off based on some external data and that datasource was reset.  Of course, that's pure speculation on my part.

S
Userlevel 3
Badge +16
The way we did the last upgrade was NOT to restore the Database.

We created a new server, installed K2 fresh then used package and deployment (with data) to the new server. Used a new K2 service account, then all of a sudden, every previous form submission started to send out requests for approval.

Thanks for the replies,

Would you consider backing up and restoring the DB to a new server the best option? Or should we do as before and use package and deployment and should we use a new K2 service account or existing?
T
Badge +10

As I'm sure you know without restoring the K2 database you lose all the previous reporting and audit information and any in progress workflows.  Unless there was some big problem with the database that couldn't be fixed by K2 support I can't see why you wouldn't use the same K2 database.  There would be no need to deploy the forms and workflows and the business users could continue working from where they left off.  Most customers I've worked with have been using the same K2 database for 5+ years or more.  If it gets too big you can archive out reporting information (K2 4.7 not K2 5).

 

I would use the same K2 service account unless there is some compelling IT reason not to.

 

Using a new K2 database probably caused the problem that workflows were restarted as I suspect conditions that existed in the old K2 database to determine when a workflow should start no longer existed causing them to start again .  This isn't out of the box behaviour so I speculate that there is some schedule or service that automatically starts the workflows.  It would be good to look into the workflows that restarted and see how they're started so that you can document the conditions.  If its simply users submitting a form then my speculation is wrong.

 

Z
Badge +9

Are you using smartactions? If you're using smartactions, and if it's linked to the K2 Admin account's mailbox, and reusing that K2 Admin account on a new K2 server, everything in the K2 Admin's inbox will be treated as new items on the new K2 server, which will then process everything accordingly and the server replies will proceed to block out the sun and plunge everything into darkness. 


 


That being said, K2 DB migration is a common exercise I see most customers doing when they have new servers and whatnot. Main reason being they don't want to lose previous workflow data and they have existing instances that have yet to be completed. Basically continuity.


 


When done properly, reusing the K2 DB in a new server will have no issues. 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings