Confusing behaviour of UpdateCreatedDate and UpdateCreatedBy in TfsWorkItemMigrationProcessor

[MrHinsh]

Users are reporting confusion when rerunning the migration tool. Specifically, they expect changes to sync across but find that nothing happens when UpdateCreatedDate and UpdateCreatedBy are set to false.

This confusion arises because:

• When UpdateCreatedDate and UpdateCreatedBy are false, revisions in the source must have a higher date than the target, otherwise they are filtered out.
• This behaviour is correct but not obvious, leading users to believe updates are being skipped incorrectly.
• These flags were originally introduced only to support TFS 2008, which does not allow setting revision dates in the past.

Current Behaviour

• If UpdateCreatedDate and UpdateCreatedBy are set to false, rerunning the tool does not sync new changes unless the revision date in the source is newer than the target.
• Users mistake this for incorrect syncing behaviour.

Expected Behaviour

• The tool should make it clear that these settings are legacy, only relevant for TFS 2008, and not recommended for modern TFS/Azure DevOps versions.

Resolution

• Removed UpdateCreatedDate and UpdateCreatedBy properties from TfsWorkItemMigrationProcessor.

• Added a new property ProductVersion on the Target to clarify intent and scope:

  • OnPremises (default)
  • OnPremisesLegacy (for older TFS versions like 2008)
  • Cloud (for Azure DevOps Services)

Benefits

• Removes ambiguity around legacy flags.
• Makes it clear that behaviour differs by product version rather than hidden behind boolean switches.
• Provides a more explicit and maintainable way to configure processor behaviour.

[nkdagility-actions-bot]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://blue-river-093197403-2960.westeurope.5.azurestaticapps.net