A software developer, who would prefer not to be identified, has drawn our attention the the following discussion about Microsoft's Windows Workflow Foundation (WWF) platform. The comments were first posted on the Visual Studio Magazine (www.visualstudiomagazine.com) and seem to indicate this could be a major issue for anyone who has built significant workflow capabilities into their products/solutions with the current Workflow Foundation platform.
Our contact says “I believe that typically Microsoft take 1-2 years to move from PDC to release code so to do anything with WWF in the meantime could mean significant re-work that equates to almost starting all over again from scratch if I am reading this correctly (and this is no doubt the positive spin!). That means that even if a vendor is able to re-create or partially migrate their existing solution to the 'new' WWF platform, any client who already has used it as a basis to start and deliver their own customised solution for file opening or anything else built on that platform will quite possibly have to re-implement all of their work again.” (Our contact adds that when Microsoft did something similar with the move from Visual Studio to Visual Studio.NET, the subsequent 'migration' equated to a 90% re-write.)

Here's the comment – the question is answered by Kathleen Dollard and you can read more on her blog at http://msmvps.com/blogs/kathleen/

Q:  I've been hearing that Windows Workflow 4.0 was announced at the Professional Developers Conference (PDC), and that it “changes everything.” Is this true, and if so, what does this mean to those of us that have existing workflows?

A:  Windows Workflow Foundation (WWF) 4.0 was unveiled at PDC and is available now as part of the current .NET 4.0 Community Technology Preview (CTP). As such, details aren't complete, so remember that my answer is based on these preliminary announcements. If you're contemplating using WWF and can wait until .NET 4.0 is released, I suggest waiting. This is particularly true if you have an existing state-based solution you can nurse along for another year or two. If you do write new workflows in the interim, I've collected a set of preliminary guidelines for preparing workflows to transition. If you've worked with WWF 3.0 or 3.5, this is a jaw-dropping list; many of the primary elements you might think of as WWF disappear in the transition to WWF 4.0.

Be careful with data. The tracking and persistence databases are likely to change significantly between 3.5 and 4.0. Holding data only in tracking is hazardous, unless you prepare a strategy for extracting data, such as when a workflow completes. If you're using rules for simple data retrieval for values that should be set outside the workflow, consider holding this data in a configuration file or database. Note that these are preliminary suggestions. Check out my blog for pointers towards Microsoft's formal guidance, as well as tools (as they become available) that will help you transition workflows.

Another important aspect of your transition strategy concerns long-running workflows. The simplest transition strategy is to allow all workflows to complete in 3.0/3.5 but to begin new workflows in 4.0. If you have aggregate information or if you have long-running workflows, this might not be an acceptable strategy. In this case, you need a strategy to bring down existing workflows and bring them back up in WWF 4.0. If you're writing workflows today and believe you'll need this strategy, consider building in events to initiate the process. If you have existing workflows, you might need to alter them later, but it's not yet clear whether Microsoft will provide a tool to help automate the 3.0/3.5 workflow-modification strategy.