Dates on Revisions are updated in on target Azure DevOps, but not in another.

[t-anderson]

Hi Community:
I ran a work item migration targeting an Azure DevOps Services org and the migrated history came over with the original dates.
However, running the same configuration, but targeting a different Azure DevOps Services org, the migrated history came over with the migration date instead. The configuration files for both migrations have ReplayRevisions set to true. How do I get the original dates on revision history? Thanks in advance.

"Processors": [
{
"$type": "WorkItemMigrationConfig",
"Enabled": true,
"ReplayRevisions": true,
"PrefixProjectToNodes": false,
"UpdateCreatedDate": true,
"UpdateCreatedBy": true,
"WIQLQueryBit": "AND [System.WorkItemType] IN ('Epic') AND [System.AreaPath] under 'company\TeamA'",
"WIQLOrderBit": "[System.ChangedDate] desc",
"LinkMigration": false,
"AttachmentMigration": true,
"AttachmentWorkingPath": "c:\temp\WorkItemAttachmentWorkingFolder\",
"FixHtmlAttachmentLinks": true,
"SkipToFinalRevisedWorkItemType": false,
"WorkItemCreateRetryLimit": 0,
"FilterWorkItemsThatAlreadyExistInTarget": true,
"PauseAfterEachWorkItem": false,
"AttachmentMaxSize": 480000000,
"AttachRevisionHistory": true,
"LinkMigrationSaveEachAsAdded": false,
"GenerateMigrationComment": false,
"WorkItemIDs": [],
"MaxRevisions": 200,
"UseCommonNodeStructureEnricherConfig": true,
"StopMigrationOnMissingAreaIterationNodes": false,
"NodeBasePaths": [],
"AreaMaps": {},
"IterationMaps": {},
"MaxGracefulFailures": 5,
"SkipRevisionWithInvalidIterationPath": false,
"SkipRevisionWithInvalidAreaPath": false
}
]
}

[MrHinsh]

The migration account needs to be a collection admin (Org admin) on the Target environment to bypass the rules model, which is required for things like back-dating.

[t-anderson]

The migration account is in the PCA group on both Azure DevOps Services Targets. I tried the migrations again using the Org owner as the migration account this time, but still get the same behavior; migrated history was back-dated in one Target but not the other.

[MrHinsh]

I really don't have a clue why "bypass-rules" would work on one and not the other except through permissions somewhere.

[t-anderson]

I tried adding the migration account to the Project Collection Service Accounts group on the Azure DevOps Services Target where the bypass rules are not working, but still get the same behavior. Any ideas on how I can verify the permissions are set in this Target as needed? This target was created in 2013, permissions may be in an abnormal state.

[MrHinsh]

If the target is TFS 2013 then you can not! The ability to manipulate the Dates was added in TFS 2015.

[t-anderson]

The source is TFS 2019 and the target is Azure DevOps Service.

This Azure DevOps Service instance was created back in 2013, but it's current version number, found using https://dev.azure.com/YourOrganizationName/_home/About, is Azure DevOps Service Version Dev19.M227.1 (AzureDevOps_M227_20230929.5)

[t-anderson]

I may have found a possible root cause for this issue. With the New Boards hub preview enabled, the migrated work item's State Graph and History filed show revision history with the migration date timestamps. When this preview is disabled, the revision history is the original (source) timestamps.

Is anyone else seeing the same behavior or can reproduce?

[MrHinsh]

That's very odd as it would be look at the same data, and if the core data for Created and Changed was updated there would be no record of the original. 🤷‍♂️

Very strange.

[t-anderson]

This was a known issue with "New Boards Hubs" preview feature and has since been fixed.