SAP Knowledge Base Article - Public

2770495 - What are Picklist Migration Conflicts and how to prepare for migration - Pre Picklist Migration


  • What is a picklist migration conflict?
  • What options do I have available to manage the conflicts?
  • What are some examples of conflicts that I can find?
  • What are the advantages and disadvantages of "Keep Separate" and "Merge Picklists" decisions?

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.


  • SAP SuccessFactors HXM Suite
  • Metadata Framework (MDF)

Reproducing the Issue

  1. Navigate to Admin Center > Manage Picklist Migration Conflicts.
  2. You are taken to the "Validation Check & Merge Tool for Picklist Migration" page.
  3. A list of conflicts appear in the "Decision Required" Tab like the example below:



The Merge tool uses a number of criteria to determine whether a pair of legacy and MDF picklists are the same or a "perfect match". These criteria include:

  • same parent-child relationship, if any
  • same amount of picklist values*
  • for each picklist value:
    • same external code
    • same status (e.g.: active/inactive)*
    • same number of locales (translations)
    • same label for each locale

If any of these criteria are not met, the two picklists are only considered a "partial match".

* NOTE: Legacy values with DELETED status are not considered for migration, they are ignored by the comparison. On the other hand, status OBSOLETED in Legacy is considered for the migration and equivalent to INACTIVE in MDF. This means that any OBSOLETED legacy values must have a matching INACTIVE value in MDF, whilst any DELETED legacy values should have no matching value in MDF.


What is a picklist migration conflict?

Suppose that there is a legacy picklist and an MDF picklist with the same ID (regardless of case), but they are not EC2MDF mapped. When we run the pre-migration check, they will show up in the Picklist migration conflicts UI as a pair of matching picklists. If they are perfectly matched (meaning they have exactly the same contents), they will be automatically merged into one picklist during migration. But if there's any differences (i.e. they are only partially matched), we call this a conflict, and there is decision required for the admin user to make, before the migration can take place.

What options do I have available to manage the conflicts?

Clicking on each row of the table in "Decision Required" tab, a dialog will pop up listing all the options side by side, which helps you identify the mismatches still existing for this picklist pair.

You have two options to resolve a conflict:

Option 1: Use picklist management tools (Picklist Center for MDF picklist, Picklists Management for legacy picklist) to make changes to the two picklists to make them match perfectly. When you’re done, the picklist pair will disappear from this tab and appear on the "No Decision Required" tab instead. You will see there the decision "Merge Picklists" is made for you automatically. They will be merged into one picklist during migration.

Option 2: Click the "Keep Separate" button in the dialog. This will move the picklist pair from "Decision Required" to "Decision Made", which means that you have agreed to keep the two picklists as two separate picklists after migration. Since MDF imposes uniqueness(regardless of case) of picklist id(Code), the legacy picklist will get a different MDF picklist id(Code), while the MDF picklist will get a different LegacyPicklistId.

NOTE: It may appear to you that option 2 is an obvious choice as it doesn't require you to do anything, and the two picklists will remain as two picklists, which is just like now, while taking option 1 means you will spend quite some effort and come back repeatedly(each time after you make changes) to this UI to check if they are brought to the perfect matching state. But if the two picklists are really meant to the same, we strongly recommend that you take the trouble now to have them merged. Because merging two picklists is almost impossible before or after migration (Picklist Migration is the only chance for you to merge a pair of legacy and MDF picklists). Later you may regret not having done so when faced with the trouble and confusion of maintaining two picklists with similar contents and similar id's.

What are some examples of conflicts that I can find?

Let's see some examples to better understand the consequences of these two options:

Example 1:  Perfect Match and Merge

perfectMatchAndMerge1.png          perfectMatchAndMerge2.png

Example 2: Partial Match and Keep Separate

partialMatchKeepSeparated1.png  partialMatchKeepSeparated2.png

Due to id collision, the MDF picklist gets a different legacyPicklistId with suffix ~MDF, and the migrated legacy picklist gets a different MDF picklist id(Code) with suffix ~LEGACY.
Before March 2020, we used to use the suffix ~%1, which could cause the illusion that the renamed picklist was a duplicate created mistakenly during migration. But it actually used to be a legacy picklist which now becomes an MDF picklist.
In some extreme cases, where there are multiple legacy picklists whose id's only differ in case (e.g. EmployeeClass, EMPLOYEECLASS, employeeclass, etc.), they may get suffix like ~LEGACY1, ~LEGACY2, ~LEGACY3, etc. Because MDF picklist id has to be unique case-insentively, while legacy picklist id is case-sensitive.

NOTE: We generally recommend customers to avoid changing the id(Code) of MDF picklists, unless they really feel absolutely necessary to rename and are able to identify all the references and take backup of the usage data. But for a migrated legacy picklists, since its MDF picklist id(Code) is newly generated, it is ok to change it (to better distinguish it from the MDF one) before it is referenced in any new places.

What are the advantages and disadvantages of "Keep Separate" decision?

The main advantages are:

    • Picklists will be working as before
      • If the picklists are intended to be different, or when there is a possibility in the future that the two picklists(which are being used in different places for different purpose) can deviate in contents, then it is better to keep them as two separate picklists.
        For example: There's one picklist "Countries" used only in Recruiting, and another one used in everywhere else. The one for Recruiting may need to have different labels for embargo'ed countries due to compliance regulations.
    • Nothing is needed for migration to happen
      • All you need to do is clicking on the "Keep Separate" button, indicating you are aware of the consequence and agree on this operation. 

The main disadvantages are:

    • Maintaining two or more copies for the same picklist
      • Whenever you make the change, you have to remember to do it for each of these picklists.
    • Risk of configuring a wrong picklist
      • Since their id's are similar, you have to remember which one is referenced in which place, and during configuration there's a risk of picking the wrong id.

Automatic picklist migration decisions ("No Decision Required")

Under tab "No Decision Required" of the Manage Picklist Migration Conflicts tool, you might find a list of decisions automatically taken. Please refer to KBA 2901125 - Automatic picklist migration decisions ("No Decision Required") - Pre Picklist Migration to learn more about the criteria for such decisions and how to change them.

Other Pre Picklist Migration issues

Please refer to KBA 2816514 - How to Resolve Pre Picklist Migration Issues for a list (with resolution steps) of each type of conflict you might find in the Manage Picklist Migration Conflicts tool.

See Also


Picklist Migration,  Conflicts, perfect match, partial match, decision, MDF Picklist, Picklist Center, Picklist Management, , KBA , LOD-SF-PLT-PCK , Picklist Management Issue , LOD-SF-MDF-PKL , Picklists , Problem


SAP SuccessFactors HXM Suite all versions