SCORM Compliant LMS: What Compliance Really Means

Somebody wrote "must be a SCORM compliant LMS" into the requirements document, and now you are reading vendor pages trying to work out whether the tick in their feature list means the same thing as the tick in the requirement. It almost certainly does not. The requirement did not say which version. The vendor page did not say which direction. And nobody in the chain, from the person who wrote the line to the person who will sign the contract, has said out loud what would count as proof.

This is not a small gap. SCORM has four living versions, two directions, and three different words that vendors use interchangeably while only one of them involves an outside party checking anything. A platform can honestly claim compliance and still be useless for your actual job, because your job is to hand a package to a client and theirs was to accept one from a vendor. Those are opposite ends of the same standard, and the marketing page treats them as one word.

So here is the whole thing laid out. What the standard is and who owns it. Where 1.2, 2004, xAPI and cmi5 genuinely differ in ways a buyer meets rather than ways only a developer meets. Which of the three words on the sales page carries weight. Four situations where the requirement is real and three where somebody copied a template. What a package looks like when you unzip it, and how to check one before you hand it over. Then six questions to put to a vendor, and a plain statement of which direction our own product handles, since it only handles one.

What does a SCORM compliant LMS actually have to do?

That is the runtime half. There is a second half, packaging, which says how the course files get bundled and described so a machine can unpack them without a human explaining the folder structure. A platform that does both directions of both halves is fully conformant. A platform that does one direction of one half will still often say "SCORM support" on the pricing page, and technically not be lying.

The standard came out of ADL, the Advanced Distributed Learning initiative, a research effort funded by the United States Department of Defense. That origin explains a lot about SCORM's shape. It was built so that a very large organisation buying training from many suppliers could stop being held hostage by each supplier's proprietary player. The problem it solves is procurement, not pedagogy. If you keep that in mind, most of the confusing parts stop being confusing.

The three words, and only one of them means somebody checked

Compliant. Conformant. Certified. They appear on vendor pages as if they were the same claim at different levels of formality. They are not.

SCORM.com, run by Rustici Software, publishes the definitions the industry works from. Their wording, checked in August 2026, is worth reading slowly: both conformant and compliant mean that a product was developed to the SCORM standards and the vendor has most likely passed the self test suites, but this fact has not been verified by an independent testing agency. Certified means something narrower and harder. It means the product has been certified by ADL, the governing body for SCORM, which requires passing the SCORM test suites and going through the testing process with ADL.

Read the middle clause of the first definition again. Most likely passed the self test suites. Not "has passed". The claim as commonly made is that the vendor believes their implementation follows the standard. It may well. Nobody outside the vendor has looked.

This matters less than it sounds and more than it sounds, at the same time. Less, because the self-test suites are the same tests the formal auditors run, and a vendor who has genuinely passed them is in good shape. More, because there is a large gap between a vendor who ran the suites and fixed everything that failed, and a vendor whose developer once loaded a package successfully and wrote "SCORM compliant" on the roadmap.

The practical move is not to argue about the word. It is to ask for the artefact. If a vendor is certified, they can point you at their listing. If they are not certified but did run the suites, they have logs, and logs are a file they can email you this afternoon. SCORM.com puts it bluntly: a platform that cannot pass the conformance test suite is not SCORM conformant, whatever adjective the marketing page uses.

One caution before you send that email. Certification is expensive and slow, and plenty of perfectly solid platforms have never bothered. Absence of certification is not evidence of a problem. Absence of both certification and test logs, from a vendor who has been claiming compliance for years, is a different signal entirely.

SCORM 1.2, SCORM 2004, xAPI and cmi5: what a buyer can see

Four names get used in the same conversation. Here is the timeline, from SCORM.com's own version history, checked August 2026. SCORM 1.0 arrived in January 2000 as a draft outline of the framework. SCORM 1.1 followed in January 2001 as the first version anyone could really implement. SCORM 1.2 landed in October 2001. SCORM 2004 came in four editions: the first in January 2004, the second in July 2004, the third in October 2006, the fourth in March 2009. xAPI was released in April 2013. cmi5 followed in June 2016.

