How do I migrate historical learnable data across accounts?

This article is meant to accompany the step-by-step guide found in our community here.

We want to start by saying that the BEST way to avoid having to do a lot of historical data migrations is to ensure that you’ve optimally set up your account from day one. We expand on the reasons for using smart groups and sub-accounts here.

If you find yourself in a position where you sub-account’ed and you should of smart-group’ed (or you had to sub-account and, for admin purposes, you now want to smart group) or if you need to move learners to a sub-account from your root account, this is your guide.

In this article we’ll focus on migrating courses, Programs, and Journeys from a sub-account into the root account. Please note that checkpoints cannot be historically migrated across accounts, and live trainings are a bit tricky (we give some tips at the very end of this article).

Start by going to Analytics > Transcript and changing the enrollment date to “is any time” and make sure that only the account name with only the users needing migration is selected:

You’ll export the file, while will look like this:

Here are the steps to take to clean it up to be used for uploading into the new account:

  • Delete row 1 (nothing)
  • Delete column A (numbers)
  • Cut the UID from column V and put it in place of the username in column B
  • Cut the Learnable ID from column O and insert to the left of title in column C
  • Delete column E (status)
  • Delete column F (enrollment date)
  • Delete column H (expiration date)
  • Delete columns J-L (re-enrollment date, modification date, required)
  • Delete column N (continuing education credits) through the end of the columns
  • Filter column D (learnable type) for Program
    • Copy and paste these on another doc and save
  • Filter column D (learnable type) for Course
    • This will be what is put into the “Bulk Upload Historical Course Enrollments” tool in the admin settings

When done, it will look something like this:

Before you take any steps forward, you need to confirm a few things:

  • The UID of the user in the historical account matches what will be used in the new account
    • If not, then the UID value in the upload needs to change to match whatever that new value will be (this can be done via a VLOOKUP of the historical UID to the new UID from an outside source)
    • If possible, try to import the user into the new account without any custom fields to avoid generating any auto-enrollments via smart groups; you will circle back to this step once the historical upload is complete so that the course completions can trigger Program completions
  • The learnable IDs match between the historical account and the new account
    • If migrating from Bridge to Bridge, if the courses are all in the root and affiliated to any sub-accounts, the learnable IDs will remain consistent across all accounts; the only need is to ensure that the courses are affiliated to any new sub-accounts if the historical migrations are moving across sub-accounts
    • If migrating enrollments for learnables that were authored in a sub-account, those courses will need to exist in the new account (either in the root itself or in the root and affiliated down to a new sub-account)
    • If migrating enrollments from another tool, a VLOOKUP will be required to cross-reference completions from the legacy tool and align those with the new learnable IDs in Bridge (this can be obtained through the course_templates.csv from the data dump in Bridge)
  • The date format is compatible as mm/dd/yyyy
  • Any courses where you do not want the auto-enrollment rules to be followed should be marked as inactive

But how do I find out which courses are inactive and where do I mark it?!

We thought you’d never ask.

There are a couple different ways to go about doing this, and the key is that (1) you want to confirm that any active enrollment being uploaded with a completion date should follow the proper auto-enrollment behaviors and (2) if a user has a duplicate enrollment that the most historical enrollments are inactive and the most recent is active.

One of the easier ways to do this is to take your spreadsheet and create new sheets for every course ID (you can do this by filtering that column A → Z to aggregate the same courses together).

Highlight the UID column and set a rule to highlight duplicate values:

If there are duplicates, you’ll want to set the most historical completion as “T” value with a new “inactive” column:

In this example, Stephanie and James’ most recent completion of the course “History of Britney Spears” will adopt all of the same auto-enrollment rules (we go over our enrollment setting good-to-knows here). The historial completions will appear in the new learner transcripts and as part of Analytics transcript completions, but Bridge will not automate re-enrollment in any way.

It’s extremely important to upload only one active enrollment for one UID to one course ID. Limitless inactive enrollments can be uploaded.

Once completed, you’ll end up with a file that looks like this one:

And you’re now ready to upload!

You will travel to the bulk historical upload tool in Admin > Tools and drag your file into the designated area:

You will then need to drag and drop the appropriate fields:

  • Login ID = UID
  • Learnable ID = Course ID
  • Due At = Due Date
  • Completed At = Completion Date
  • Score = Score
  • Inactive = Inactive

There are three fields from your CSV upload file that will not require any action (you could delete these from your file for uploading purposes, and it also does not harm for them to stay on the file):

  • Title
  • Learnable Type
  • Status

There are two fields that are generally left empty from the upload tool:

  • Attempts → You can pull this from the course level of the original course if you’d like this granular data point
  • Expiration Date → We recommend using the course metadata to create this rule, which will be triggered by the upload

It will look something like this:

After hitting “finish” in the top right corner, you will be notified of the number of updates that were made in the instance. You will have the option to move forward or cancel.

For the “History of Britney Spears” course, there were four historical uploads:

All were accepted by the tool and populated in the UI with the inactive enrollments in gray:

Note that it can take some time and page refreshing to see everything at every course level.

What about that “Program” file that I’d saved and put away somewhere?

Great question! You’re now ready to add learners to Programs.

If you were able to upload the user without any custom fields to mitigate enrollments from smart group affiliation, you can now go and add those custom fields, which should then add those users to the smart groups and trigger Program enrollments.

Programs will not accept inactive enrollments. 

Active enrollments with completion dates will propagate the completion date of the Program. In this example, Stephanie and James both have active enrollments for “History of Britney Spears.” This course is the only course in a Program called “90’s Pop Icons.” James is overdue and Stephanie completed the course on 11/27/22.

When exporting enrollments at the Program level, James is showing overdue for the Program. Stephanie is showing as having completed the Program on 11/27/22.

In this scenario, the Program does not have any expiration settings and is adopting the course settings.

All of this happens in real-time when adding the users to the Program where they have active course completions for the courses in that Program. The most recently completed course in the Program will influence the overall completion date for the Program itself.

If you do need to migrate checkpoint completions, you can create shell courses for those checkpoints. What this means is that you’d create an empty course that is only published in the background with a course ID. You could then do a bulk upload of completions to that course ID, which would really just be an affirmation that the checkpoint was completed in the historical account. This process wouldn’t allow for the uploading of evidence, but it’s a way to bulk migrate the checkpoints without having to manually assign and masquerade as users.

As far as live trainings, you can use the same process for checkpoints above to go the same route with shell courses. The easiest way to export live training sessions is through the specific sessions themselves in the historical account. That file will require a cross-reference to the users file from the data dump/Download All Data page to gather the UID. If using shell courses, you could bulk upload those completions as presented here. 

To keep them categorized as live trainings, you would then need to one-for-one upload these files through the “add via CSV” option in the sessions within the new account. If the session is in the past, user attendance will automatically be checked off. The completion date will be listed as the date of the session; however, the date attendance was entered will always be the current date for when the session registrations are uploaded.

Please reach out to support@bridgeapp.com with any questions!

PS. We do offer this as a paid service if you are needing more detailed assistance.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request