Handling Number Conflicts when migrating to a live ServiceNow instance

Here is a summary of some number conflict resolution strategies that should be considered when migrating to an existing ServiceNow instance or when consolidating multiple instances onto one new instance.  Note that you can adopt different strategies for each application.

Strategy	Advantages	Disadvantages/Risks
Let the target instance generate new numbers for all migrated tickets and migrate the legacy number into the correlation id field (or another custom field)	Easy to implement in Precision Bridge & performance efficient.	Any references to numbers embedded in the text elsewhere will be incorrect. For KB articles, links containing these numbers will be broken and may require some manual work to correct.
Allow Duplicate Numbers	Easy to implement No issues with embedded numbers in tickets	Confusion for users, particularly if the 2 duplicate tickets are in the same domain. If they are in different domains, this may not be so much of an issue. Possible failure of links in Knowledge Articles that contain a reference to a number that is duplicated. At worst, this could link to the wrong article.
Add a prefix/suffix to all migrated numbers	Easy to implement Embedded numbers in knowledge links could potentially be updated by Precision Bridge during migration.	All  numbers will be changed, requiring some re-education of end-users searching for records.
Add a prefix/suffix to all migrated numbers, only where a conflict is detected	The number of records where numbers are changed is kept to a minimum, so minimum disruption to users.	More complex to implement. For KB articles, links containing these numbers will be broken and may require some manual work to correct.
Offset the number of all migrated records by a large number (e.g KB0000001 -> KB9000001)	Easy to implement Embedded numbers in knowledge links could potentially be updated by Precision Bridge during migration.	All  numbers will be changed, requiring some re-education of end-users searching for records. Possibility of conflicts occurring later if the number series is not managed carefully
Offset the number of all migrated records by a large number (e.g KB0000001 -> KB9000001) only for records where a duplicate is detected.	The number of records where numbers are changed is kept to a minimum, so minimum disruption to users. Embedded numbers in knowledge links could potentially be updated by Precision Bridge during migration.	More complex to implement. For KB articles, links containing these numbers will be broken, and may require some manual work to correct. Possibility of conflicts occurring later if the number series is not managed carefully
Let target instance generate new numbers for only records where a number conflict is detected	The number of records where numbers are changed is kept to a minimum, so minimum disruption to users.	More complex to implement. Any references to numbers embedded in the text elsewhere will be incorrect. For KB articles, links containing these numbers will be broken, and may require some manual work to correct.