That is twenty-three years of standards for one job. What you need is not the history but the handful of differences that will reach you as a buyer.

SCORM 1.2, the one people mean

Released October 2001 and, in SCORM.com's phrase, still the industry workhorse. If a requirements document says "SCORM" with no version, this is what everyone will assume, and everyone will be right often enough that the assumption survives.

It tracks what SCORM.com calls the Big Four: whether the learner finished, what they scored, how long they spent, and whether they passed. Status is a single field, cmi.core.lesson_status, which carries values like completed, passed, failed and incomplete. One field for two ideas — did they finish, and did they do well — which is 1.2's most-criticised design choice and also the reason it is simple enough that everything supports it.

Its ceilings are real and low. The bookmark field, cmi.suspend_data, where a course records where the learner got to, is capped at 4,096 characters. That is enough to store a position and a few flags. It is not enough to store a long branching state, which is why courses that push against this limit start doing clever compression and then start losing progress in ways nobody can reproduce.

Its recording of individual questions is thin. You get an aggregate score readily. Getting per-question detail out of a 1.2 package into an LMS report is possible but limited, and different implementations disagree about the edges.

SCORM 2004, the one that added order

The headline addition across the 2004 editions is sequencing and navigation. Sequencing governs what happens between modules and outside them: which module unlocks next, what the learner is allowed to skip, whether failing one sends them back. In 1.2 the LMS decides that. In 2004 the content decides it, and the rules travel in the package.

Related to that, rollup responsibility moves. In 1.2 the LMS handles rolling multiple modules up into an overall result. In 2004 the content signals when its data is ready to be rolled up. That is a real improvement for complex multi-module courses and a source of subtle disagreement between implementations for everything else.

The data model got more generous. Status splits into two fields, completion and success, separately trackable, which removes 1.2's most awkward ambiguity. Interactions and objectives are richer, with room for the full question and answer text. The bookmark ceiling rises from 4,096 characters to 64,000, which is enough that you will probably never think about it again.

And 2004 tightened conformance itself. Under 1.2, an LMS could implement a subset of the data model elements and still call itself conformant, which is exactly how "it works in their LMS but not ours" became a genre of support ticket. SCORM 2004 requires the full data model.

The API object is renamed too. Packages look for a JavaScript object called API under 1.2, and API_1484_11 under 2004. That single rename is why a package built for one will simply fail to find the other and sit there reporting nothing, with no error a learner would understand.

Of the four editions, the third from October 2006 saw the widest use. If somebody says "2004" without an edition, that is usually the safe guess, and it is also the guess you should confirm rather than make.

xAPI, which is not an LMS standard

Released April 2013 and often introduced as SCORM's successor, which sets the wrong expectation. xAPI is not a packaging format and does not require an LMS at all. It is a way for any application — a course, a simulator, a mobile app, a piece of equipment on a factory floor — to send statements about what somebody did to a store that keeps them. Actor, verb, object. Somebody completed something. Somebody attempted something.

That freedom is the point and also the catch. xAPI will happily record that a technician watched a safety video on a phone with no LMS involved. What it does not do on its own is tell an LMS how to launch a course, how to authenticate the learner, or how the course should be structured. Those were the boring, essential things SCORM specified, and xAPI deliberately left them out.

So if a tender asks for SCORM and a vendor answers "we support xAPI, which is better", the answer is not responsive. It may be true that xAPI is better for the vendor's use case. It is not an answer to the question of whether a package will load.

cmi5, the bridge

Released June 2016. cmi5 is an xAPI Profile: it inherits everything xAPI mandates and then adds back the rules xAPI left out. Interoperability rules for launching content, for authentication, for managing the session, for reporting, and for describing course structure. The unit an LMS launches is called an AU, an assignable unit.

