My OpsHub code and work item migration has stopped at 70% complete with the error:
OH-SCM-002: Entity with Internal Id 9030, Global Id 10819 from XXX__TFS_Source_1416167909383_ALM_TFS_14161679093851416167909415 has not been synced into destination system yet. Please sync the entity or remove entity mapping to continue sync process.
I realise that the cause of this is probably because work item 9030 is associated to a changeset in which there are files for two different projects (this was a mistake on the developers part). In other words, changeset 18909 (not mentioned in the error message, but is mentioned in the OpsHub Migration Utility "Version Control Failures"), in which the files $/Proj1/FileA $/Proj2/FileB were modified, is associated with work item 9030. $/Proj1 has been mapped as part of the migration, $/Proj2 has not been mapped.
Thus far, this migration has taken 11 days to get to this point (70% complete) so I am not at all keen to delete this migration and start again as per the suggestion on this similar question: OpsHub errors OH-SCM-003 and OH-SCM-002 - Resolution description is unclear
My question is:
a) I have since removed the association between work item 9030 and changeset 18909, but the error still occurs. Is this expected?
b) Is there a way for me to force the OpsHub migration utility to ignore this changeset? I have no need of the code in $/Proj2 to be migrated, nor do I need work item 9030 to be migrated. It would even be acceptable if this changeset was skipped altogether.
Update From OpsHub: This issue has been fixed. Hence, in newer versions of OpsHub, WorkItem links across projects will not fail if only a subset of the projects involved are selected to be migration.
Thank You Lance for your assistance.
Answering your questions one by one
a) Removing the link in your on-prem TFS is not going to make any difference now. The OpsHub Migration Utility has already retrieved the information pertaining to that changeset-workitem association. And it (that information) is being held in OpsHub. Hence, changing anything in your source now, is not going to matter.
b) Unfortunately no. Although when your changeset contains commits across project. And only a selective ones from those are selected to be migrated. The files lying in other projects are skipped. But the workitems are not.
You can do the workaround just like the person in the thread you linked did. If it is not a hassle. -Pause the current migration. -Create a new migration and select to migrate only Work Items of Project2 -Once that is done. Resume the current migration. It would work since now the utility will find the expected WIT in the VSO to link with. -(You can delete the second project post the migration of the first one, if not needed)