As our customer base gets smarter and smarter about SharePoint and migration issues, I hear about Workflow more and more.  It was amazing how often it came up at the SharePoint Conference compared to other shows 6, 12, 18 months ago.  

Naturally, all of our customers would like to push a button in our tool and migrate their Notes workflow applications to SharePoint.

The core problem is that Notes people typically implement “workflow” by writing hundreds of lines of formula or LotusScript code on button events and agents.  Even though people have been using Notes to do workflow for years, there is actually no specific workflow feature in Notes.  In SharePoint, declarative workflow is an actual feature and is implemented completely differently.  The RIGHT thing to do to rethink how workflow should be done in SharePoint.  SharePoint has a range of options from out-of-the box workflows, to SharePoint Designer workflows, to workflows build with Visual Studio and custom .NET code (C# or VB.NET).  This is on top of the built-in "checkbox" features such as the document approval, versioning, and check-in check-out features available in SharePoint lists and libraries.  So in many common cases, those 100 (or 1000) lines of LotusScript can be replaced by a simple code free SharePoint construct.

I have made the above explanation to partners and customers many times over the years and have come to realize that they need more than an excuse (even if it is a really good excuse) for why out tool does not attempt to map apples to oranges.  They need some practical advice.  So I have started a project to explore how I would go about migrating typical Notes workflows to SharePoint.  I want to be able to deliver a strong set of specific advice as to how we recommend customers approach the problem and all the things that Quest tools do do to help.

This is still an evolving area, but here is a rough outline:

1. Notes Migrator for SharePoint does a great job at migrating the data (and metadata) that is used to drive the workflow process in Notes (for example the “Next Approver” and “Status” fields).  This can be made to work well with most SharePoint workflow processes.   Our tool writes the data record, including the workflow state, and the SharePoint workflows are triggered automatically.  I am working on some better demos to show this better.

2. We are currently working with several vendors of high-end Workflow products to better understand how how our tools should be used together.  Our customers already use our products together but I think we can help them by providing better samples and prescriptive guidance.

3. Quest's Web Parts for SharePoint (an awesome tool in general for quickly building complex user interfaces, like the ones you have in Notes, on SharePoint) has a lot of support for working with SharePoint workflows and third-party workflow products.

4. Our new Analysis tools will (in production, stay tuned) make it easier to understand what that old Notes "workflow" really did.

Quest's System Integrator partners are already great at helping customers navigate this complex terrain.  Quest will continue to improve its tools, samples and guidance but meanwhile I encourage customers to bring in the right services people to help.  I will follow up with a Part 2 of this article when we have some workflow migration example on our new demo site, which should be online soon.

PS:  There are some people who will tell you that complex workflow applications can't really fit on SharePoint and you should therefore invest in rebuilding them as expensive Visual Studio based solutions.  I suggest escorting that person out of your office.