In other words, cmi5 is the attempt to give you SCORM's procurement guarantees with xAPI's tracking freedom. It is the sensible destination. It also appears in far fewer tenders than SCORM 1.2, and if you buy on the assumption that cmi5 support satisfies a SCORM requirement, you will find out at the worst possible moment that it does not.

None of this is an argument for buying old technology. It is an argument for answering the question that was actually asked. If your requirement says SCORM, cmi5 support is a bonus, not a substitute. This same trap shows up when teams shop for tools to build the courses in the first place — we went through the tiers and which of them can produce a package at all in the guide to eLearning authoring tools.

The direction nobody asks about

Here is the question that separates useful vendor claims from decorative ones, and almost nobody asks it. Which direction?

SCORM support means one of two entirely different capabilities:

• Import and play. The platform accepts a zip somebody else built, unpacks it, hosts it, launches it in a frame, provides the API object, and records what comes back. This is what "SCORM compliant LMS" means in its strictest reading, and it is what you need if you buy off-the-shelf compliance courses or receive material from a partner.
• Export. The platform lets you build a course inside it and then produce a zip that somebody else's LMS can import. This is what you need if your material has to end up inside a client's system, a parent company's system, or a customer's academy.

A platform can do either, both, or one badly. The feature list rarely distinguishes them. "SCORM 1.2 support" on a pricing page could mean a full player with a certified runtime, or it could mean a download button that produces a zip.

Work out which direction you need before you shortlist anything, because the answer eliminates most of the list. If the material has to run inside somebody else's system, a platform's player quality is irrelevant to you and its export quality is everything. If you are receiving packages, the reverse. Teams that skip this step end up with a platform that ticks the box and cannot do the job, which is a particularly annoying way to be wrong. It is the same class of mistake as buying a system for the half of the problem you do not have, which we walked through for the wider category in the piece on which half of training management software you actually need.

What actually happens when a package runs

You do not need to be able to write this code. You do need to recognise the shape of it, because every failure you will ever debug is one of these five steps not happening.

Step one: find the API. The LMS launches the package in a frame or a new window, and attaches a JavaScript object to the launching window. The package has to go looking for it — up to its parent, then that window's parent, all the way to the top, then across to the opener window and up that chain too. It is looking for an object called API under 1.2, or API_1484_11 under 2004. If it never finds one, the package usually carries on displaying content perfectly while recording nothing at all. This is the single most common SCORM failure, and its symptom is not an error message. Its symptom is a report full of zeroes.

Step two: open the session. The package calls LMSInitialize(""). The LMS creates or reopens the learner's attempt record. Nothing else may happen until this returns true.

Step three: report as you go. As the learner works, the package calls LMSSetValue with data model elements. The ones that matter to you are cmi.core.lesson_status for state, cmi.core.score.raw with its min and max companions for the score, cmi.core.session_time for duration, and cmi.suspend_data for the bookmark that lets somebody resume. There is also cmi.core.exit, which when set to suspend tells the LMS to keep this attempt open rather than starting a fresh one next time.

Step four: commit. LMSCommit("") tells the LMS that what it is holding is worth writing to disk now. Well-behaved packages commit at checkpoints rather than only at the end, because learners close tabs.

Step five: close. LMSFinish("") ends the session and lets the LMS finalise the record. Skip it and an attempt can hang on incomplete indefinitely, which is how a learner who genuinely finished shows up in the compliance report as outstanding.

Now, three practical consequences of that sequence.

The first is that pop-up blockers and frame policies break SCORM, because step one depends entirely on the package being able to see the launching window. A well-meaning security change to a corporate browser policy can silently take out a whole training programme.

The second is that scores are whatever the package sends. The LMS does not mark anything. It records. If a package's own logic is wrong, the LMS will faithfully store the wrong number and every report downstream will agree with it.

