I've build a workflow with SharePoint Designer 2010 on a dev computer. Let's say it's in V1.

Now I want to move the workflow to the production environment. What is the correct way to do that ?

I've exported the workflow as a template (in a wsp file), then added the solution in the farm solution (didn't work with sandboxed solution). Then I can can activate the feature and my workflow template is here in the target computer. Is it the correct way ?

This approach have caused some problems :

  • the exported WSP contains the OOB <Field Id="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" ... />. So as soon as I deactivate the feature, the Title field is removed and everything in the site brokes
  • If I update the workflow on the dev computer, I can't export it again and upgrade the solution on the target computer. New solution ID and feature ID are generated, and the upgrade cannot be done.

How can I properly manage the lifecycle of the wokflow ? If I import it into Visual Studio, can I later design the workflow in SPD then upgrade the Visual Studio project ?

PS: Don't know if it matters, but the Workflow is a reusable workflow targeting a custom content type.

[Edit] the question is still open, but I found the source of my problems; I renamed on the content types generated by the custom task process. Don't know why, but it broke something. I set-up from scratch the task process and it works. I can actually export the WF, and import it using site solutions

2 Answers 2


If you don't need to do additional custom development in VS2010, you can use the reusable workflow template you created in SharePoint Designer to deploy your workflow to production using the solution package. After you upload it to the solution gallery for your site collection you will need to activate it, and then activate it in the site. It should then appear in the list of workflows.

If you import the .wsp to Visual Studio it will need to be a farm solution because custom workflows require full trust. You can't take your VS2010 .wsp and move back to SPD. If you need some custom behaviour, consider developing custom actions in VS2010 rather than a full VS2010 workflow template. Try to keep your workflows declarative if you can.

Upgrading workflows is a little complicated because there may be workflows "in flight". When SPD re-publishes a workflow it re-names it and the old workflow stays around for running workflows. The recommended approach for VS2010 workflow upgrades is to do this side-by-side using a new feature and assembly and use scripting to modify the workflow associations. Versioning workflows is such a pain that you might want to have a fairly conservative release schedule to try to minimize the need to upgrade.


You can actually export sharepoint designer workflows and import them into Visual Studio 2010 to redeploy as a declarative (no-code) workflow, but it takes a bit of custom work, mainly tidying up hardcoded ListId references and using the correct feature receivers, etc. I have a series of blog posts on this, starting from this post:


This means you can control everything around your workflow/wsp - the task forms, content types, etc etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.