LMS and TMS Integration: The Real Cost of Disconnected Training Data

When you have data silos in L&D, it means that your data on training is fragmented between systems that do not maintain a single record, generally TMS containing attendance information and LMS containing course completions, and there is nowhere where both of them are reconciled altogether. None of those two systems are wrong – their problem is that neither of them can be used individually by a coordinator, compliance leader, or an executive who needs a report.

This article will discuss the implications of this situation: what kind of costs it brings, what a typical week looks like for a training coordinator who needs to reconcile attendance from TMS with course completions in LMS, why merely integrating those two systems is not enough, and how things get different when all data is stored in a single system.

What Is a Data Silo in L&D?

Training data silo refers to any training-related data that is gathered and stored in systems that do not automatically connect through common schema, IDs, or updating at the same time with each other. For the majority of training providers, this refers to a training management system tracking the scheduling, assigning instructors, and attendance being separate from a learning management system tracking the completion of courses, scores on quizzes, and certification.

This is not a theoretical model but rather the natural arrangement of the systems in place for the majority of training providers using both classroom and e-learning programs. The reason the TMS was created is because it manages the logistics of live training programs while LMS deals with delivering and tracking the content. The problem is that no one predicted the issues that would arise at the junctions of those systems where someone’s attendance information from one system should be connected with the completion data from another.

An example of a data silo is not a broken system; it is two perfectly fine systems without any common point of truth.

What Does a Disconnected TMS and LMS Actually Look Like Day to Day?

Disconnection between a TMS attendance log and LMS learner record results in a few particular and recurring symptoms:

• Manual transfer of data back and forth between TMS attendance log and LMS learner record by using a spreadsheet.
• Dual accounts of learners in each of the systems and lack of synchronization between them as time goes by.
• Manual compliance report based on comparing the information from two spreadsheets to confirm that a learner both attended a session and successfully passed the related content.
• Lack of immediate certificate issuance due to the need to confirm attendance and completion in two separate databases.
• Contradicting information about the same learner depending on which system was checked first.

It does not seem like an obvious failure. All the symptoms mentioned above are easily manageable, hence the reason why they continue existing for years and years. It is not a matter of failure but a sum of small actions, which will be repeated over and over again.

None of these symptoms is dramatic by itself, which is precisely why they survive budget review year after year.

What Does a Realistic Week of Reconciliation Work Actually Cost?

A practical example of a week of work involved with reconciliation between an unconnected TMS and LMS would include a few hours of time diverted away from the delivery of training pulled apart between exports, reconciliations, and correcting any mistakes, as opposed to one single time frame.

Here’s what a week of work like that entails.

• Monday: Export attendance list from the TMS for last week. Compare against LMS completion list to check which learners attended and completed their modules. Mark any discrepancies where learners show up as “attended” without completion, or “completed” without having attended.
• Tuesday: Follow-up on those discrepancies. In some cases, it’s simply a timing issue, where the LMS hasn’t yet synced. Some are legitimate gaps, such as a learner who left a training module before it ended, but was recorded as attended. Every discrepancy requires going back through both systems by hand to solve.
• Wednesday: A corporate client or compliance officer requests a record of training for auditing. This task means combining attendance data from TMS and certificate data from LMS into a single file.
• Thursday: New enrollments for the week have to be manually entered into both systems separately, because a learner enrolled in the TMS for a live session doesn’t become a learner in the LMS.
• Friday: Monthly reports. The leadership wants a single number – how many learners completed the training during the month. The fact is that there is no such number available natively in any of the systems; it has to be created manually once again using two exports without common learner identifier.

These are the usual activities that do not suggest any mismanagement of the training process in any way. This is just the ordinary work of the coordinator for two systems that weren’t designed to use a single database in the first place. The time wasted in performing these tasks is not spent on instructional design, clients’ relationships or any improvement of the training program, and this is a cost that will never appear in any budgetary line.

This week is not presented by any line item in the budget, which is the reason it will never be changed and considered to be “normal” work.

Why Does Integration Get Sold as the Fix, and Where Does It Fall Short?

Integration is presented as a solution since it’s the natural follow-up step for recognizing the lack of connection between TMS and LMS as a problem: create a link between them using API or middleware, and have data exchange automatically rather than manually. Integration is the standard conclusion reached in vendor guides on this topic. It’s a much better solution than manual reconciliation. It’s not the same as creating one system though.

And here are the ways integration fails to resolve the issue:

• Somebody has to maintain integration anyway. Each connection between systems is another component of the infrastructure. Any change in the data schemas or API version on behalf of any of vendors breaks the connection. This has to be noticed and fixed.
• It creates more technical debt rather than a solution. Over time the accumulation of the costs of managing connections, workarounds, and software extensions turns into additional recurring expense. Such expenses tend to be underestimated at the time of implementation.
• It produces duplicates, only kept consistent. Integration maintains consistency of two databases, it does not merge them into one database. Sync delay, failure of a webhook call, or partial update can still lead to a situation when a mismatch has to be detected manually.
• It does not solve the initial question. Why do a training organization need two systems each with its own data model which require additional efforts for maintaining connection between them?

This is the part of information that is often overlooked in vendor content. The message is almost always “integrate your stack”. Nobody ever says “question your need in two stacks connected by integration”.

Integration is a better solution than manual reconciliation, but it is still a solution. Staying in sync is not merging into one database that was never separated.

What Changes When TMS and LMS Data Live in One System Instead of Being Connected?

In the case of native cohabitation of both LMS and TMS data sets in one platform, reconciliation disappears since there is no need to maintain consistency between two data sets connected via connector. This means that attendance and completion data are part of one learner record, updated in the same place in real time.

If we will apply it to the same week as before:

• Monday: no need for export and cross-check as attendance and completion data are already in the same system and no reconciliation is needed;
• Tuesday: the problem of tracking down the mismatching becomes very small since a learner’s status is either consistent in one place where it is stored or there is only one data entry to make;
• Wednesday: the problem of requesting an audit turns into creation of report about one learner record in one system.
• Thursday: the problem of double-enrollment disappears since the learner registered in the live session is already existing in the system as a learner, no additional LMS enrollment is needed;
• Friday: there is already information about the learners needed for monthly number report available in the system.

It is important to note that this doesn’t mean that the unification of the two systems removes all operations: scheduling, coordination with instructors and content management require effort. However, it removes the extra effort required for reconciliation of two systems.

The work doesn’t disappear, running training is still work, but the specific hours spent making two systems agree with each other do.

How Do You Know If Your Training Data Is Actually Siloed?

The most obvious indication that your data is siloed is quite simple: ask someone to give you an accurate report showing which learners attended a required session and did the coursework for the session last month. If you receive an answer indicating that you need to open two separate systems and then manually reconcile the data, your data is siloed, no matter how good either system works

Other clear indications:

• Your team maintains an “unofficial” shadow spreadsheet that everybody actually trusts more than the reports available in either system.
• Compliance audits require days of preparation instead of minutes, because you need to gather your records from multiple sources.
• Two people generate “the same” report from two systems and receive different numbers.
• Creating an account for a new learner is done in two steps, not one

Research on data quality generally supports why this is important. IBM’s research on data quality shows that fragmentation and lack of reconciliation result in predictable costs: delayed decision making, decreased trust in reporting, and rework across teams. This happens no matter what kind of fragmented data you are dealing with: a supply chain, a sales pipeline, or a fragmented training program that spans across a TMS and an LMS.

If producing one accurate report requires opening two systems, the data is siloed, no matter how well each system performs individually.

Curious how it works without the manual reconciliation?

Check out Unified Reporting in SimpliTrain →

FAQ