The third is that duration is unreliable across implementations. session_time is what the package reports, and packages differ on whether a tab left open counts. Treat time-in-course as a rough signal, never as evidence for anything that matters.

Inside the zip: what a package actually is

A SCORM package is a zip file with rules. In SCORM's own vocabulary it is a PIF, a Package Interchange File. Unzip it and the required piece is a file called imsmanifest.xml sitting at the root — always that name, always that place. The manifest is what makes the folder a package rather than a folder: it declares which SCORM version the content is built for, lists the resources, and identifies which file the LMS should launch.

Inside the manifest you will meet two words. A SCO, a Sharable Content Object, is a chunk of content that talks to the LMS. An Asset is a file that does not — an image, a stylesheet, a PDF. A package can contain many SCOs or exactly one.

One SCO versus many is a design decision with consequences, so it is worth understanding rather than accepting.

Many SCOs gives each module its own completion and its own score, which is what you want if the modules are genuinely separate and reusable, and it is the arrangement SCORM's sequencing rules were built for. The cost is that combining those separate results into one course result is the LMS's job, and under 1.2 that is exactly the area where LMS implementations disagree most.

One SCO means the whole course is a single unit reporting a single status and a single score. It is less elegant and dramatically more portable, because every LMS ever built can handle one SCO correctly. If your priority is that the package works first time in a system you do not control and cannot test against, one SCO is the pragmatic choice.

Now the parts that surprise people.

Media makes packages enormous. A course with an hour of video becomes a multi-gigabyte zip that most LMS upload forms will simply refuse. The usual answer is to reference media by link rather than embed it, which works, and which means the package now requires a network connection and a host that stays up.

Nothing a human has to mark can be scored. Essay answers, opinion scales, free-text responses: the package can display them and collect them, and it cannot grade them, because there is no grader inside a zip file. Any honest export will show these to the learner and score them zero, or exclude them from the score entirely. Check which, because the difference changes everybody's percentage.

The answer key ships with the questions. This is the one that makes people sit up. A SCORM package grades offline, inside the learner's browser, with no call home. To grade, it must contain the correct answers. Anyone who unzips the file can read them. That is a property of the format, not a flaw in any particular vendor's implementation. It follows directly from "runs without a server".

The consequence is a rule worth writing on the wall: use SCORM packages for learning and self-assessment, and keep consequential assessment on a system that grades server-side. A certification exam distributed as a SCORM package is an exam with the answers attached. If the score decides a licence, a promotion, or a regulatory record, that grading belongs somewhere the learner cannot inspect. We went through what that separation looks like in practice in the guide to choosing an online quiz maker for staff training.

Four situations where SCORM is genuinely required

One: the material has to run inside a system you do not own. A client requires their staff to be trained in their own academy. A parent company mandates one group-wide platform. A regulator or an industry body accepts evidence only from an approved system. In every case you build the material and somebody else hosts it, and a package is the only way it crosses that boundary without being rebuilt by hand.

Two: procurement is a scored tender. Public sector buying, large enterprise buying, and anything running through a formal RFP will contain a standards question, and it will carry points. Whether the buyer will ever move a package is beside the point. The evaluation is a scoring sheet, and an unticked row is lost points before anyone has looked at your product.

Three: you buy off-the-shelf courses. Compliance libraries, health and safety catalogues, industry certification content — these are sold as packages, and the way you get them into your platform is import. This is the direction where import quality is everything and export quality is irrelevant, and it is worth being explicit about that when you shortlist. The wider question of what a platform must handle at this size is one we worked through in the piece on what corporate learning management systems must do.

Four: you expect to change platform. Not a hypothetical. Training platforms get replaced when the company that bought them is acquired, when the sponsor leaves, when the licence renewal lands on a bad quarter. Courses built inside a platform's own editor and never exported are courses that die with the platform. A package is the closest thing to an insurance policy, and the time to check the export works is while you still have a working login.

