Navigation: How Content Matrix Handles Various SharePoint Components >
How InfoPath Forms are Migrated
InfoPath forms can be migrated through the same process as migrating a SharePoint list.
IMPORTANT: InfoPath forms can only be migrated to the Enterprise edition of SharePoint 2019.
The Database (DB) connection types cannot be used to migrate InfoPath Forms because these types of connections cannot fully access the source and target metadata.
NOTE: Currently, if Office 365 OAuth with MFA Authentication is used, Content Type InfoPath forms will not be migrated, and browser enabled InfoPath form templates will not be browser-activated at the target.
Criteria for Link Correction
When migrating InfoPath forms, Metalogix Content Matrix will automatically try to run link correction, provided the Enable Link Correction option in the General Options tab is enabled, on any items that meet the below criteria:
·If the BaseTemplate for the list is a FormLibrary.
·If the item contains ".XML" in its FileName field.
NOTE: If an XML file is manually uploaded to a forms library it will undergo this link correction process as well. However, since these XML files will not actually have the necessary InfoPath form links to correct, no links will be corrected for the file. No logging will occur for the link correction in these types of files.
If the item does not meet both of these requirements, then the link correction process will not try to correct the link data for InfoPath forms.
If the Verbose logging option under the General Options tab is not enabled, then this link correction will not be reported in the migration logs. However, if the Verbose option is enabled, then any successfully corrected links in the InfoPath forms will be reported in the migration logs.
NOTE: A mandatory InfoPath Item Content Link Corrector transformer for this InfoPath link correction ability can be found in the Transformations tab, under the SharePoint Items transformer definition.
Navigation: How Content Matrix Handles Various SharePoint Components >
How SharePoint Workflows are Migrated
Before continuing into the SharePoint workflow migration process, it is a good idea to have a better understanding of what each of these workflow pieces are.
·A workflow association contains all the data necessary to run the workflow at a given level (i.e. all the variables). For example, they contain all the parameters for a workflow Instance, default values, a list of steps that need to be taken, and other tasks (such as sending email to specified users). Workflow associations can be present in the following:
§In SharePoint 2007, they can be found in lists, libraries, and content types.
§In SharePoint 2010, they can be found in sites and site collections.
§SPD 2010 platform workflow associations can be found in sites and site collections, and SPD 2010 platform and Out-of-Box workflow associations can be found in lists and content types.
§SPD 2013 platform workflow associations can be found in sites, site collections, and lists.
Only the most recent version of the workflow associations will be migrated.
·Metalogix Content Matrix can also migrate the workflow template, so long as the template is defined locally on the source SharePoint server (and is in a hidden list called "Workflows") and is not defined at the server level. This is usually the case for SharePoint Designer (SPD) workflow templates and Nintex workflow templates. Basic Out-of-Box (OOB) templates are not defined locally (they are not listed in this "Workflows" folder), so OOB Templates are not supported for migration. However, Metalogix Content Matrix will look for these OOB templates on the target, and while it cannot migrate the OOB templates themselves, it will activate the required features to enable them.
·Metalogix Content Matrix is also able to migrate workflow instances.
EXCEPTION: Migration of SPD 2013 platform workflow instances is currently not supported.
The instances are the actual running processes of a workflow, and are only present on items. Each instance is attached to an association, so if the associations are not migrated, the instance cannot be migrated either. Additionally, only the running or completed workflows that are associated with the latest workflow instance version will be migrated.
IMPORTANT: For workflow instance migration to be enabled, migration of workflow associations and a switch that allows Metalogix Content Matrix to write the data directly to the database must be enabled.
·Workflow histories are currently always migrated from SharePoint 2010 and never migrated from SharePoint 2013 and later, regardless of whether workflow instances are migrated.
Pre-Workflow Migration Considerations
If you are performing workflow migration, it is highly recommended you have a general understanding of their workflows and where the data is located to ensure that data integrity is preserved after a migration.
Consider the following questions:
·What type of workflows are being used?
§Are there out of box (OOB) workflows?
§Are there SharePoint Designer (SPD) or Nintex Workflows?
§Are there other third party workflows?
Depending on the answer to this question, there can be different steps that need to be taken, or even a slightly different approach to the migration. The following are some general responses to this question:
·If there are OOB workflows - OOB workflows are installed as a SharePoint solution file, and are deployed across the entire farm. As a result, they are defined at the server level. In this case, Metalogix Content Matrix will not migrate the template definitions, but will instead activate the features on the target side to allow the OOB workflow templates to be used. If migrating at the site collection level, these templates will be activated by Metalogix Content Matrix, and only the features will be activated. If migrating at a site or list level (and not the site collection level), you must ensure that the templates are already activated at the site collection level before a migration is run so that the features can be activated. This is especially notable when migrating from SharePoint 2007 to SharePoint 2013 or later.
NOTE: In some cases, you may need to manually activate the SharePoint 2007 Workflows feature on a SharePoint 2010 or later target environment before the workflows can be properly migrated.
·If there are SPD or Nintex Workflows - SPD and Nintex Workflows have a local install of the workflow template (WFA) definition. This definition is usually held in a hidden list called "Workflows." If the Preserve workflow associations for SharePoint Designer and Nintex Workflow option is enabled, then Metalogix Content Matrix can migrate the template as well. However, in this case the migration must be performed at a site or site collection level. This is because the definition is in a local hidden folder and the rest of the data is spread out, and can only be collected when performing a site or site collection level migration. As long as the workflow templates are defined locally, Metalogix Content Matrix should be able to migrate them.
·If there are third party workflows - The answer here can vary depending on the workflow in question. If the third party workflow works in the same way as a SharePoint Designer or a Nintex Workflow, then the workflow can be migrated using the same steps as SPD and Nintex Workflows.
If the third party workflows are set up in a different way from OOB or SPD and Nintex Workflows, then migration of those workflows is currently not supported.
Once you have a better understanding of what type of workflow is being migrated, the actual migration process can begin.
For additional Nintex workflow-specific considerations, see Additional Considerations for Nintex Workflows.
Workflow Migration Requirements and Limitations
The following list describes some requirements and limitations to be considered when migrating workflows. Note that this list may not exhaustively cover every migration scenario.
NOTE: SP 2010 OOB and SPD 2010 style workflows are no longer supported by Microsoft for SharePoint Online, so they will be skipped during migration to a SharePoint Online target.
·For a migration at the site level or higher:
§The source connection can be Database (SharePoint 2010 or later); Object Model (OM) connection (through either a Local or Remote Metalogix Extensions Web Service (MEWS) connection) (SharePoint 2013 or later). However, for a SharePoint 2013 source, the only supported target is another SharePoint 2013 or Office 365 tenant connection.
§The target connection must be Local OM, MEWS, CSOM, SharePoint 2013 or later, or Office 365 Tenant.
·For a migration at the list level (OOB and SPD workflows), the source connection can be SharePoint on premises local Object Model (OM) or Metalogix SharePoint Extensions Web Service (MEWS).
·When migrating from a SharePoint 2010 DB source to a SharePoint 2013 or later CSOM target, Metalogix Content Matrix is unable to distinguish between SPD and Nintex workflows, so it will attempt to migrate all SPD/Nintex workflows that are found. As a result, a warning message will be displayed (if the Nintex workflow feature has been enabled) indicating that any Nintex workflows that are migrated through these connections will result in errors for the Nintex workflow after migration.
·Metalogix Content Matrix does not currently support migrating SharePoint Designer 2013 read-only style workflows from SharePoint 2013 or later source environments over MEWS or CSOM connections. Workflows will be skipped; only lists and libraries will be migrated under these conditions.
·When migrating SPD 2013 platform workflows, the SuppressEvents property must be set to False in order for workflows to be published after migration. For more information, please see Modifying the SuppressEvents Property.
·If you initiate a list-level migration and you want to migrate workflows for the lists, all of the site-level dependencies must already exist at the target. See also Pre-Workflow Migration Considerations.
·Metalogix Content Matrix does not support the migration of workflows at the item level because the item level scope of the migration cannot properly fetch all of the necessary data, as this data is usually stored at the site or list level (this includes actions that reference other lists, site level content types, and so on).
·Workflow histories are currently always migrated from SharePoint 2010 and never migrated from SharePoint 2013 and later, regardless of whether workflow instances are migrated. This applies to Nintex workflows as well, regardless of whether the option "Preserve Nintex Workflows instance history" is checked. This is a known issue that will be addressed in a future release.
· List-level migrations are not currently supported for Nintex workflows.
© 2021 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Termini di utilizzo Privacy