Sharepoint 2010 - Migrate List-based Workflows between Sites and Site Collections
Thank you Gavinmckay, you saved me!
From his blog: http://gavinmckay.wordpress.com/2011/08/29/howto-move-or-migrate-sharepoint-2010-list-based-workflows-between-sites-and-site-collections/
I’ve experienced this issue a lot when trying to migrate workflows between test SharePoint 2010 farms and production farms, in particular with workflows attached to lists. When moving a workflow to another site collection or server farm, the association to the list is broken and the workflow cannot be attached to the list. You also cannot use SharePoint designer to fix this via the standard methods as the unattached workflow cannot be reattached to the list.
List-based workflows are tied to three different lists – the “main” source list where the data is held (such as a Forms library or custom list), a task list, and a workflow history list. The latter in particular is tricky, because it is a hidden list and cannot be viewed via the normal interface.
The fix for this is to modify the source workflow files to force the workflow to reattach to the list. The following method assumes that your new site/location that you are moving the workflow too does not yet have any workflows already attached to any lists on the site. When a workflow is created in a site for the first time, a Tasks list and a Workflow History list are automatically created/used by the workflow. These lists must exist before you can force your migrated workflow to attach to the list.
Step 1 – Create a Blank Workflow
Using SharePoint designer, connect to your destination site
Create a new list-based workflow called “test” (or whatever), attaching it to your migrated list
Create one condition (i.e. if 1 = 1)
Create one action (i.e. add comment “hello”)
Save and publish the workflow
After this step has been completed, your site will now have a Tasks list and Workflow History list.
Step 2 – Get the list ids for your new workflow
The list ids are required to configure your migrated workflow.
Using SharePoint Designer, connect to your destination site
in the left-hand side, in Site Objects, select All Files
in the All Files list, select Workflows
Select your new workflow that you just created (in this example, “test”)
You should see (at least) four files:
text.xoml
test.xoml.rules
test.xoml.wfconfig.xml
test.xsn
Right-click on test.xoml.wfconfig.xml and select Open With, Notepad
Look for the <Association…> tag in the xml:
<Association ListID=”{7DC232FD-4D0B-4F7B-AC72-3D4D6399147C}” StartManually=”true” TaskListID=”{CB551A8B-F1E1-49F9-A8F8-A2C8EDC241C7}” HistoryListID=”{04B19F9D-5A47-4E14-B85E-53FFF06CFA63}” StartOnCreate=”true” StartOnChange=”true”/>
Record the Guid entries for ListID, TaskListID, and HistoryListID
Step 3 – Update the migrated workflow
Still using SharePoint Designer, All Files, Workflows, this time select your migrated workflow
You should again see (at least) four files. Right-click on “your-workflow.xoml.wfconfig.xml” and select Open with SharePoint Designer (As XML)
Find the Association tag and very carefully change the Guids so that your migrated List IDs are the same as the “test” workflow List IDs.
Save the file
Close SharePoint Designer
Open SharePoint Designer again and open your site
Instead of All Files, this time click on Workflows
Select your workflow
Save the workflow
Publish the workflow
Your workflow should now be reassociated with your list on your new site.
Yes! It is!
Nice to see your blog and hope frequent visit. It’s such valuable information more about Sharepoint Migration. Requesting you please do share more about sharepoint in future.
ReplyDeleteGreat to see this informative blog.
Is there a way to automate this? Say some tool? Cos my client is too dumb to follow these steps manually, and he wont give me access to prod server either.
ReplyDeleteHi,
DeleteIt is an edit on xml file and I think there's no way to automate...
Right way of deploying solution to avoid this problems is .. use the right way..
This article is for those have deployed with export/import solution.
If you use Backup/Restore (backup in test, restore in prod), workflows keep their ID.
Backup/Restore in prod works well. But since ours would be an incremental update, the backup/restore cannot be used. I'll try explaining these steps to my client anyways. Lets hope he replaces the right guid's.
ReplyDeleteYou can try this cmdlet from Gary Lapointe: http://blog.falchionconsulting.com/index.php/stsadmpowershell-commands.
DeleteThere's a command to export single object, like List or Library, with option -retainobjectid (but works when you create new list/library)
Good luck...
I have been able to get the workflow to associate to the new list, however the workflow remains sitting in the original list. How can the workflow be 'moved' to sit within the new list? Without doing this the workflow cannot funcion.
ReplyDeleteYou can modify the xml as explained in this article.
DeleteRemember to write the right List/Library Guid and then close and reopen SP designer.
For me, it works.
I have copied a publishing site containing my list workflows to a new site within the same site collection using the Manage Site and Content feature. Does the above solution still apply? Im a bit confused as I assume if you set the GUIDs of the new workflow to the GUIDs of source list (original lists) then wouldn't any editing affect the source/original list instead and not the new lists in the new location considering the fact Im still in the same site collection?
ReplyDelete