Notice what is common to all four. None of them is about the learning. Every one is about a boundary — between companies, between systems, between a contract now and a contract later. SCORM is a boundary-crossing format. If nothing in your situation crosses a boundary, hold that thought.

Three situations where you are paying for a checkbox

One: everyone learns on the platform you already run. Your staff, your platform, your reports, no external party. In that world a package never moves anywhere, and the standard is solving a problem you do not have. This is most small and mid-sized companies, most of the time, and it is a completely respectable position to be in.

Two: you bought it and have never used it. Go and look. Ask whoever administers the platform how many packages have been imported or exported since it was bought. If the honest answer is none, that is not a reason to rip anything out, but it is a strong reason not to pay a premium for the same tick next time. This kind of audit is worth doing across the whole feature list, in the spirit of how to choose and roll out employee training software — the features that get used are rarely the features that closed the deal.

Three: you want the reporting, not the format. A surprising number of SCORM requirements, traced back to their source, turn out to be somebody wanting to know who completed what. That is a reporting requirement wearing a standards costume. If the platform already reports completion, scores and dates, and nothing has to leave, then the standard adds nothing to that particular need. Worth asking the person who wrote the requirement what they were actually trying to see. For smaller teams, that conversation often ends the whole procurement, which is roughly the argument in do you actually need a learning management system for a small business.

None of these three is an argument against SCORM. They are an argument against paying a premium for it before anyone in the building has a package to move.

Exporting a package to hand to somebody else's LMS

Suppose the answer is yes, you need to export. Here is the process, including the parts that go wrong.

Before you build: ask three questions

Ask the receiving side, in writing, before you author anything.

Which SCORM version does your LMS accept? Not "do you support SCORM". The version. If the answer is 1.2, build 1.2. If the answer is "both", build 1.2 anyway, because the wider support is on the 1.2 side and you gain nothing from 2004 unless you need sequencing.

What is your maximum upload size? This decides whether media is embedded or linked, and it is much cheaper to know now than after you have built an hour of video into the course.

Who tests it, and against what? Get a name. "We'll load it and see" is not a test plan, and when it fails you will be debugging somebody else's environment through a chain of three people.

Build with the destination in mind

Keep the structure flatter than you would for your own platform. Sequencing rules that work beautifully in one system are the first thing to behave oddly in another. Avoid anything that assumes a specific window size, and avoid anything that needs a browser plug-in — SCORM.com's own RFP guidance flags plug-in dependencies as a red flag precisely because they are the thing corporate browser policies kill.

Decide the pass threshold now, not later. It goes into the manifest as the mastery score, and the receiving LMS may use it to decide pass or fail on its side. Changing it later means re-exporting and re-uploading.

Keep anything that must be graded reliably out of the package, for the answer-key reason above. If a certificate depends on a score, issue the certificate from a system that verified the score itself. That is a separate mechanism with its own requirements, which we covered in how to issue certificates people can actually verify.

Export, then test before you send

Never let the first launch of a package be in the client's system. Test it yourself first, in this order.

Unzip it and look. Is imsmanifest.xml at the root, not inside a folder? A package zipped one directory too deep is the single most common rejection, and it is the easiest to fix. Open the manifest and confirm the version declaration says what you expect, and that the mastery score is the number you decided.

Check the size. Against the number the receiving side gave you, with room to spare.

Run it in a test environment. Any LMS you can get an account on, or a sandbox from the receiving vendor. What you are checking is not whether the content displays — it will. You are checking whether tracking arrives.

Then check the four numbers. Complete the course as a test learner and go look at the report. Did completion register? Did the score arrive, and does it match what the course showed you at the end? Did a duration appear at all? If you left mid-way and came back, did it resume where you were? Those four answers tell you whether steps two to five of the handshake are working. If content displays and all four are blank, you have a step-one problem: the package is not finding the API.

