It's all about the answers!

Ask a question

How to change the workflow of a work item type with existing work items

Susan Hanson (1.6k2201194) | asked May 31 '13, 2:43 a.m.
I've seen a couple posts on this but none that gave me what I think is the final answer ...

I have an existing work item type that is using the "Default Workflow".  We need to change the workflow to a custom workflow, and have to somehow get all of the existing work items to handle this change.

I can duplicate the existing workflow but it changes the IDs of all the states based on the new workflow ID:

So then I assume if I go into the Config and change the workflow from Default Workflow to APARWorkflow, basically there will no NO work items that have the correct state visible.

Is there any way to have, within the APARWorkflow, a state called:
"s4" (since this is what I assume is currently stored in the existing work item

and then add an action (temporarily) to change from "s4" to "APARWorkflow.state.closed"  which would map it to the right NEW workflow state (since I plan to reduce the states available in the workflow down to just 4 to simplify the workflow).

Or am I really just going to end up with all numbers in the work items and have to go fix them all anyway?  I'm wondering what the best practice here is.


sam detweiler commented May 31 '13, 8:15 a.m.

when we did this, we had to export the data, change the template for all the workitems, synchronize, fixup the exported data, then import to make the updates

frederick carter commented Dec 15 '13, 4:02 p.m.


can you expound on your solution ?

Susan: does sam's solution address all of your points in your original request and  your followup  comments ?

sam detweiler commented Dec 15 '13, 5:41 p.m.

see my other post on using a shared process template.  we would find all the impacted workitems (thru a query), export them.
change the process area parent.
then change the export as required (one time a filed changed from checkbox to enum, so we had to fiddle with everything, fixup the export to match.)
then update the existing workitems with the corrections..  sometimes that included a state change.

this is not for the faint of heart.. sometimes the changes are impactful in ways you don't expect.

3 answers

permanent link
Rahul Bhoy (1) | answered Sep 01 '14, 5:57 a.m.


After exporting the data and importing it back as per the new workflow, have you checked what happens to the History of the workitem. Whether it is still present or it gets blank??

sam detweiler commented Sep 01 '14, 7:02 a.m.

the history is lost using export/import.

I have not found a reliable method to recreate the history, short of redoing the operations.

Rahul Bhoy commented Sep 01 '14, 7:16 a.m.

Yeah, even I had the same result.

sam detweiler commented Sep 01 '14, 8:12 a.m.

and even if you could recreate the events,  you would still end up with a correct sequence, but the userid and timestamps would be different as there is no effective user impersonation.

we wrote a set of migration utilities to copy a project and its workitems from one server to another with as much fidelity as possible.   we spent 100 person days.
and did not get history or plan customization
we estimated another 50-75 person days for those two.. and decided to defer that to a later cycle if ever.

permanent link
Sterling Bates (2311612) | answered Feb 03 '14, 4:28 a.m.
This really should be doable.  The general flow is:

1. Store user email preferences
2. Silence user emails (has to be done per-user)
3. Reuse code from to modify work item's workflow
4. Restore user email preferences is found in the* plugin,* subarchive, and the com/ibm/team/workitem/rcp/ui/internal/wizards directory.  This is enough of the brains behind moving a workitem between project areas that you can play with its copyWorkFlow method.  I've adapted it to move workitems between project areas by simply providing a Map that identifies the source workflow ID paired with the target workflow ID.

Even without a comparable set of string identifiers between the project areas, as long as the labels match up you can eventually make that association.

Combine that with a query that pulls the workitems you want to modify in/from the project area, and it should do what you need.

permanent link
Piotr Aniola (3.7k11738) | answered May 31 '13, 4:38 a.m.
I think this workitem might contain just what you need:

Susan Hanson commented May 31 '13, 4:45 a.m.

Well, not really.  It says basically (if I read correctly):
1) that the existing work items will still have the OLD workflow
2) only NEW work items will use the NEW workflow

However, this part:
- If you want to change the workflow for existing work items, do not change the workflow ID or the binding (every work item stores the ID of its workflow), but just change the existing workflow.
.... i can't change the existing workflow, since it is used by other work item types that are still valid.

- Make sure that the new workflow is compatible with the old workflow, that is do not remove states and resolutions because old work items may use them already.

.... so this I don't understand. If the old work items will continue to have the OLD workflow saved in them, then why would this matter?  And, I don't WANT the older items to continue to have the old workflow and states, since this makes queries extremely difficult.


Piotr Aniola commented May 31 '13, 4:58 a.m.

The old workitems will only have the old workflow, IF you modify the workflow by duplicating it and binding the new workflow to the WI type, as opposed to modifying the old workflow.

In your scenario, I believe, instead of duplicating the workflow, you'd need to change the existing workflow. Since you are attempting to remove some states, I think you need to make sure no current WIs are in any of the states that you are removing.

Harry Koehnemann commented Dec 13 '13, 9:25 a.m.

 Susan, did you ever resolved this issue?  I am stuck in a similar situation with 10K+ work items to move to a new workflow. I found another forum discussion that mentioned changing the type and then changing back to reset to workflowSurrogate attribute.  But I found that resets the work item state too - not acceptable.

Please let me know if you found any resolution of workaorund to this problem.

Thanks and best regards,

Susan Hanson commented Dec 15 '13, 6:00 p.m.

I didn't really go very far on it.  I only had a handful of work items and so manually manipulating them wasn't really that bad.  I don't have 10K work items to move to a new workflow.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.