We have discussed various issues about workflow in the past [link].  To make a long story short, there is no way to press a button and magically translate Notes code-based workflows to SharePoint declarative workflows, but Notes Migrator for SharePoint does an excellent job at migrating your workflow state. 

Recently we have been getting a few questions about how people should handle workflows that automatically change the security of the document as it moves through various workflow stages.  For example, imagine a Notes application that lets an “Author” add or update travel requests until they are ready to submit it.  Once the request is submitted, however, the Author can no longer make changes and it us up to her “Manager” to approve it, reject it, or make further changes.  Real-world Notes applications can easily have many such dynamic access rules.

The way Notes developers typically implemented this type of workflow was was to have buttons, formulas and agents that implemented the right steps.  The actual security rules were usually implemented using reader / writer fields that listed specific people (or groups) that were currently allowed to update the document.  So when the Author pressed the “Submit to Manager” button, some code would run which looked up the manager and updated the reader / writer fields on that document so that now only the manager could edit it.

(Side note, there are also some cases where people did the security enforcement in the user interface.  That is to say, they tried to hide the parts people were not allowed to see in the UI.  But most Notes developers understood that this was not true security.)

So when we migrate this document, we have the option to map those reader / writer fields over to the equivalent document-level permissions in SharePoint.  Notes Migrator for SharePoint makes this trivial.  But it is important to remember that the security on this document is really just a snapshot of its current workflow state.  A workflow process on the SharePoint side is going to need to pick up the document from there. 

In the SharePoint world, you will really have two choices.   If you are using something like InfoPath to design complex forms, it will be possible (though not necessarily a good idea) to implement the workflow the old way:  with code on your form buttons and other form events.  It is possible that you could write code that set the appropriate document level permissions as described above. 

It is more likely however that you will want to switch to declarative workflow instead.  Declarative workflow means that you have a workflow engine interpreting a set up rules that someone (not necessarily a developer) has configured.  This could be a built-in SharePoint workflow, something designed in SharePoint Designer, or something designed in Visual Studio.  The workflow capabilities in SharePoint get stronger with each new release.  Another great choice is to implement the workflow with an add-in tool such as Nintex.  (Many people migrating Notes applications find Nintex to be exactly the right-size tool for rebuilding complex apps, but there are many other nice choices available as well.)  Regardless, your workflow definition will include rules to update the document level permissions according to your business rules.