Planning out data migration from legacy learning systems into a new SF LMS instance can be one of the more challenging aspects of an implementation. What data to bring over, how it will be formatted, and how many years of learning history to migrate are topics that should be brought up in the initial phases of the project, as clients often need a while to ruminate on the decisions. Any mistakes made can be very time consuming and expensive to clean up (imagine trying to fix hundreds of thousands of history!).
After managing several LMS data migrations over the last two years, I’ve come up with a “cheat sheet” with some tips and tricks to make the migration of learning items as smooth as possible.
1) Uniform revision dates across all migrated items: Almost every client I have worked with has used a uniform revision date across all items (for example, Jan 01 2016 12:00:00). This is very helpful when using the item connector to update details once you have already done an initial upload. For example, if the client wants to make changes to the descriptions of uploaded items, they only need to provide the item type and ID; you can then easily add the Jan 01 2016 revision date to the items. Using no revision date or a new one will result in a new revision of the item. This will cause headaches if the item is already in use and assigned to users.
2) Item classifications: There is no field on the connector to tell the system what classification to make the item (instructor-led, online only, blended, or other). Instead, the system uses the following combinations of the segment length (CPNT_LEN) and online completion status (CMPL_STAT_ID) fields used on the item to determine the classification.
- Instructor-led: Segment length populated, online completion status blank.
- Online only: Segment length blank, online completion status populated.
- Blended: Both segment length and online completion status populated.
- Other: Neither segment length nor online completion status populated.
3) Item currency: This is important for clients that are using multiple currencies within their organization. There are fields on the item connector to indicate the default price and currency on the item. However, if the currency used on the connector is different from the system default currency, the system default price will still populate on the item at $0 cost. For example, let’s say your system currency is USD. The Canada branch of your client uploads a course with the connector set to $100 CAN. When the item is made, it will be set to cost $100 CAN or $0 USD 0 which is not what the client intended.There is an easy solution to avoid this – at the time of upload, temporarily switch the system default currency to the currency being used in the connector. Once the file is uploaded, switch the default currency back.
4) Item custom columns – Many clients use custom columns on their items to capture additional information about courses. However, during initial implementation, I’ve seen many systems setup with single digit column IDs (column numbers 1, 2, 3, ect). Unfortunately these columns are not supported in the connectors. The item connector custom fields map back to column IDs 10, 20, 30, ect. For example, COL_NUM1_VAL= item custom field 10 (even though the digit in the header field is just a single “1”). Because of this, it is important to prioritize the item custom fields with IDs 10, 20, 30, 40, and 50 to hold data that you intend to bring over in the migration process, and use all other field IDs for data you’re maintaining directly in the LMS.
5) Legacy IDs – Many clients change the formatting of their item IDs during the migration process. In that case, there is not a 1:1 match between legacy IDs and SF IDs. While some clients do a good job of maintaining the mapping, others have lost it along the way. These mappings become especially important during the migration of history and scheduled offerings. I highly recommend either using the comments field or an item custom column to capture the legacy system ID. That way, if the mapping is every needed again, admins will not have to go through the arduous process of re-mapping all their courses again.
Thanks and I hope this helps with your implementation!
UPDATE: There was a question posed to me about the CPNT_LEN field. The connector is unfortunately limited to only one default segment. If you put the total segment hours of a course in this field, when an admin first attempts to schedule the item, it will default to one segment at that length. For example, if a course is two days long, eight hours a day, many clients put 16 in that field. If that is done, when a course is first scheduled, the default will be one segment that is 16 hours long. Admins will have to go through the items that have multiple segments and update to the correct settings for scheduling. It is this reason than many clients just use a default “1” in that field for multiple segment items and then just do a manual update in the system.
There is a suggestion on the SF community about updating the connector to make the segment length process easier – kudos it here.