Symptoms
At some point you may run into question of moving existing K2 installation (and database(s)) to a new server(s). Sample scenario may be that you are going to move your entire K2 environment to new servers/hardware. This article outlines the process for such migration.
NOTE: You have to have qualified K2 platform specialist in house working closely with other IT departments (e.g. infrastructure) to perform such complex migration. In case you are lacking internal expertise it is recommended to work with K2 professional services for implementing such changes.
Diagnoses
To move K2 server itself it is much easier to do a clean install from media of all K2 components on your new server. Large portion of your settings as well as workflow related data resides in K2 DB, and connection strings stored in configuration files are being generated/updated by K2 setup manager during installation process.
Additional consideration here are patches/coldfixes (if you have any) you will also need to reapply them (this part is a bit time consuming, as they are mostly installed through manual process).
If you don't have coldfixes, installing K2 components from scratch should be relatively easy:
* If you reusing existing DB large portion of settings will be pulled from it
* If you have cookbook/internal documentation it is easy to click through the wizard filing in correct settings, and if you do not internal documentation it is a good opportunity to create your internal installation document as a part of your preparation process
* If you want to streamline/accelerate setup process even further consider using answer files. See relevant K2 documentation section: Unattended Installations. It is up to you to decide if you want to invest some time in creating answer files or not (keep in mind that some testing will be necessary for you).
Now switching to K2 DB migration part. Assuming you already have deployed processes, reporting data and other things you want to preserve in K2. If answer to this YES, then you have to restore full back up of your K2 DB onto new SQL server instance.
Here is an official K2 KB for your reference which covers your question and possible scenarios: Installing and Upgrading K2 after Database or Server Relocation.
Outline of entire process for you will be the following:
1. Before building/preparing your new servers familiarize yourself with K2 compatibility matrix to ensure that you building fully supported environment.
2. Backup your K2 DB and install folders of K2 servers (second just in case, so that you have config files and other things)
3. Stop all K2 services and change their startup options to "Disabled" or "Manual" and (optionally) shutdown your existing servers. It is really nice to have K2 NLB farm name instead of exposing to your users meaningless (from the user prospective) server name(s), and if you have it you can remap it to IP of new server via DNS A record, after you complete steps below. If you didn't have K2 farm name and used standalone install + server name, again this is a good opportunity to switch to NLB farm name and server farm installation type for you (for farm name you may use something descriptive like "k2.domain.com")
4. Restore your K2 DB onto new SQL server instance, note that K2 DB collation should match with SQL Server instance collation. K2 DB has very specific collation requirement on a SQL server instance level Latin1_General_CI_AS (this requirement comes from the fact that all testing from K2 side is done with this collation, and only this one is officially supported). But in case you have existing K2 DB which was created by K2 installer based on collation of SQL Server instance where installer originally created it you just have to make sure that your new SQL instance has the same collation as one which your K2 DB has.
5. Assign database permissions for K2 Service, K2 Web Service and your K2 installation accounts.
6. After moving your K2 database onto new SQL server you have to reset asymmetric keys on K2 DB restored onto new SQL server as described in this K2 community KB: Database Key error
7. After perfroming steps above you just need to run installation of K2 components on new server(s) in appropriate order (refer to K2 documentation for detailed steps) and on the database connection step target installer to use existing K2 DB on your new SQL Server. If you want extended support during this process or more guidance on this consider contacting K2 professional services with that. K2 Professional Services team has extensive experience in installing K2 environments, as well as in automating K2 installation leveraging answer files etc.
To make sure that configured settings pulled on from the database early in the installation process (and especially if you are using non standard (meaning not "K2") DB name for K2 database before running setup do the following:
1. Browse to [INSTALLDIR]K2 blackpearlSetup
a. Open the Configuration.config file
b. Update the connection string to point to your specific K2 DB name.
2. Browse to [INSTALLDIR]K2 blackpearlK2 SmartForm Setup
a. Open the Configuration.config file
b. Update the connection string to point to K2 DB name
Resolution
See details above which outline process of moving existing K2 installation (and database) to a new server(s).
In case your environment leverages extra databases holding workflow specific data or custom service brokers additional steps may be involved in this process.
Whenever additional support is required for this process it is strongly recommended to work with K2 professional services to handle such migrations.
