Replies: 13 comments
-
You can, but it's not recommended. The new version is MUCH faster end to end. Can I ask why you would want to migrate different work item types separately? I generally recommend to move all Open work item in the last 90 days, then all closed items. Once you have the last 90 days then move up to the last 360, then the rest... This method of progressive scope expansion for work item migration enables the quickest turnaround.... with the tail being mopped up over time. Running this separately is no longer supported and will not benefit from feature enhancements and bug fixes. You can install a version prior to v8.. to continue to run them separately. |
Beta Was this translation helpful? Give feedback.
-
Have a team converting from customized Agile to OOB Scrum in TFS. What would be the querybit for the last 60 days? Understand what you have said and I'm adding all the work item types into one. It's that each one had different FieldMaps for the states, so it was easy to keep track of them separately.
|
Beta Was this translation helpful? Give feedback.
-
I usually do something like:
That way I get explicit control of the date. You can also filter for |
Beta Was this translation helpful? Give feedback.
-
Note that you can add different field mappings for each work item type and have others that apply to them all. That way you can run a single migration as above. |
Beta Was this translation helpful? Give feedback.
-
I went with the "IN" instead of "Not In" to only cover the 5 work item types being moved. This is the bulk of the JSON now: |
Beta Was this translation helpful? Give feedback.
-
OK, so for the Then only have a seperate mapping if you need to branch. They are executed in the order they are listed, so if you have a second mapping for State thst is only for 1 work item type then just have it after. |
Beta Was this translation helpful? Give feedback.
-
So did not have this issue before, but it stops on attachments it can't add. Management before my time thought it was a good idea to allow large file attachments. Users abused it and where attaching long videos so the database was growing. To prevent that I put the attachment size back down to 4MB. migration.exe Warning: 0 : [EXCEPTION] Microsoft.TeamFoundation.WorkItemTracking.Client.FileAttachmentException: TF237082: The file you are trying to upload (US-175637_TestEvidence_Losstheft_replacement.docx) exceeds the supported file upload size (4 MB(s)). Instead of uploading the file, add the file to version control or to the team project web site, and then link the file to the work item. |
Beta Was this translation helpful? Give feedback.
-
Should now be all fixed. MaxAttachmentSize of the target can be set in the config and it defaults to the 60mb that is Azure DevOps Services. |
Beta Was this translation helpful? Give feedback.
-
I will test and let you know how it goes. Is it wrong to run the same JSON pointing to another project? [ User Story][Complete: 64/19231][sid:374652|Rev:36 ][tid:null | Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemLinkValidationException: TF201066: You cannot add a Child link to work item 174222 because a work item can have only one Parent link. ---> System.Web.Services.Protocols.SoapException: TF201036: You can not add a Child link between work items 175803 and 174222 because a work item can have only one Parent link. at Microsoft.TeamFoundation.WorkItemTracking.Proxy.RetryHandler.HandleSoapException(SoapException se) at Microsoft.TeamFoundation.WorkItemTracking.Proxy.WorkItemServer.Update(String requestId, XmlElement package, XmlElement& result, MetadataTableHaveEntry[] metadataHave, String& dbStamp, IMetadataRowSets& metadata) at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.SendUpdatePackage(XmlElement package, XmlElement& result, Boolean bulk) --- End of inner exception stack trace --- at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.Save(SaveFlags saveFlags) at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.Save() at VstsSyncMigrator.Engine.MigrationContextBase.SaveWorkItem(WorkItem workItem) in C:\Source\TFStoADO\MigrationTool\ado-migration-tools-8.4.7\src\VstsSyncMigrator.Core\Execution\MigrationContext\MigrationContextBase.cs:line 86 at VstsSyncMigrator.Engine.WorkItemMigrationContext.ProcessWorkItem(WorkItemStoreContext sourceStore, WorkItemStoreContext targetStore, Project destProject, WorkItem sourceWorkItem, Int32 retryLimit, Int32 retrys) in C:\Source\TFStoADO\MigrationTool\ado-migration-tools-8.4.7\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 190 migration.exe Warning: 0 : [EXCEPTION] Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemLinkValidationException: TF201066: You cannot add a Child link to work item 174222 because a work item can have only one Parent link. ---> System.Web.Services.Protocols.SoapException: TF201036: You can not add a Child link between work items 175803 and 174222 because a work item can have only one Parent link. at Microsoft.TeamFoundation.WorkItemTracking.Proxy.RetryHandler.HandleSoapException(SoapException se) at Microsoft.TeamFoundation.WorkItemTracking.Proxy.WorkItemServer.Update(String requestId, XmlElement package, XmlElement& result, MetadataTableHaveEntry[] metadataHave, String& dbStamp, IMetadataRowSets& metadata) at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.SendUpdatePackage(XmlElement package, XmlElement& result, Boolean bulk) --- End of inner exception stack trace --- at VstsSyncMigrator.Engine.WorkItemMigrationContext.ProcessWorkItem(WorkItemStoreContext sourceStore, WorkItemStoreContext targetStore, Project destProject, WorkItem sourceWorkItem, Int32 retryLimit, Int32 retrys) in C:\Source\TFStoADO\MigrationTool\ado-migration-tools-8.4.7\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 226 at VstsSyncMigrator.Engine.WorkItemMigrationContext.InternalExecute() in C:\Source\TFStoADO\MigrationTool\ado-migration-tools-8.4.7\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 119 at VstsSyncMigrator.Engine.MigrationContextBase.Execute() in C:\Source\TFStoADO\MigrationTool\ado-migration-tools-8.4.7\src\VstsSyncMigrator.Core\Execution\MigrationContext\MigrationContextBase.cs:line 35 MigrationEngine: The Processor WorkItemMigration entered the failed state...stopping run |
Beta Was this translation helpful? Give feedback.
-
Yup, you will not be able to do that. I recommend that you use a new empty organisation using https://aex.dev.azure.com/signup/ and run trials against that. |
Beta Was this translation helpful? Give feedback.
-
This is TFS 2015 Update 4.1. I may have to go back to an older version of the tool. |
Beta Was this translation helpful? Give feedback.
-
Ok, create a new collection and test against that. |
Beta Was this translation helpful? Give feedback.
-
For the Test Plans and Suites: I run all the other processes to bring in the work items but Test Plans and Suites. Then run the process associated with the Test portion and get this: migration.exe Information: 0 : Migration Context Start TestPlansAndSuitesMigrationContext
|
Beta Was this translation helpful? Give feedback.
-
With the 8.4.7 version can you migrate all the work items first and then in another JSON file complete the linking and attachments?
We first in several JSON files move task, epic, feature, task, and pbi. Then looking to run after all those JSON, and one just to link them all together and add attachments.
Use to use the old version before everything was combined into WorkItemMigrationConfig.
Beta Was this translation helpful? Give feedback.
All reactions