As described previously, when migrating Notes workflows to SharePoint workflows you are really switching from code-based workflows (logic encoded in button events, agents, etc.) to declarative workflows. And using Notes Migrator for SharePoint, you can migrate your workflow state so you can preserve in-progress workflows between the two systems.
To achieve this, simply migrate the (status fields, next review, due date, whatever) as data columns in your list items, InfoPath documents, Word documents, etc. Depending on how you designed your workflow, you may be done at that point, or you may need to customize it. The relevant part is that when the workflow starts up for newly written list items, it should be designed to examine these columns and “advance” to the right state. For example, the out-of-box “three state workflow” does this but others may not.
A special (but very important case) is when you are able to replace your “approval process” workflows with SharePoint’s built-in approval process. This can be a huge win for reducing development costs and eliminating the need to maintain the application later. What used to be a custom developed application can be replaced with a checkbox feature!
Of course, Notes Migrator for SharePoint correctly migrates the state for that as well. The relevant part of our documentation can be easy to miss, so I will repeat it here:
Advanced: Customizing SharePoint Data Target Definitions
The Type property can be set to any of the available field types:
• Approval Code – Sets the approval status of documents that are migrated to SharePoint. Input data must be one of the following strings: “Approved”, “Denied”, “Draft”, “Pending”, “Scheduled”.
In other words, map some piece of data (probably using a formula) that yields the values “Approved”, “Denied”, “Draft”, “Pending” or “Scheduled” to a Target field of type “Approval Code”.
There is a lab on this on our support site: https://support.quest.com/SUPPORT/index?page=solution&id=SOL52223 (Lab 4.5).