Why self-hosted dealer training changes for manufacturers
A self-hosted Open edX or Moodle platform can serve dealers, installers and end customers from one codebase, with separate audiences, catalogs and certification paths for each group. Whether that works depends less on the learning features than on three things: how each audience signs in, how the catalog is split and priced, and how many languages and regions the platform must cover from day one. Those three decisions should be made before a platform is chosen, because they shape the identity integration and the content model more than any course feature does. Manufacturer training differs from generic course selling in what a certificate means. A dealer or installer certification often authorizes someone to sell, commission or service equipment that can affect people and facilities, so the record of who passed which module, on which product version, becomes part of the product safety and channel story. Installations that connect to industrial or building control networks add an operational technology angle: the training must match what installers actually do on site, and the ISA/IEC 62443 series is a useful reference for the asset owner side of that conversation. Channel contracts add a further layer, since certification may be a condition of partner status, which makes expiry, re-certification and revocation rules as important as the course content. Platform choice follows from those requirements rather than from brand preference. Open edX suits large, multilingual catalogs with strong authoring and course structure needs, while Moodle is often the simpler fit for cohort-based certification with many local administrators. Confirm with each candidate how it handles separate sites or tenants for dealers and end customers, whether it supports the identity providers your partner portal already uses, and how it exports completion records to the CRM. Ask a partner to show these in a working prototype before committing to either platform.
Which regulations and standards shape manufacturer training
This table compares the main regulations and standards that touch manufacturer training, and what each means for training content, certification records and partner portal access. Read each row as a question to answer for your own catalog and audiences, since the rules govern products and plants, but training systems often hold the evidence regulators and auditors ask for.
| Regulation or standard | What it means for training content and records | What to confirm before building |
|---|---|---|
| NIS2 Annex II manufacturing scope | Manufacturers in NACE Rev. 2 divisions 26 to 30 may be in scope as important or essential entities. Training platforms need logs and contact records that support incident reporting. | Whether your entity is in scope, and which systems hold dealer and customer contact data needed for notification |
| NIS2 reporting windows (Article 23(4)) | Significant incidents need an early warning within 24 hours, a notification within 72 hours and a final report within one month. Partner portal and LMS admin accounts must be traceable so the timeline can be reconstructed. | Who on the training team can act on an incident, and whether access logs for partner accounts are retained long enough |
| Cyber Resilience Act Article 14 | Manufacturers' duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026 (Article 71(2)). Security advisories for installed products may need to reach certified installers quickly through the portal. | How advisories reach certified installers, and whether certification records let you identify who was trained on an affected product |
| Machinery Regulation 1.1.9 (from 14 January 2027) | Requires machinery to be protected so that connecting another device does not create a hazard. Installer and dealer courses on network connection and commissioning should carry current, versioned content. | Which courses cover connection and commissioning, and how course versions are tied to product firmware or machine versions |
| ISA/IEC 62443 role split | Asset owners follow ANSI/ISA-62443-2-1-2024 for their security program, while suppliers follow ANSI/ISA-62443-4-1-2018 for secure product development. Training should state which role each course serves so customers do not mistake supplier guidance for their own obligations. | Whether courses are written for asset owners, integrators or product teams, and where role labels appear in certificates |
| NIST SP 800-82 Rev. 3 (OT installations) | Applies where training covers installations that touch operational technology such as PLCs, SCADA or building controls. Content should separate IT account guidance from plant safety and reliability requirements. | Whether any course leads learners into OT networks, and who approves that content before publication |
| Certification records and partner access | Records of who completed which product certification, and when, are evidence of competence for dealers and installers. Partner access should follow least privilege across audiences and catalogs. | How long certification records must be kept, and which partner staff roles can see learner data for other companies |
How dealers, installers and end customers need different catalogs
Dealers are independent resellers who sell and quote your products. They usually need sales-facing training on product lines, pricing rules, configuration and certification before they can sell certain models. Their accounts should come from the manufacturer's partner directory, so that access follows the signed dealer agreement and ends when the agreement does.
- Login source: Partner directory or partner portal identity, federated to the learning platform through SAML 2.0 or LTI, depending on what the partner program already runs.
- Catalog: A dealer-only catalog covering sales courses, pricing and promotion training, and product certification paths that gate partner status.
- Certificates: Certificates that carry the dealer company and the individual name, so the partner portal can check current certification.
- Hidden from this audience: Internal engineering modules, unreleased product content and end-customer course pages.
- Enrolment: Category-based enrolment that places a dealer account into the dealer category when the partner directory assigns the dealer role.
Confirm with your partner program owner which dealer data is shared back to the CRM and whether dealer certificates must expire on a set cycle.
Installers are technicians who fit, commission and service your equipment, often through dealers or as employees of contractors. Their training is hands-on and safety-sensitive, and they may need to prove competence for a specific model, site type or regional code. Installer access often lives in a contractor or dealer directory, which may change faster than the dealer agreement.
- Login source: Contractor or dealer directory identity, with a sub-group per employer so access can be removed when an installer leaves a company.
- Catalog: An installer catalog with installation procedures, commissioning checklists, firmware and safety updates, and model-specific certification tracks.
- Certificates: Time-limited certificates tied to model families, with reminders before expiry and a clear record of the version of the procedure that was assessed.
- Hidden from this audience: Sales pricing, margin information and customer account data.
- Enrolment: Category-based enrolment by installer role and region, so regional language versions and local code modules reach the right people.
Confirm how installer certificates are checked by field and service teams and whether any certificate must be linked to a regulated registration number in your market.
End customers are the owners or operators of your equipment. They need operating, maintenance and safety training, usually delivered free or bundled with a purchase. Because they are not partners, their accounts should be self-managed or created from your customer account system, with strict limits on what they can see.
- Login source: Customer account identity, either a self-registration flow with email verification or single sign-on from the existing customer account system through OAuth 2 or SAML 2.0.
- Catalog: A customer catalog with operating guides, maintenance routines and safety content, separated from dealer and installer material.
- Certificates: Completion records that are useful to the customer, such as operator training records for their own staff, without exposing partner status.
- Hidden from this audience: Dealer pricing, installer procedures marked for trained personnel only and internal enrolment data from other customers.
- Enrolment: Category-based enrolment by customer account type, so a company administrator can enrol staff without seeing other companies' learners.
Confirm your data protection basis for customer accounts and how long learner records are kept after a customer account closes.
Open edX or Moodle: which platform fits which manufacturer
Dealer, installer and end-customer training on one platform is possible on either Open edX or Moodle, but the two differ in release model, staffing and integration effort. The cards below set out what each option asks of your team, and what to confirm before choosing.
Open edX for certification-led programs
Open edX is licensed under AGPL-3.0 and is built on Python, JavaScript and Django, with Studio for authoring and the LMS for learners. Tutor, the official Docker-based distribution, supports Kubernetes deployments, which suits a platform serving several regional catalogs. Open edX supports only the latest named release, so Verawood is supported now, Willow is planned for December 2026 and Xylon for June 2027, and each move is a required upgrade your team or partner must schedule. Cost sits mostly in staffing: the maintainers recommend a service provider or Tutor for production, and bare-metal installs are complex.
Open edX analytics and LTI integration
Open edX Aspects captures tracking logs as xAPI statements through the event-routing-backends plugin, stores them in ClickHouse via Ralph or Vector, and presents them in Superset dashboards. That gives dealer-level completion and certification reporting, but it adds a data stack to size, secure and back up. LTI Advantage Complete certification, added in Verawood, matters if partner portals or external tools must launch courses. Confirm the LTI version each partner portal supports before committing to a launch architecture.
Moodle for LTS stability and broad plugins
Moodle is licensed under GPL-3.0 and maintained by Moodle HQ, with a large plugin ecosystem for certificates, catalogs and payments. Moodle 5.3 is the next long-term support release, with security fixes until October 1, 2029, which gives a longer security horizon than a single named release. Core authentication covers LDAP, LTI, OAuth 2 and Shibboleth, so dealer directories and partner logins can often be connected without custom code. The cost trade-off is plugin maintenance and per-release compatibility testing, which your team or partner carries.
Moodle hosting and document root changes
From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, or the site may show directory listings or errors. Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17 or MySQL 8.4 and sites must run Moodle 4.4 or later to upgrade. Older dealer-training sites often hold years of records, so the upgrade path is a planned migration with its own testing window. Ask any partner to show a tested upgrade from your current version before signing.
Canvas LMS under AGPL-3.0
Canvas LMS by Instructure is licensed under AGPL-3.0, so modifications you distribute or run as a network service carry source-sharing duties that legal teams should review. It is a candidate where a manufacturer already runs Canvas for other audiences and wants one vendor family. Confirm the self-hosting path, required database and cache services, and the support model with the vendor before comparing it with Open edX or Moodle on cost. Canvas is the least-covered option in this set, so verify each capability for dealer and certification use cases directly.
How a manufacturer rolls out dealer and customer training
The sequence moves from agreed audiences and certification paths to a run-and-upgrade model, with each phase closing on a named output so the platform, integrations and support model are settled before regional launch.
Scope audiences and certification paths
The manufacturer's training lead, product owners and a dealer representative define each audience (dealers, installers, end customers), the catalog each one sees, the certification paths and the regions and languages in the first release. DeployOpen maps which courses sit behind which credential and which records must survive a later platform change. The step closes with a signed scope document listing audiences, catalogs, certificates, languages and out-of-scope items.
Design identity and CRM integration
The team documents how dealer and installer accounts are created, how single sign-on connects to the partner portal or directory, and which CRM objects receive enrollment, completion and certificate events. DeployOpen reviews the supported identity options for Open edX or Moodle, including SAML 2.0, OAuth2 and LTI, and confirms them with your identity team. The step closes with an integration specification covering data flows, field mappings, identity sources and who owns each interface.
Build catalogs, branding and multilingual content
DeployOpen configures the chosen platform with separate audience catalogs, role-based access, theming for each brand, and translation workflows for the languages in scope. Course content is loaded and tested per audience so a dealer cannot see restricted installer material by accident. The step closes with a build acceptance record that shows each audience's catalog, login path, certificate template and language version working in a staging environment.
Run a pilot with one dealer cohort
One dealer group enrolls under production-like conditions, and the team tracks login issues, course completion, certificate delivery and CRM sync errors. Feedback from trainers and dealer staff is logged against the scope so changes are tied to agreed requirements. The step closes with a pilot report recording defects fixed, open items, adoption figures from the cohort and a go or no-go decision for regional rollout.
Roll out region by region
Each region is enabled in turn with its language packs, local admins, payment or enrollment rules where applicable, and support contacts. Load and access checks run before each regional launch, and the CRM and portal integrations are monitored during the first weeks. The step closes with a regional launch record per region confirming the audiences, languages, integrations and support route that went live.
Hand over the runbook and operate
DeployOpen documents hosting, backup, monitoring, access reviews, certificate reissue and incident steps in a runbook the manufacturer's operations team can follow. Ongoing support can be provided under a retainer or kept in house, and the decision is recorded in the scope. The step closes with an approved runbook and a named owner for each operational task.
Plan upgrades against named release windows
Upgrades follow the support windows of the chosen platform. For Open edX, only the latest named release is supported, with Verawood the current release (published July 30, 2026) and Willow planned for December 2026. For Moodle, confirm the LTS line your site uses, since Moodle 5.3 carries security support until October 1, 2029, and check PHP and database prerequisites before each move. The step closes with a dated upgrade plan, a test environment checklist and a rollback procedure approved by the manufacturer.
Running multilingual delivery across regions
Multilingual delivery for dealer and installer training is mostly a hosting and content-workflow decision, not a translation decision alone. Each region's language, data residency rules and review process determine where the platform runs, how course content is versioned, and who signs off before a translated module or exam goes live. A manufacturer that plans these three things first avoids rebuilding its catalog later. Start by listing every language and region in scope, then ask who in each region approves wording that touches product safety, warranty terms or certification criteria.
Language packs are the first technical check. Open edX and Moodle both separate interface strings from course content, so a translated interface does not translate the product courses, videos, subtitles or certification exam questions. Confirm in each platform's documentation how language packs are installed and updated, how a learner's language is selected per audience, and whether the site can show different catalogs to dealers and end customers in different languages. For translated certification exams, decide whether each language gets its own question bank or a shared one with translated text. Separate banks make item review and result comparison harder, but they reduce the risk that a translation changes what a question actually asks.
Regional hosting usually means running one platform instance per data jurisdiction inside the manufacturer's own cloud account or data center, or running a central instance with carefully scoped regional tenants. Both options affect backups, support access and how learner records are exported to a regional CRM or partner portal. Before choosing, ask your legal and works council contacts where learner names, dealer identifiers and assessment results may be stored, and confirm the translation tooling and any machine-translation plugin behavior in the vendor documentation. Keep a sign-off record for each translated module, because regional review is the step auditors and dealer managers ask about first.
Evidence auditors and regulators ask for from training records
This table maps each evidence item that assessors may ask for from a dealer and customer training platform to the component that produces it and the gap teams most often miss. Read it as a checklist for scoping logs, tickets and documents before an audit or a regulator request. The main takeaway is that the LMS alone rarely holds the full evidence set, so identity, analytics and change management records must be planned from the start.
| Evidence item | Component that produces it | What to confirm or where it usually fails |
|---|---|---|
| Certification completion records and exam versions | LMS completion and certificate records, plus archived course versions | Confirm that each certificate stores the course version and assessment version taken, so a later content change does not overwrite the proof of what was tested. |
| Access logs by audience | Identity provider logs, LMS enrollment and login logs, and catalog permission settings | Confirm that dealer, installer and end customer accounts are logged separately and that audience-specific catalogs can be shown to an assessor for a given period. |
| Incident and vulnerability handling runbooks tied to CRA Article 14 | Security runbooks and ticketing records, with vulnerability intake from the security team | Confirm that the runbook names who reports actively exploited vulnerabilities and severe incidents to authorities under Article 14, and that training content for affected products can be updated quickly. |
| Supplier development evidence aligned to ISA/IEC 62443-4-1 (where the manufacturer also produces IACS components) | Secure development lifecycle records in source control, code review and test tooling, and training content review logs | Applies only when the manufacturer also builds IACS components. Confirm that the platform's own customizations and plugins are tracked as part of that lifecycle, since they are often outside the product team's records. |
| Change records for upgrades | Change tickets, Git history for theme and plugin code, and release notes for the named Open edX or Moodle release | Confirm that every upgrade has a ticket, a test record and a rollback plan. Moodle and Open edX upgrades often fail where custom plugins are not checked against the new release. |
| Learner analytics and completion reporting | Analytics pipeline (for Open edX, xAPI event storage and dashboards) or Moodle reporting and logs | Confirm which reports are the system of record and how long raw logs are retained, since dashboards that are rebuilt from raw events can differ from earlier exports. |
| Data location and retention for dealer and customer records | Database backups, object storage for certificates, and retention settings in the LMS and identity provider | Confirm where personal data for end customers is stored and deleted, and that training records are separated from any product or warranty data they should not share. |
What buyers ask before hiring a partner for dealer training
What drives the total cost of a dealer training platform?
The largest cost drivers are the number of audiences and catalogs, the number of certification paths, the depth of CRM and partner portal integration, the languages and regions you deliver in, and the amount of custom theming and content migration. Software licensing is often zero for Open edX and Moodle, so most spend goes to people: planning, configuration, integration work, hosting, testing and ongoing operations. One-time costs include the initial build, content migration, integration development and launch testing. Recurring costs include hosting, backups, security patching, version upgrades, support and content maintenance. Ask any partner for a quote that separates one-time and recurring lines, names who is paid for each item, and states what is excluded.
How long do a pilot and a full dealer training rollout take?
Duration depends on the number of audiences, the integrations in scope, how much existing content must be migrated and how many languages launch on day one. No timeline is fixed in this page's sources, so the reliable approach is to agree the duration in a written, fixed-scope plan before work starts. A pilot usually covers one region, one dealer tier and one certification path so that CRM sync, enrolment rules and certificate issuance are proven before wider rollout. Ask the partner to show the phases, the acceptance criteria for each, and which dependencies (such as CRM API access or translation sign-off) could move the schedule.
What must our internal team provide for the project?
Your team should own the business rules, because the partner cannot decide them for you. That includes the audience list and how dealers, installers and end customers are separated, the product catalog and certification criteria, pricing and access rules for paid courses, and the list of partner portal and CRM fields that must sync. You also need an accountable owner for approvals, a technical contact who can grant API and single sign-on access, and reviewers for translated content. Ask the partner to provide a written responsibilities matrix so that delays caused by missing inputs are visible early.
Should we choose Open edX or Moodle for dealer training?
Open edX suits manufacturers that need strong course authoring, a modern frontend, structured multi-course catalogs and an LTI-based path into other systems, and that can accept a platform run on a named release cadence. Moodle suits organizations that want a mature, widely understood LMS with a broad plugin ecosystem, a large administrator pool and a predictable major and long-term support cycle. Both are open source and both can serve several audiences on one installation. Confirm which authentication methods, reporting formats and certification features each release supports for your case, and test them against your real partner portal before deciding.
Can our team run the platform ourselves after launch?
Yes, if your team has the skills and the capacity, but it is a decision to test rather than assume. Operating either platform requires someone who can manage the hosting environment, database, cache, backups, security patches and version upgrades on a fixed schedule. The maintainers of Open edX recommend production deployment through a service provider or with Tutor, and warn that bare-metal installation is complex. Moodle versions also carry specific PHP and database requirements that must be planned for. A practical option is a split model where your team runs daily operations and a partner handles upgrades, testing and incident support under a written retainer.
How is CRM integration priced and scoped?
CRM integration is usually priced by the number of data objects, the direction of sync and the number of systems involved. Typical objects include dealer accounts, contacts, enrolments, completions and certificate records. Each object needs a field mapping, a sync rule for conflicts, error handling and testing against a sandbox. The cost rises when the CRM has custom objects, when data must flow back in near real time, or when partner portal single sign-on has to be added. Ask for a scope document that lists each integration, its trigger, its owner, its test plan and any licensing charges for the CRM vendor's API access, which DeployOpen does not set.
How do certification records survive a platform migration?
Certification records survive a migration when they are exported in a documented format, mapped to the new platform, and verified against the source before the old system is retired. Confirm which records must be kept, including learner identity, course version, completion date, score, certificate ID and issuing authority. Ask the partner how they will handle expired or superseded course versions, how certificate verification links will keep working, and where the archive will live. Plan a reconciliation step where counts and sample records are checked by the business owner. Also confirm the retention period that your sector requires.
How is regulatory evidence prepared without DeployOpen issuing certifications?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. For a manufacturer, evidence may include access control records, configuration baselines, change logs, backup tests, training completion records and documented processes for product security. Depending on your market, relevant frameworks may include the EU Cyber Resilience Act and NIS2, and sector-specific rules may apply. Ask your partner to map each required control to a named artifact, to state who signs off each item, and to confirm which findings you must resolve with your assessor before go-live.
Questions to ask an implementation partner
Start with audience separation, because every later decision depends on it. Ask the partner how dealers, installers and end customers will be modeled on one Open edX or Moodle platform: whether they sit in separate organizations, cohorts or Moodle cohorts and groups, which catalogs each audience can see, and who holds the role that can grant enrolments or issue certificates. Ask them to show how a certification path is built as a sequence of courses with a gated final assessment, how a certificate is tied to a specific product line and expiry period, and how a lapsed dealer certification is revoked without deleting the learner's history. Request a written role matrix before any build starts.
Ask how identity is brokered for each audience. Dealers usually authenticate through the manufacturer's partner portal or their own company directory, while end customers should not need a partner account at all. Ask which protocol the partner will use for each group (SAML 2.0, OAuth2, LTI or a Moodle auth plugin such as the one listed in the SAML2 Single sign on plugin entry), where account provisioning and deprovisioning happen, and how a dealer who leaves a company loses access within a defined window. Ask for the integration design for CRM and partner portal sync: which system is the source of truth for enrolment and completion, whether data flows through an API or a queue, and how failed syncs are retried and reported. Finally, press on multilingual delivery and lifecycle. Ask how translations of course content, certificate templates and assessment questions will be managed, who owns each language, and how a change to a source course is flagged for translators. Ask which Open edX or Moodle release the platform will run, how the partner tests a named-release upgrade against custom themes, plugins and CRM connectors before it reaches production, and whether the partner or your team will own the upgrade calendar. Confirm in writing who operates the platform after launch, who responds to incidents, and what support is included in the fixed-scope quote versus a retainer.
How DeployOpen scopes and supports manufacturer training
This sequence turns a manufacturer's audiences, catalogs and integrations into a written, fixed scope, then builds, tests and documents the platform so that training delivery can be run and evidenced after launch. Each step ends with a named output the buyer can check.
Map audiences, catalogs and certification paths
Your product, sales and training teams list each audience (dealers, installers, end customers, internal staff), the product lines each one must learn, and which completions must yield a certificate or a renewal. DeployOpen's solution architect converts this into a catalog map showing which courses sit in which audience's view and where prerequisites apply. The step closes with a signed-off audience and catalog matrix that becomes the basis of the written scope.
Define integrations and language scope
DeployOpen documents every system the platform must exchange data with, such as the partner portal, CRM, single sign-on directory, and any product registration or warranty system. For each one, the scope states the data flow, the direction of sync, the owner of the field definitions and the test data to be used. Language and regional requirements are recorded alongside, including which languages, translation workflow and regional content variants are in scope. The output is an integration register and a language list agreed before build starts.
Agree the written fixed scope
DeployOpen issues a written scope covering audiences, catalogs, integrations, languages, deliverables, acceptance criteria and exclusions, and both parties sign it before work begins. Ask the partner which named Open edX or Moodle release the scope targets and how that release will be supported after launch. The step closes when the signed scope is the single reference for changes, and any change request is priced against it.
Build, theme and connect the platform
Engineers deploy the chosen platform inside your cloud account, data center or private network, configure audience separation and catalogs, build the certification paths and connect single sign-on and partner or CRM integrations. Content migration and branding per partner or region follow the agreed plan. Each integration is checked against its data flow in the register, and the step closes with a working staging environment and a test log.
Test security and performance before launch
Before any dealer or customer account is created, DeployOpen runs security testing against the web application, its APIs and the integration endpoints, and tests the identity flows that gate partner access. Findings are ranked, fixed and retested, and the platform is hardened according to the agreed baseline. Load testing scope is set during the written scope, so the team can confirm that launch traffic from a partner campaign or a product release is covered. The output is a findings report with closure status.
Prepare evidence for assessments
DeployOpen assembles the records an assessor or customer's compliance team will ask for, such as configuration baselines, access control design, backup and restore records, change logs and test results tied to the controls in scope. Where certificate issuance or electronic signature rules apply, the team documents how records are kept. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications, so the step closes when your auditor or certification body confirms which evidence it needs.
Hand over and set support retainers
Operators receive runbooks, admin training and documentation of the integrations, and the platform goes live with acceptance tests run against the signed scope. You choose whether to keep operations in-house or to add a support retainer that covers platform upgrades, patching and continuous security testing. The retainer scope is agreed in writing, including which Open edX or Moodle releases it covers. The output is a signed acceptance record and a support agreement, or a documented in-house run plan.
