Workflow migration types

This topic provides overview information and best practices to use the following Nintex for Office 365 migration types:

Workflow design

Applies to: Office 365 to Office 365. Workflow architecture and settings only.

Nintex provides a quick and easy workflow design option for users who do not know how to use a text-based coding programs such as SharePoint Designer, Visual Studio or custom code such as .NET.

Once you’ve designed and configured the workflow, you can leverage the design migration method to export the workflow design and logic into an .nwf file. Nintex Workflow can read that file, enabling you to import a copy of that workflow design with basic workflow configuration settings into a new workflow.

The intent for a design migration is to allow a user to rapidly design and configure a workflow, then move the workflow and its configurations from one list, library, or site to another by exporting and importing a single file.

Import and Export options are available in the Toolbar. For more information, see Toolbar.

Best practice

Design migrations are best used to move a single workflow from one list, library, or site to another (for example, test list to production list). This move can occur within the same site, between two different sites, and between the same platform (Office 365 to Office 365).

The workflow file formats for Nintex workflows are different from SharePoint to help users distinguish the difference and retain the necessary components to help the workflow run in the right platform.

If you’re designing and configuring a single or one-off workflow and need to move it from one list to another, you’re performing a design migration. This is a good and efficient practice for getting a workflow design applied to a new list quickly.

Note: This type of migration does not copy and carry over any associated tasks or workflow history for the migrating workflow.

Workflow context

Applies to: Office 365 to Office 365. Workflow design and settings, related configuration details, and workflow history.

Context refers to perspective, background, or framework. As you build workflows and use them within SharePoint, the workflow starts building workflow history, associated tasks and constants, if configured appropriately. A workflow alone doesn’t do much, but when connected to content, the workflow then has context in which to operate.

A workflow design, by itself, is a group of logic:

Migrating the design of the workflow can be achieved by performing a design migration. However, if you want more content that the workflow touches, you’re performing a Nintex context migration. A context migration contains the workflow design, the configurations, any associated tasks, any workflow history, and the items created, modified, or updated by the workflow. Essentially, all the associated assets that are linked to a workflow are captured and moved from one location to another.

The context migration is the most popular among users because migrating Nintex workflows within context allows for the entire processes managed by the workflow to stay intact. This type of migration requires the SharePointlist/library and associated items to be migrated – along with the workflow design and configuration – to retain that relationship appropriately between the content and the workflow.

Be aware of the following situations when performing a context migration with Nintex:

  1. Any workflow tasks generated by the workflow cannot be in running or in a paused status at the time of the migration. For example, the Assign a task and Flexi-task cannot be running or in a paused status.

  2. When setting up the migration using a third-party product, select the appropriate SharePoint list and workflow task list along with the workflow. If using SQL Management Studio, ensure that you have all the correct SharePoint content databases selected along with the correct Nintex databases to retain the association between list items, the workflow design, and the workflow history.

Best practice

As an IT admin or SharePoint administrator responsible for SharePoint environments, you will most commonly deal with context migrations where a business process requires that the SharePoint data and the workflow history remain intact. For example, your organization has a case study review and approval process. If you’re migrating that process, you would select the relevant SharePoint libraries and workflows to retain the correct associations upon republishing to the new location.

If you want to move the SharePoint list and libraries along with the Nintex workflow, then you’re more often attempting a context migration. Identifying this scope helps you prepare appropriately and arrange the correct steps to set yourself up for success.

For these types of migrations, while you could export the SharePoint list and then perform a design migration, it's best to use a third-party migration product to achieve this goal.

Does this migration type apply to Office 365?

Workflow conversion

Applies to: On-premise to Office 365 migration path. Workflow design and settings, related configuration details, and workflow history.

The workflow conversion migration type is probably the most talked about and most debated migration type in the Nintex community. Nintex offers two distinct workflow platform versions to accommodate underlying platform differences for Office 365.

Be aware that two major differences exists between the following versions:

  • SharePoint Server 2010 Classic Workflow Engine
  • SharePoint Server 2013 Workflow Manager

These differences within the SharePoint platform affect how Nintex workflows function as well. Nintex must be compatible with the correct workflow engine or workflow manager based on the SharePoint platform.

A workflow built on SharePoint Server 2010 must be converted so that it can run correctly in Office 365, which runs the workflow manager. There are inherent differences between the SharePoint Server 2010 classic workflow engine and the SharePoint Server 2013 Workflow Manager, which was engineered to be cloud optimized.

One of the benefits of the cloud is that you don’t have to worry about managing resources so your workflows run as they should; in fact, Microsoft designed workflow manager with that in mind. In Office 365, there is a potential downside to such freedom: If you had full control to the servers and were allowed to perform certain functions or commands, that could bring down the instance of the workflow manager that your particular workflows are executing for Office 365. This ripple effect would, in turn, could affect other customers .

This isn’t a cloud-only issue. Any large SharePoint farm has similar security models in place to prevent the entire farm from being crippled. In Workflow Manager and Office 365, Microsoft restricts things such as farm-level access and custom code uploads to the workflow manager to assist in keeping the scalability, flexibility, and security as benefits of the cloud approach.

When converting the workflow from the classic workflow engine to the workflow manager, basic functionality is present in both is lost. At Nintex, we’ve mapped those out and kept them consistent between products so that when converted, there’s a one-to-one ratio for your Nintex workflow action. A small percentage of actions have this one-to-one ratio and the remainder vary based on the workflow manager design.

Either the functionality on the classic workflow engine was injected and enhanced with code as part of the Nintex product, or the functionality simply does not have an equivalent option within the workflow manager. Also, functionality that requires specific farm-level permissions is not available in a multi-tenant environment due to modifications in the security models for the workflow manager.

Converting a workflow becomes key for handling actions across both the workflow engine and workflow manager. The process of conversion is equally logical and functional, which is why we recommend assessing your process before attempting a migration.

Best practice

Not all processes are built for the cloud environment; therefore, you must convert the Nintex workflow using a third-party product. Nintex file types and XML structure are different and written to work against the classic workflow engine and workflow manager, respectively. Our technology partners have developed products to help you identify your workflows, understand the user actions, and figure out how to move the workflows and actions between platforms.

Performing a Nintex conversion migration should never be attempted in a rush or without due diligence. During the planning stage, evaluate factors like content, permissions, and processes. Consider security aspects, availability, scalability, and access permissions because it will affect how your workflows are used and how users interact with the processes that are converted.

Benefits of using a hybrid environment

With SharePoint Server 2016, Microsoft encourages a hybrid environment. Nintex works well within the scope of a hybrid environment, where you may need workflows automating processes in SharePoint Server as well as workflows automating processes inside Office 365. This could keep you from spending a lot of time and resources converting workflows because you essentially would build the necessary workflows on their respective platforms.

Another aspect when considering a conversion is to identify the functionality needed for that workflow and checking to ensure it’s available in Office 365. Best practice for the preparation phase is reviewing the requirements you originally worked against and seeing if the requirements are the same and the functionality will need to be the same in Office 365.

Note: A conversion migration does not bring over any associated tasks or workflow history from the Nintex workflow.