Important: When you upgrade the application server, you must also upgrade all of the remote clients that connect to that server to use the same version of Workflow. You can upgrade Workflow without having to uninstall the program.

Upgrade Paths

The following upgrade paths are supported:
  • From Workflow 2.5 with latest SIM to Workflow 2.6
  • From Workflow 2.5 SP1, SP2, SP3, SP4 with latest SIM to Workflow 2.6
  • From Workflow 2.5 Reporting SP1, SP2, SP3, SP4 with latest SIM to Workflow 2.6
  • From Workflow 2.2 SP1, SP2 to Workflow 2.6
  • From Workflow 2.2 SP1, SP2 Reporting to Workflow 2.6 Reporting
  • From Workflow 2.5 to Workflow 2.5 SP1
    Note: All versions of Workflow prior to version 2.5 SP1 must first be upgraded to version 2.5 before you can upgrade to Workflow 2.5 SP1.
  • From Workflow 2.1 to Workflow 2.5
  • From Workflow 2.2 service pack 1 (SP1) to Workflow 2.5
  • From Vision 6.2 to Vision 6.3
    Note: All versions of Vision prior to version 6.3 must be uninstalled before being upgraded to Workflow 2.5 SP1.
  • From Workflow 2.1 to Workflow 2.2 service pack 1 (SP1)
  • From Workflow 2.0 to Workflow 2.2 service pack 1 (SP1)
  • From Workflow 1.5 service pack 4 (SP4) to Workflow 2.2 SP1
    Note: You must first upgrade Workflow 1.5 SP4 to Workflow 2.0.

If you are upgrading from an earlier version of Workflow, contact Technical Support.

Legacy Certificates

Starting with Workflow 2.5, legacy certificates are no longer supported.

Upgrading Extension Servers

If you are installing or upgrading an extension server (Workflow or User), you must have already installed or upgraded an application server of the same version to host the Core services on a separate machine.

Upgrading Microsoft® .NET Framework 4.5 (Full Framework)

Note: Custom display or form assemblies that target earlier versions of .NET will continue to function as before. However, saving changes made to such custom assemblies requires that they be upgraded, which is accomplished in different ways, based on the version of .NET:
  • For an assembly that pre-dates .NET 4.0, you must upgrade the assembly when you open it. Failure to do so results in an error and the inability to save the edited assembly.
  • For an assembly that targets .NET 4.0, the assembly is upgraded automatically when opened, and changes to such assemblies can be saved as before.

Service providers that target versions of the .NET framework before version 4.5 must be recompiled targeting .NET 4.5.

Upgrading Web-based Forms for the Task List

If you have web-based forms as part of an existing workflow that you have created prior to the release of Workflow 2.2 SP1, you must bind them again inside the Form activity in order for them to function in the Task List.
Note: This upgrading issue affects existing web-based forms only, and not HTML5 web forms that are created in Workflow 2.2 SP1.

Upgrading a Clustered Environment

After upgrading Workflow on the primary server machine, you must reconfigure the failover server in the cluster, as well as reconfigure that machine as the primary server in the cluster.

SQL Server Database Replication

When upgrading the application, if you are using a replicated database and have replication turned on, you must turn it off, upgrade, and then turn it on again. You must also upgrade the replicated database. For more information, see Upgrade a Replicated Database.

Password Security

During an upgrade installation, the account lockout capability is automatically enabled; all other password security features are disabled, by default. To enable any of the other password security features, you must use the Configure Security tool after the upgrade installation has successfully completed.

Windows Users

Workflow 2.0 supports Windows domain names with personnel names and login names. If you choose to use the new functionality included with Workflow 2.0 (that is, active directory universal or global groups mapped to Workflow groups), then when your Windows users log in, their personnel name and login name will both be updated to include the domain name, and the personnel name will change to match the login name. For example, the personnel name John Smith and login name johnsmith will both change to <domain name>\johnsmith.
Warning: If you were using Windows user accounts in a prior version of Workflow, any workflows that reference individual users will no longer work! These personnel names will NOT be updated when the Windows users log in. You must manually change these names to include the domain name with a backslash character between the domain name and personnel name. However, if you reference personnel classes in your workflows, no change is required; the workflows will work as they did in the previous version of Workflow.