September 4th, 2008
With the upcoming release of K2 blackpearl 0807, there are many questions around migrating processes and process instances from K2.net 2003 to K2 blackpearl. There are two central concepts that need to be explained: Migration and Interop.
What is Migration?
Migration is the physical migration of data from K2.net 2003 to K2 blackpearl. This is a server-side, tool that migrates and modifies database records from K2.net 2003 to K2 blackpearl.
Migration is accomplished using the Database Migration Utility scheduled to be released shortly after K2 blackpearl 0807 is released, but is available now in beta form (ver. 2.1) for all current K2 customers.
The migration utility documentation is available with the beta components download on https://portal.k2workflow.com/downloads/beta.aspx. The document can also be found on k2underground.com, at http://www.k2underground.com/files/folders/database_migration_beta/entry25437.aspx.
All process instances, data and security settings are migrated from a K2.net 2003 SP4 system to a clean K2 blackpearl system except for archived data. Custom stored procedures and reports are also not migrated.
What is Interop?
Interop (short for interoperability) is the ability for K2.net 2003 process (.kpr) files to be opened in the K2 Designer for Visual Studio that ships with K2 blackpearl. It is client-side, design-time functionality that allows converted K2.net 2003 and hybrid mixes of K2.net 2003 and blackpearl processes to be deployed to a K2 blackpearl system.
Interop components will be released and supported as part of the K2 blackpearl 0807 release. Please refer to the release notes or contact your K2 regional support after 0807 is released to discuss any technical questions around the interop components. More information about interop can be found in the product documentation and release notes.
The interop components allow all K2.net 2003 wizards to be function alongside the K2 blackpearl wizards in the K2 Designer for Visual Studio. This allows a process to include functionality from both K2.net 2003 and K2 blackpearl in the same file, which can then be deployed to a K2 blackpearl system.
What else do I need to know about Migrating?
If you are planning on migrating your K2.net 2003 processes to K2 blackpearl, there are three important things that you should know. Also take a look at the FAQ section that follows the Decision Matrix.
1. You need a clean installation of K2 blackpearl 0807 as the target system.
2. You need to test your migration first in a QA/Test environment that closely resembles your production environment.
3. You need to have your source K2.net 2003 upgraded to SP4. If you plan to migrate to MOSS as well, it is recommended that you upgrade your K2.net 2003 system to work with the MOSS components before migrating to K2 blackpearl.
Decision Matrix
|
Option Name |
Description |
Pros |
Cons |
|
1 Stay on 2003 |
. Customer continues to use 2003 |
No migration efforts |
· Missing the benefits of K2 blackpearl
· Support for K2.net 2003 will end sooner than blackpearl, most likely when the next version of the K2 platform is released
· K2 blackpearl is the platform of innovation; new features will only be reflected in K2 blackpearl |
|
2. Run Parallel K2 environments |
Run parallel environments keeping 2003 running but also running K2 blackpearl. All existing K2.net 2003 projects would stay on that platform. All new projects would be done on K2 blackpearl. |
No migration efforts |
· Maintenance of two environments
· Possible extra license cost
· Support for K2.net 2003 will end sooner than blackpearl, most likely when the next version of the K2 platform is released
· K2 blackpearl is the platform of innovation; new features will only be reflected in K2 blackpearl |
|
3. Rebuild on blackpearl |
Setup a new K2 blackpearl environment and rebuild all needed processes natively in the K2 blackpearl designers |
· Clean environment, (no remnants of old K2 processes or environment)
· Can immediately take full advantage of new K2 blackpearl features
· No automated code conversion or migration efforts |
· Redevelopment efforts may be significant
· Licensing cost may be prohibitive (double since you will be running two servers)
· Could require you to maintain both environments for an extended period of time to handle the currently active K2.net 2003 processes |
|
4. Process Conversion Only (Interop Only) |
Processes go through the conversion wizard in K2 blackpearl and are deployed to K2 blackpearl. No migration of data or running processes. |
· No migration efforts
· Minimal Time to convert
· Access to new blackpearl design wizards (if desired) |
· No data migration and thus no single point of reporting
· No migration of running processes (in progress)
· Could require you to maintain both environments for an extended period of time (to handle the currently active K2.net 2003 processes)
· This is done on a process by process basis and can take a long time depending on how many processes you have |
|
5. No Process Conversion (Interop Only) |
Deploy K2.net 2003 processes from K2 Studio 2003 directly to K2 blackpearl (0807 with interop required) |
· No migration efforts
· No conversion efforts |
· Missing the benefits of K2 blackpearl
· Processes will be marked as 2003 process and use 2003-style serial numbers
· Historical data is not migrated, which means you will not have a single reporting mechanism for process data
· Won’t migrate K2.net 2003 processes that are in progress
· Would most likely need to maintain both environments for a period of time (to handle the currently active K2.net 2003 processes) |
|
6. Migration |
A customer would run the migration wizard that would migrate all processes and all historical data (but not archived data) |
· All processes data moved to K2 blackpearl
· All active processes are moved and can be completed in K2 blackpearl.
· All completed K2.net 2003 instance data is available in K2 blackpearl reporting
· Only a single K2 environment needs to be maintained
· Has the ability to leverage K2.net 2003 Studio to continue maintaining this process (similar to option # 5) or upgrading the process definition within Visual Studio (similar to option # 4) |
· Depending on amount of data this can take a considerable amount of time (estimated 40 minutes per 1 GB of combined K2.net 2003 data (server and log tables)
· Requires significant testing to confirm migration completed successfully
· Archived data not migrated
|
|
7. Archive and Migration |
Some or all historical data in 2003 is archived first, and then migration is performed as normal. |
· Same as #6 with exception that archived data is not migrated and thus does not appear in blackpearl reporting
· Less time to migrate due to less data |
· Same as # 6
· Archived data not migrated (see FAQ below)
|
FAQS
Here are some frequently asked questions (FAQs) about migration and interop. Please refer to the K2 documentation for more information.
• What are the benefits of migrating my processes to blackpearl?
• Migrating processes allows you to run your existing processes side-by-side with newer processes that you might have planned. All processes will run on the same server, simplifying management, reporting and infrastructure.
• You can take advantage of the non-process features of blackpearl, like reporting, notification events, roles and the K2 Worklist (in Workspace and in SharePoint), as well as run on the latest version of the K2 platform and Microsoft technologies
• You can integrate K2 blackpearl functionality into your K2.net 2003 processes by taking advantage of hybrid design. This should only be done when developing a blackpearl process and functionality is needed that is only available through the K2.net 2003 wizards.
• Do I have to migrate all of my processes at once?
• No, you can choose the processes you want to migrate. However, we do not recommend an incremental approach to migrating existing, deployed processes from K2.net 2003 to blackpearl. The option to migrate single processes is available for testing purposes. When migrating your production environment, you should migrate all of your processes that have current instances running or that you plan to use on the blackpearl server. For testing purposes you are able to rollback each run of the migration utility to restore your K2.net 2003 and K2 blackpearl environments after testing the single migrated process.
• You can use an incremental approach to converting your K2.net 2003 projects (*.kpr) to K2 blackpearl projects (*.kprx). Typically you will need to convert them if you want to have additional blackpearl functionality or you need to make a change to a process after it's migrated. You can still, however, modify the process in K2.net Studio and deploy it to a blackpearl server as long as the blackpearl server is running on port 5252 (the default).
• Can I start a process in K2.net 2003 and finish it in blackpearl?
• Yes.
• Can I keep my K2.net 2003 processes running on my K2.net 2003 server, and install a K2 blackpearl server in my environment?
• Yes, you can have both versions of K2 running in your environment but it is not recommended due to potential licensing costs, port conflicts if running on the K2 blackpearl system on the same server as K2.net 2003, and the integration through Web services with SharePoint and other systems. The recommended approach is to consolidate all processes on a single blackpearl server.
• What doesn't work when deployed K2.net 2003 processes are migrated to a K2 blackpearl server?
• The goal of the backward compatibility features of K2 blackpearl is100% cross-version compatibility. This means that everything, including custom code, should work in K2 blackpearl the same way it did in K2.net 2003. However, destination queues are converted to roles and you may have to add custom assemblies to the GAC on the server running K2 blackpearl. You should always test and confirm that processes run 100% as expected in a test environment before migrating your production environment.
• OOF features in K2.net 2003 will work in K2 blackpearl
• If you are using the SQL user manager (SQLUM) in K2.net 2003 you cannot migrate to K2 blackpearl at this time.
• Can I migrate to an instance of blackpearl that has processes running?
• No. The K2 blackpearl server cannot have any processes deployed or running on it.
• When testing migration, you can make a backup of your clean K2 blackpearl server, migrate a single process to test it, and then restore your K2 blackpearl server to its previously clean state. If you have SmartObjects but no processes deployed to your blackpearl server you can still migrate.
• How do I get to my archived data once I migrate?
• If you need to access K2.net 2003 archived data post-migration, you should not migrate at this time because there is no solution to access this information. This issue and migrating to an existing K2 blackpearl server instance that has processes running are being investigated for a future release of the migration utility.
• How do I get my SQL 2000 databases to SQL 2005?
• If you have a single box installation of K2.net 2003 and SQL 2000 or 2005, you should Detach and Attach, or Backup and Restore, your K2.net 2003 databases to your SQL 2005 installation where your K2 blackpearl databases reside or will be installed.
• What if I’ve modified my K2.net 2003 databases? Can I still migrate?
• No, but it depends on what you’ve modified. If Table and Fields names are the same, you can still migration. However, note that K2 Support may not be able to assist you if you have extensively modified your databases and this will be a billable service.
• Can I go from K2.net 2003/SPS to K2 blackpearl/MOSS at the same time?
• No – we recommend that you go to MOSS first, then K2 blackpearl. Use the K2.net 2003 components for MOSS. More information about migrating to MOSS from SPS can be found on Microsoft's Web site.
• Note that a process cannot start in SPS and finish in MOSS
• K2.net 2003 processes can run against SPS, but new K2 blackpearl processes cannot run against SPS without using the K2.net 2003 SPS wizards
• What versions of K2.net 2003 do you support for a source system migrating to K2 blackpearl?
• Only SP4. You must install K2.net 2003 SP4 before you can perform the migration if you don't currently have it installed
• Can I migrate to a clean installation of K2 blackpearl running on a 64-bit server?
• Migrating to 64-bit is possible but can be complicated and requires additional testing. You may run into issues with referenced assemblies, especially if your K2.net 2003 projects reference non-GAC assemblies.
• Can I migrate from a single K2.net 2003 server to a clustered K2 blackpearl server?
• Yes
• What happens to my K2.net 2003 license after I migrate?
• The server is disabled. Tables renamed and licenses disabled
• At any time you can run the migration utility again and roll back all of the changes. This allows you to test migration and then roll back the changes. Database backups and running the migration in a test environment are still recommended even with this roll back capability.
• Will all of my K2.net 2003 SmartForms continue to work?
• Yes
• If they reference Web services, those Web services must remain running after the migration. If you plan to retire the server on which those Web services are running, you must manually update all Web service references in your forms.
• Will all of my InfoPath forms and SharePoint integration continue to work?
• Yes, but there may be some manual steps to fix connection strings depending on how your InfoPath forms are designed. For example, some data connections are not updated so these have to be manually modified to continue using the same InfoPath forms.
• If you move the K2.net 2003 Web services to a new server so that you can retire the old server, you will have to update the data connections manually.
• If you move your InfoPath forms to a new form library, you will have to update the template.xml manually.
• Are K2.net 2003 code files in the K2.net 2003 project (.kpr) files updated?
• Yes, all code files are updated to C# or VB.NET projects and referenced in the solution.
• Do the old K2.net 2003 Web services have to stay running after migration?
• Yes. If you plan to retire the server on which those Web services are running, you must manually update all Web service references in your forms.
• How would I make a modification to a process after it’s migrated?
• Use the K2 Designer for Visual Studio with the K2.net 2003 Studio wizards installed
• K2.net 2003 studio if K2 blackpearl workflow server remains on port 5252
• Are Destination Queues migrated to blackpearl Roles?
• Yes, during migration destination queues become K2 blackpearl roles.
• Opening a K2.net 2003 project (.kpr) file in the K2 Designer for Visual Studio will also convert any destination queues to K2 blackpearl roles.
• What is the guidance for migrating to a K2 blackpearl environment that has K2 blackpearl instances running?
• If you have a CAL-based license, install another server and keep it clean, then migrate to that server
• Design new versions of your processes in K2 blackpearl
• Open existing K2.net 2003 process (.kpr) files in K2 blackpearl, automatically converting them to K2 blackpearl (.kprx) files, and then deploy to the K2 blackpearl server
• Why can’t you migrate to a K2 blackpearl server that has existing instances? It seems like it should be technically possible? This is a big problem for my company.
• This is a common request – it comes down to unpredictability of process instance data colliding. K2 is looking into the possibility of migrating K2.net 2003 processes to a K2 blackpearl server that has K2 blackpearl processes running, but a clean K2 blackpearl database will probably remain a requirement with the first official (non-beta) release of the migration utility. This brief will be updated to reflect any changes to that plan.