Hand over with a note

Send the zip with three lines: which SCORM version it is built to, what the pass threshold is, and what it needs from the network if media is linked rather than embedded. Those three lines prevent most of the back-and-forth that otherwise follows, and they make it obvious very quickly whose end a problem is on.

How to check a package somebody sent you

The reverse direction has its own short list, and it is worth running before you tell a supplier their course is broken.

Confirm the version the package declares matches a version your platform imports. A 2004 package in a 1.2-only platform will often import and then track nothing, because the package is looking for API_1484_11 and your platform provides API.

Check whether it is one SCO or many. Multi-SCO packages are where rollup differences show up, so if the overall status looks wrong while individual modules look right, that is your suspect.

Complete it as a test learner and read the report, using the same four checks: completion, score, duration, resume. Do this before rolling it out to a few hundred people, not after.

If tracking is missing, the fastest diagnostic is to ask the supplier which version they built to and whether they tested it anywhere other than their own authoring tool's preview. Authoring tool previews simulate the LMS side, and a preview that works proves the content runs, not that the handshake does.

Six questions to ask a vendor

SCORM.com publishes RFP guidance for exactly this conversation. These six condense it into the questions that separate real support from a feature-list tick, along with what a weak answer sounds like.

Ask this	What a good answer sounds like	What should worry you
Which SCORM versions do you support, and in which direction — import, export, or both?	A specific version list, and a clear statement of direction for each	"We're SCORM compliant" with no version and no direction
Are you ADL certified? If not, can you send your conformance test suite logs?	A certification listing, or the log files by email	An explanation of why the tests do not apply to their architecture
What does a learner see when they open a package — new window, embedded frame, something else?	A screen recording or a demo account you can try	A description that avoids saying whether a pop-up is involved
Where does the data a package reports end up, and can I get at it?	Named fields in a named report, plus an export or an API	"It's all tracked in the system" with no route to the raw values
Does anything need a browser plug-in or a specific browser?	No, and here are the supported browser versions	Any plug-in requirement at all in 2026
Can I have a sandbox that matches production, and load my own package into it?	Yes, here is a login	A guided demo instead of an account you drive yourself

Question six is the one that settles it. Everything above can be answered persuasively by somebody who has never moved a package. A sandbox you can load your own zip into cannot. Take an hour, load a real package, complete it, and read the report. That hour is worth more than every comparison article on the subject, including this one.

Where Orova Training sits, and where it does not

Time to answer the direction question about our own product, since the whole article has been insisting that vendors should.

Orova Training exports SCORM 1.2. It does not import or play SCORM packages.

That is the complete claim, and everything below is the detail behind it. If your requirement is to load packages somebody else built, Orova is the wrong tool and no amount of reading further will change that. Go and look at the platforms whose business is being a player.

What the export produces, precisely: a single-SCO zip containing imsmanifest.xml declaring schema version 1.2 with your course's pass threshold written in as the mastery score, an index.html holding the whole course with a contents list down one side and the marking at the end, a scorm.js that performs the handshake described earlier, a stylesheet, and an assets folder for files that travel inside the zip.

One SCO rather than many, for the reason given above: every LMS handles one SCO correctly, and a course score is one number anyway. Splitting it would mean relying on the receiving LMS to combine scores across SCOs, which is the part of SCORM 1.2 where implementations disagree most.

On the runtime side the package reports cmi.core.score.min as 0, cmi.core.score.max as 100 and cmi.core.score.raw as the percentage, and sets cmi.core.lesson_status to passed or failed against your threshold, completed where there is nothing to score, and incomplete while the learner is still working.

What travels inside the package: text lessons, AI-written lesson content, slide PDFs embedded directly, AI-generated slide decks as HTML, flashcard sets including AI-generated ones, and quiz questions of the multiple-choice and short-answer types.

