As you may already be aware that SAP SuccessFactors will be migrating all the customers from legacy picklist to MDF based Picklist tool called Picklist Center that will be a one stop shop to maintain customer picklists across Success Factors BizX suite. In this blog, my goal is to de-mystify MDF picklist migration process and help you understand why are we doing this, what is our value proposition, what you as a customer or implementation partner need to know to be prepared to make this transition as smooth as possible and what can you expect when your instance is ready to be migrated. The good news is that we will be doing this migration for you but here are few things that will help you prepare for this.
Why are we doing this?
Here are some current limitations with our legacy picklists that we are trying to resolve with this migration
- Legacy Picklist Management is cumbersome as we need to download the entire picklist file, filter the picklist we want to change, make the changes and then upload the file again.
- Picklists do not require unique, mandatory external codes creating problems with managing them across landscapes (Dev/Test/Prod) and updating parent-child relationships is a manual task as it uses OptionID instead of externalCode which is extremely painful as it varies across instances.
- There is no delete capability for legacy picklist values.
- Legacy Picklists is not effective dated which does not give us any visibility to values that changed over time.
- Sorting in legacy picklists is challenging if values are not alphabetic
- Numbers don’t work – e.g., 1 through 10 is sorted as 1, 10, 2, 3, 4, etc.
- Concepts don’t work – e.g., Low, Medium, High is High, Low, Medium (alphabetically)
- Ranges don’t work - e.g., 1-10, 11-20, 21-30
- Implementation partners & customers do not have a common location where the default picklist content is stored (e.g.,SuccessStore)
What is our value proposition for you?
- Single UI to Manage all Picklists
Admins will be able to change a single or subset of Picklist values through a single UI which will be common across the suite
- Creating mandatory, unique external codes for Picklists
Through both the UI (#1 above) and the Import/Export mechanisms (Tool & Scheduled Job) the user must input unique external codes for the picklist. This will provide ability to move picklist values across instances and will result in consistent mapping of parent child relationship across instances.
- For delivered/seeded Picklists, unify on a single, suite-wide common set of Picklists
For delivered picklists, users only have to manage their picklist only once that can be used across entire SuccessFactor suite.
- Allow Effective Dating
Users should be able to effective date picklist values so that only the values that are effective as of the record's effective date are shown in the drop-down list. It is up to individual modules to use the effective dating on the picklist. Employee Central will use the effective dating to show picklist values. Existing legacy picklists will be converted with the effective date of 01/01/1900.
- Allow Backward Compatibility
Migration is designed to be backward compatible and will not require customers to change their reports, interfaces and business rules that are built on legacy picklist values as we will internally store cross reference to old option ids that was used by the legacy picklists
Process of Migration
We are doing this Migration in waves and it will be scheduled and will be done for a certain number of customers at a time for all their instances. When we are ready to migrate your instance, we will run a picklist diagnostic check in your instance and will reach out to you in case there are any picklist data issues or any conflicts where we need you to make decisions or to resolve any conflicts related picklist data issues.
You will get an email at least one month before the picklist migration is scheduled. You will be provided instructions on how to resolve data conflicts and also to resolve your picklist data issues.
Preview instances will be migrated 1 month before the production instance. For customers who don’t have a preview instance, all instances will be migrated at the same time. However, you will be notified in advance to prepare and resolve any picklist conflicts and data issues.
Data Transformation
In Legacy Picklist all picklists had a unique Option Id and in MDF picklist all picklists will have a unique external code. Legacy pickiist may or may not have external code. If there is no external code, the system will generate a unique external code for each picklist when it is converted to picklist.
Legacy picklists also allow to have the same external code for values within one picklist. Post migration, the system will generate a unique external code for the external code field for MDF picklist and will store the code from the legacy picklist in Non-Unique external code field on MDF Picklist table. This is a new field that will be available post migration in the MDF picklist table. Example if you have your marital status picklist that has the same external code ‘M’ for’ Married’ status for all countries, the migration will generate a unique external code for each ‘Married’ status for all your countries and ‘M’ will be stored as the non-unique external code in MDF picklist table. All configuration, interfaces, reports will be referencing the non-unique external code to avoid any impact to configuration, interfaces and reports.
Please Note: If you currently have same external code for multiple picklist values in the same legacy picklist id, we recommend that you turn off ‘Copy External Code to Non-Unique External code’ feature. The system will be migrated with that feature turned on by default.
We also have option Id stored in a hidden field so we can maintain that internal reference of legacy picklist values from employee records. For picklist with unique external code in legacy picklist, the same code gets stored in both Unique and Non-Unique external code fields on MDF picklist table
Preparation
Here are few steps that you can take now to get yourself or your customers ready for the picklist migration
1: Consider adding an external code to your legacy picklists
Download the legacy picklist fie and review all active picklists for missing external codes. Add a unique external code for a picklist where the code does not exist. The migration will not fail if external code is missing, however the system will generate a new external code for you that may not match with your naming convention.
2: Compare and Standardize all values for picklist ids that exist in both MDF and Legacy Picklist.
If you are not using MDF picklist currently, you will not have to worry about this step. However, if you are a customer who has common picklists ids in legacy and MDF Picklist, please read on. It is recommended that you compare all the values in common picklists ids between legacy and MDF picklists. For the system to merge the two picklists ids that exist both in legacy picklist file and MDF picklist file, it is important to make sure all the labels including the translated labels, status and external codes match between common picklist ids that exist on both legacy and MDF picklists tables.
3: Download your legacy picklist file
You must download the legacy picklist file from Picklist Management before the migration is done in any instance. You should also download a before and after conversion MDF picklist file from Import and Export Data that will help us troubleshoot any discrepancy/ Issues that you may run into post migration.
4: Fix all data issues.
Once we run the diagnostic check, we will let you know in advance issues with your picklist data. This diagnostic check will help us identify the following issues:
- OptionIds having invalid parents
For example, Picklist A is a child of Picklist Z, but Picklist Z does not exist.
- Picklists having cyclic dependency for parent option id
For example, Picklist A is parent of Picklist B and Picklist B is parent of Picklist A.
- Self-reference picklist options
For example, if Picklist A is a parent of Picklist A.
You will also get recommendations on what needs to be fixed. These data issues will need to be resolved before we run the migration in your instance.
5: Merging Picklist
A picklist data conflict is when there is a discrepancy between legacy picklist values and MDF picklist values and we are not sure how to map your existing legacy picklists data into the new MDF picklist fields. Example labels are different for same picklist values. In these cases, we are able to partially match the legacy picklist with its corresponding MDF picklist values and there are some option values that we don't know how to handle, preventing picklist migration. You need to decide how you want us to handle these conflicts.
For this we will enable the Picklist Merge Tool temporarily in your instance. It is only visible in instances where it is needed and it is only used prior to migration. You can use the Picklist Merge Tool to resolve the data conflicts we've identified. Refer to the MDF Picklist Migration Guide on options that are available to you.
6: Create a Test Strategy
Although the conversion has been designed to make sure customers don’t have minimal or no impact to the configuration, reports, interfaces and business rules, but it is critical to know which fields, business rules, interfaces and reports use picklists and so you can test those items post migration. You must focus your testing strategy is on the fields that have picklists that exists both in legacy and MDF Picklist. For the picklists that exists just in legacy you can be assured that it will migrate smoothly unless they are data issues mentioned above. With a good testing strategy in place you can focus your testing efforts in the right direction
Note: This migration will first be done in your preview instance (if you have one) first and you will have a month to do your testing before it is done to your production stack.
Conclusion
This migration has been designed to improve your experience creating, editing, deleting picklists from the overall suite perspective. It provides a single place to manage all your picklists suite wise and will allow you to have standardize picklists across the suite and across all your instances.
Migration requires minimal effort form the customer as data migration, conversion will be handled by SuccessFactors. If you follow the preparation guidelines and if the picklist values between legacy and MDF picklists match and are consistent, you can be assured that you will have no issues and data Conflicts to resolve when we are ready to migrate you over.
References:
Follow the instructions in the MDF Picklist Migration Guide to help you find and fix all data issues
Blog: Picklist Migration Blog on our Community
- SAP Managed Tags:
6 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