What is embedded as a link rather than a file: podcasts, uploaded audio, videos and video links. Media of that size makes a zip no LMS will accept, so the package points at it, and the learner needs a network connection for those items. The export says so on the page rather than leaving you to discover it.

What appears but scores nothing: essay questions, scales, dates and times. They are shown to the learner and excluded from the score, because nothing inside a zip can mark them. The package states this on the page too.

And the disclosure the format forces: the answers are inside the package. Orova's export box says so in as many words. A SCORM package grades in the browser with no call home, so the key has to travel with the questions. Use exported packages for learning and self-assessment; when a score has to count, have people take the assessment on the platform, where marking happens server-side. The package and the platform use the same grading function, so a learner who takes the same quiz in both places gets the same score — a detail worth having, because two grading rules running in parallel disagree eventually and nobody notices until a learner complains.

One more thing to know before you export: the language of the package is fixed at the moment you generate it, taken from the interface language of whoever clicks download. The package runs offline in somebody else's system and cannot ask who is reading it. If you need the same course in two languages, export it twice.

What Orova does not do, stated plainly so nobody has to infer it: no import of external SCORM packages, no SCORM player, no SCORM 2004, no xAPI, no cmi5, and no learning record store. One direction, one version, done properly.

Common questions

Is SCORM obsolete?

No, and the question usually comes from somebody selling something newer. SCORM 1.2 dates from October 2001 and remains, in SCORM.com's own words, the industry workhorse. Standards in procurement do not die when something better appears; they die when the last system that requires them is switched off. That has not happened and is not close.

Should I ask for SCORM 2004 instead of 1.2?

Only if you need sequencing — content-controlled ordering, branching, prerequisites enforced by the package rather than the platform. If you need the Big Four and nothing more, 1.2 is more widely supported and less likely to surprise you. Asking for 2004 without a reason narrows your options and gains you nothing you will use.

Does a SCORM package work offline?

The tracking does not. The package grades in the browser without calling home, but it still needs the LMS on the other side of the handshake to record anything, and the LMS is a web application. Content with linked media needs a network for that media as well. "Grades offline" and "works offline" are different claims and only the first is true.

Can I convert a SCORM package to xAPI, or the other way round?

Not by pressing a button in any way you should rely on. They record different shapes of information: SCORM sends a small fixed set of values to an LMS, xAPI sends open-ended statements to a record store. Tools exist that wrap one in the other for specific cases, and they are integration projects, not file conversions. If you need both, plan for both from the start rather than expecting a converter.

Our LMS says it supports SCORM but our package will not track. Where do we start?

Start at step one of the handshake. Confirm the version the package declares matches the version the LMS provides — a 2004 package looking for API_1484_11 in a 1.2 platform providing API will display perfectly and track nothing. Then check whether the package is being launched in a way that lets it see the launching window, since pop-up blockers and frame policies break exactly that. Those two account for most cases. Only after both are ruled out is it worth involving either vendor's support.

How many SCOs should a package have?

One, unless you have a specific reason for more. Multi-SCO packages are the right answer when modules are genuinely independent and reusable across courses, and they are where LMS implementations disagree most under 1.2. If the goal is that a package works first time in a system you cannot test against, one SCO removes an entire category of problem.

What to do with this

Go back to the requirement that started this. Find whoever wrote it and ask three questions: which version, which direction, and what would count as proof. In most organisations at least one of those has no answer, and finding that out changes what you are shopping for.

If the honest answers are "no version specified", "no package has ever moved", and "nobody checks", you have discovered that the requirement is inherited rather than real. That is worth knowing before you pay a premium for it.

If the answers are specific — 1.2, export, and the client's platform team will test it — then you know exactly what to demand from a vendor and exactly how to verify it. Ask for the sandbox. Load a real package. Complete it. Read the report. Check completion, score, duration and resume.

Everything else in this article exists to help you interpret what you see when you do that. The hour spent doing it beats every feature comparison, including this one.