Why a self-hosted customer academy changes the build for SaaS companies
A self-hosted customer academy for a SaaS company changes the build because the training has to live inside the product relationship, not beside it. Learners should sign in with the same account they use to run the product, and the academy should know which plan, workspace and role each person holds. Open edX and Moodle can both deliver courses, but the decision turns on your product stack and your team. Open edX, licensed under AGPL-3.0, suits product-led organizations that want strong course authoring, a modern learner experience and an engineering team comfortable with Python, Django and Docker-based operations through Tutor. Moodle, licensed under GPL-3.0, suits teams that want a mature, widely supported LMS with a large plugin ecosystem and simpler day-to-day administration. Neither choice removes the integration work.
Identity is the first place a general course site falls short. Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, so the academy can be connected to your product's identity provider rather than issuing separate passwords. Confirm which protocol your product login uses, who owns the identity provider, and how account deprovisioning reaches the academy when a customer contract ends. Customer and partner data also changes the build: enrollment, completion and certificate records are linked to a customer organization, which means the academy needs clear rules for who can see which learner records and for how long they are kept.
Onboarding flows are where the academy earns its place in the product. Training is most useful when a new workspace is provisioned with the right course path, when a completed module unlocks a feature guide, and when account managers can see progress without exporting spreadsheets. Each of these requires an API or event connection between the product and the academy, and that connection is custom work in any LMS. Ask any implementation partner to name the events that will flow between the two systems, the owner of each webhook or API, and how failures are retried. Usage analytics also need a plan: Open edX Aspects routes tracking logs as xAPI statements into ClickHouse and Superset, which is useful, but it must be sized and governed as part of the product data estate.
Which requirements a SaaS academy must meet and what each means for the build
This table maps each requirement a technology or SaaS academy typically meets to its source and the build consequence it creates. Read it as a checklist to bring to scoping: each row names what the requirement asks for and what the platform team must design or evidence. The main takeaway is that identity, learner data terms and accessibility shape the build more than the course content does.
| Requirement | Source or constraint | What it means for the build |
|---|---|---|
| Product account SSO | Customer expectation that learners sign in with the same product account used for the application | Connect Open edX third-party authentication (SAML 2.0, OAuth2 or LTI) to the product identity provider. Confirm claim mapping, account linking for existing users and how deprovisioning is handled. |
| Free and paid tracks | Commercial model for product training, often free onboarding with paid certification | Separate enrolment rules per track. Paid tracks need a payment and tax layer connected to the LMS. Confirm which storefront or payment module the chosen platform supports before committing. |
| Certificate verification | Customers and partners often need to prove a certification to their own employers or procurement teams | Issue certificates with a public verification route and a stable record identifier. Plan how records survive a platform migration or a named-release upgrade. |
| Completion analytics | Product and customer success teams need training data linked to adoption and account health | Route learning events to an analytics store the company controls. Open edX Aspects captures xAPI statements in ClickHouse and presents them in Superset. Confirm the reporting model before the first cohort. |
| GDPR processor terms for learner data | GDPR Article 28(3) requires documented instructions and Article 32 security measures from any processor | Sign processor terms with the hosting partner and any analytics or email vendor. Map where customer learner data is stored, who can access it and how deletion requests are fulfilled. |
| Data Act switching rights for hosting | EU Data Act (Regulation (EU) 2023/2854) requires data processing providers to allow switching to another provider or on-premises infrastructure | Confirm the hosting or operations provider's exit terms in the contract. Keep course content, learner records and configuration exportable in standard formats so a switch does not depend on one vendor. |
| NIS2 and CRA exposure | NIS2 covers cloud and managed service providers, and the Cyber Resilience Act applies to products with digital elements, including software, from 11 December 2027 | If the company is in scope as a provider, the academy becomes part of its supplier and product security evidence. Confirm applicability with counsel and document patch cadence for the platform. |
| SOC 2 evidence for customer trust | AICPA 2017 Trust Services Criteria, with the security common criteria CC1 to CC9 applying to every SOC 2 | Academy logs, access reviews, change records and backup tests become evidence in the company's SOC 2 scope. A Type 1 report covers design at a date, and a Type 2 report covers operating effectiveness over a period. DeployOpen prepares evidence; auditors issue the report. |
| WCAG 2.1 AA as a procurement expectation | Enterprise buyers ask for WCAG 2.1 AA conformance, and public sector customers face ADA Title II duties | Choose a theme and course player that can be tested for WCAG 2.1 AA. Budget for audits of custom themes, video captions and certificate PDFs, and ask for a conformance statement with the test method. |
Open edX, Moodle and the storefront options for a product academy
A product academy needs a learning platform that accepts the product account, issues certificates and reports completion, plus a storefront only if customers pay. The cards below compare the open-source options and the pieces that often sit beside them. Each choice depends on your team's skills and product stack, so confirm every option against your own environment before committing.
Open edX for product training
Open edX is built for course authoring and delivery at scale, and it is licensed under AGPL-3.0. Its third-party authentication covers OAuth2 providers, SAML 2.0, Shibboleth and LTI, which lets learners sign in with the product account instead of a second login. Check whether your team can run Python and Django services, and plan upgrades around named releases because only the latest release is supported.
Open edX analytics with Aspects
Aspects captures tracking logs through the event-routing-backends plugin as xAPI statements, stores them in ClickHouse through Ralph or Vector, and presents them in Superset dashboards. That gives product teams completion and engagement data without sending learner events to a third-party tool. Confirm which dashboards you need, who maintains the ClickHouse and Superset components, and how the data feeds your customer success reporting.
Moodle for certification-led tracks
Moodle is licensed under GPL-3.0 and has a long track record in certification-style courses, quizzes and completion rules. Moodle 5.3.0 is the next long-term support release, with bug fixes until October 4, 2027 and security fixes until October 1, 2029. Choose Moodle when your team already runs it or when certification workflows matter more than a polished authoring experience, and confirm the SSO connectors you need for the product account.
Canvas LMS as an alternative
Canvas LMS by Instructure is licensed under AGPL-3.0, so it is a viable open-source option to evaluate alongside Open edX and Moodle. It fits teams that want a familiar instructor interface and already use Canvas patterns in other parts of the organization. Confirm the hosting effort, the plugin and integration depth with your product stack, and the supported deployment model before you choose it over the other two.
Headless CMS for academy pages
Marketing pages, documentation hubs and course landing pages often sit outside the learning platform. A headless CMS such as Strapi, Payload or Directus can serve that content through an API, so the academy catalog stays consistent with the product site. Check how the CMS authenticates editors, how course content links back to the LMS, and which license terms apply to your deployment model.
WooCommerce or Saleor for paid tracks
Paid certification tracks need a storefront, tax handling and invoicing, which an LMS does not usually provide on its own. WooCommerce (GPL version 2 or later) fits teams that already run WordPress, while Saleor, a headless commerce API under BSD-3-Clause, fits teams that want a separate catalog service. Confirm how enrolment is triggered after payment, how payment handling affects PCI DSS scope, and who owns refunds and tax rules.
How product accounts, paid tracks and free tracks fit one platform
Customers are the audience most likely to expect one login across the product and the academy. The usual pattern is to connect the academy to the identity provider that already authenticates the product, so a customer signs in with the account they use in the app and never creates a second password. Open edX third-party authentication supports SAML 2.0, OAuth2 providers and LTI, so the team must confirm which protocol the product's identity provider exposes and whether account attributes such as organization or subscription tier are passed at login. Entitlements then decide which courses a customer can open. A customer on a paid plan might see a certified track, while a trial account sees only free introductory courses. The catalog itself stays single: free and paid tracks sit in one course catalog, and access rules, not separate sites, decide what each account sees.
- Login path: SAML 2.0 or OAuth2 from the product's identity provider, with the academy trusting it as the only sign-in route.
- Attribute mapping: account fields such as plan or organization mapped to academy groups on each login.
- Entitlement rules: plan level decides enrollment in paid tracks, with free tracks open to every verified account.
- Account lifecycle: deprovisioning in the identity provider should remove or suspend academy access.
- Payment scope: if the academy takes card payments directly, PCI DSS scope changes and must be confirmed with the payment provider before launch.
Check with the product team which identity provider and claims are stable enough to drive access rules.
Partners such as resellers, implementation firms and integrators often need training and certification that is separate from end customers, but they usually should not get a separate platform. A common approach is a partner group inside the same Open edX instance, with its own catalog section and certification paths. Partner users may come from a partner directory or a partner portal rather than the customer identity provider, so the team needs to decide whether a second identity source is connected through SAML 2.0 or OAuth2, or whether partner accounts are created and managed by the academy. Entitlements for partners tend to depend on a signed partner agreement or program tier, so access should follow that record. Partner-only certifications can be kept visible to partners and hidden from customers using the same catalog and group rules.
- Separate identity source: a partner directory connected by its own SAML 2.0 or OAuth2 configuration, or accounts managed locally.
- Program tiers: access to advanced certification tracks tied to partner tier or agreement status.
- Visibility rules: partner-only courses hidden from customer accounts through group membership.
- Certificate records: partner certificates issued and verified in the same system as customer certificates.
- Contract terms: any fees partners pay for paid tracks should be confirmed with the commercial team, and card handling confirmed with the payment provider.
Confirm who owns partner account creation and removal when a partner contract ends.
Internal enablement covers sales, support and customer success staff who take the same product courses to learn the product and its certifications. Because these users are employees, the cleanest route is usually the corporate identity provider, so staff use their work login and leave the academy when they leave the company. Internal tracks often need different entitlements than external ones: staff may see draft courses, pre-release content or internal-only certifications that customers never see. These rules belong in the same role model, not in a separate instance. Internal completion data also matters for managers, so the team should decide early which reports are shared with line managers and which stay within the learning function.
- Corporate login: the company identity provider is the sole sign-in route for staff, enforced through SAML 2.0 or OAuth2.
- Preview access: draft and pre-release courses limited to internal roles and kept out of the public catalog.
- Role-based tracks: support, sales and success paths assigned by department attributes from the directory.
- Manager reporting: completion reports scoped to teams, with personal data handling agreed in advance.
- Offboarding: access ends with the employee's directory account, checked in the audit trail.
Confirm with HR and legal which learner data staff completion records may include before rollout.
How a SaaS academy rollout moves from scope to onboarding embeds
The sequence turns a product training idea into a customer academy that signs in with the product account, issues verifiable certificates, reports completion, and appears inside onboarding, with each phase closing on a written output.
Define scope and audience segments
The team agrees with the product, customer success and partner teams which audiences the academy serves, such as new customers, administrators, partners and certified implementers, and which product versions each track covers. DeployOpen documents the audiences, catalog boundaries, free and paid tiers and the success measures the business will report. The output is a signed scope document that fixes deliverables, exclusions and timelines before any build work starts.
Design identity and entitlement mapping
Architects map how learners sign in with the product account and which roles, organizations or subscription plans grant access to each track. Open edX third-party authentication supports OAuth2 providers, SAML 2.0 and LTI, so the design confirms which of these your identity provider uses and how partner users are separated from end customers. The output is an integration specification covering claims, group mapping, provisioning and deprovisioning, reviewed by your identity team.
Build the platform and theme
Engineers deploy the chosen Open edX or Moodle distribution inside your cloud account or data center, configure the course authoring workflow and apply branding that matches the product's design system. Hosting choices, such as a Kubernetes-based Tutor deployment for Open edX, are confirmed at this stage with your operations team. The output is a staging environment with a tested SSO login flow and a documented build record that your team can reproduce.
Configure tracks, enrollment and payments
The team builds the free and paid tracks, enrollment rules, prerequisites and any commerce connection, including how paid entitlements map back to the product account. Tax, invoicing and payment handling are confirmed with your finance and compliance leads, since card data handling changes the compliance scope. The output is a track matrix and a tested purchase-to-enrollment flow, with refund and access revocation cases documented.
Set up analytics and certificate verification
Engineers configure learner event tracking, completion reporting and certificate issuance, and decide where verification records are stored so they survive a future platform change. For Open edX, Aspects captures tracking logs as xAPI statements and presents them in dashboards, which the team confirms against the reports your customer success team needs. The output is a reporting specification and a test certificate that can be verified by an outside party.
Test load and security before the pilot
Testers run load tests against the expected launch traffic, review authentication and authorization paths, and check the identity integration for session and role errors. Findings are triaged with the build team, and the highest-risk items are fixed and retested before any customer sees the academy. The output is a load and security test report with a remediation log and a sign-off from your security owner.
Run a pilot with a partner cohort
A small group of partner users completes the paid and free tracks under real sign-in conditions, and the team collects feedback on content, navigation, certificates and support paths. Results are compared against the success measures agreed in scope, and content or flow issues are corrected. The output is a pilot completion report that records what changed and which items remain open for launch.
Launch and embed training in onboarding
The academy opens to customers, and course entry points are placed inside the product onboarding flow, help center and account pages, with links that pass the user's entitlement through the agreed identity integration. Monitoring and support paths go live with named owners for platform incidents and content questions. The output is a launch checklist signed by the product and operations owners, followed by a support plan for upgrades and ongoing testing.
Integration points and deployment patterns for SaaS academies
Can Open edX run on Kubernetes for a customer academy?
Yes, Tutor is the usual route, because it is the official Docker-based Open edX distribution for production and local development and it supports Kubernetes deployments and plugins. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, and they note that bare-metal installation is complex and receives limited community support. Confirm the Tutor release you plan to use against the current Open edX release notes, since only the latest named release is supported. A Kubernetes setup adds container images, persistent storage for the databases, ingress and certificate management, and a deployment pipeline your platform team must own. Ask any partner which Tutor version they will pin, how upgrades between named releases are tested, and who is on call after launch.
Why does a multi-node Open edX deployment need Redis or Memcached?
A multi-node Open edX deployment needs a shared Django cache backend, such as Redis or Memcached, so that every LMS and Studio pod sees the same cached state. Without it, sessions and cached data sit on individual nodes, and learners can see inconsistent behavior as traffic is balanced across pods. Development also requires MySQL 8.0, MongoDB 7.x, Memcached and Python 3.12, so the cache is one of several stateful services your operators must run and back up. Check that your cache sizing and failover are tested before a product launch, and ask how cache keys are isolated between the academy and any other applications sharing the cluster.
How does Aspects analytics fit into a SaaS academy stack?
Aspects captures tracking logs through the event-routing-backends plugin as xAPI statements, stores them in a ClickHouse database through Ralph or Vector, and presents them in Superset dashboards. For a SaaS company, this lets course completion, quiz attempts and certification events feed the same analytics environment that tracks product adoption, if you agree the event schema and identifiers up front. The stack adds a ClickHouse cluster, a Superset instance and a routing pipeline to operate, so it is a real infrastructure commitment. Ask your implementation partner which Aspects components are in scope, how dashboards are secured by role, how data retention is set, and what is one-time setup versus ongoing operation.
How do customers sign in to the academy with their product account?
Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. For a product account, the usual pattern is SAML 2.0 or OAuth2 against the identity provider that already authenticates customers, so learners sign in once and their academy profile is provisioned on first login. Confirm which identity provider your product uses, whether it can issue the attributes Open edX needs for account matching, and how deprovisioning works when a customer leaves. Identity integration is often the riskiest part of the build, so ask for a written test plan covering SSO, logout and account linking before scoping the rest of the work.
How do LTI links connect training to the product?
LTI lets the academy launch a course or lab from inside another application, and Open edX supports LTI, including LTI Advantage Complete certification in the Verawood release. In a SaaS setting, LTI is useful for putting a sandbox or guided exercise inside an onboarding flow, with the launch carrying the learner's identity and course context. The product must act as a tool provider or consumer with a matching configuration, so the work sits on both sides of the integration. Ask how launch signatures are validated, which roles and claims are passed, and how the product team will test launches across releases before customers see them.
How should entitlements sync between the product and the academy?
Entitlements decide which free and paid tracks a customer can open, and they should be driven by the product's subscription or plan data rather than by manual enrollment. A common pattern is an API-based sync where the product publishes plan changes, and a small service maps them to course enrollments, certificate eligibility and expiry dates in the academy. Design the sync to be idempotent, log every change, and handle downgrades and cancellations explicitly. Ask a partner how the sync is tested, how it recovers from missed events, and who owns the mapping rules when the product's pricing changes.
What should a platform team confirm before choosing this deployment pattern?
Confirm the target Open edX or Tutor release, the cluster and cloud environment, the identity provider, the analytics retention rules and the uptime expectations for product launches. Confirm which systems hold customer data and whether the academy will copy any of it, since that determines the data processing terms your legal team needs. Ask for an architecture diagram that shows each stateful service, its backup method and its restore test, along with the integration points listed above. DeployOpen plans, implements, integrates, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts or data centers, and most engagements are fixed-scope with agreed deliverables in writing before work starts.
What does it cost to run these integrations over time?
Cost falls into one-time work, such as designing the identity, LTI and entitlement integrations, and recurring work, such as hosting, cache and database capacity, analytics storage, upgrades and monitoring. Costs rise with the number of identity providers, the volume of learner events, the number of product plans that need mapping and how often named releases are upgraded. Open edX names the latest release as the only supported one, so budget for regular upgrade cycles rather than a single launch. No supplied source gives a price for these components, so ask any partner for a quote that separates setup, hosting, support retainers and upgrade effort, and ask which cloud costs are billed to your account directly.
What SOC 2 and customer security reviews ask the academy to prove
This table maps the evidence a SOC 2 examiner or customer security reviewer typically asks for against the academy components that produce it. Read each row as a question to answer before launch, with the artifact that answers it. DeployOpen prepares the controls and evidence; independent auditors issue any report.
| Requirement or question | What the academy must show | Evidence to prepare | Where it usually fails |
|---|---|---|---|
| Access control (CC6 and related common criteria) | Only authorized staff and learners reach course authoring, learner records and admin consoles, with SSO tied to the product account | Identity provider configuration for Open edX third-party authentication, role mapping for Studio and LMS staff, access review records | Shared instructor logins, or learner accounts that drift from the product account after offboarding |
| Change management (CC8) | Platform, theme and plugin changes are approved, tested and traceable before reaching production | Change tickets, staging test records, version-controlled theme and plugin code, deployment logs | Course content or Studio edits made directly in production with no review trail |
| Monitoring and incident response (CC7) | Security-relevant activity is logged, reviewed and escalated | Access logs from the Aspects tracking pipeline, alert rules, incident records for learner-facing events | Logs captured but never reviewed, or retention shorter than the audit period |
| Logical and system operations (CC6 to CC7 system components) | Platform components, databases and caches are hardened and their configuration is documented | System description, architecture diagram, hardening baseline, configuration inventory | Undocumented Tutor or Kubernetes overrides that differ between environments |
| Named release upgrades (CC8 change evidence) | Each Open edX or Moodle upgrade follows a named release and is recorded | Upgrade records per named release, test results, dates of cutover, notes on support windows | Running an unsupported release because no upgrade owner was named |
| Certificate verification and credential integrity | Certificates can be verified, and issuance and revocation are logged | Certificate verification logs, issuance records, revocation procedure, sample verification tests | Certificates that cannot be checked after a migration, or no record of who issued them |
| Type 1 versus Type 2 reporting | Type 1 shows controls are designed as of a date; Type 2 shows they operated over a period | For Type 1: documented controls and system description at a point in time. For Type 2: operating evidence sampled across the full period | Teams prepare for Type 1 and then face Type 2 requests with no evidence collected during the period |
| GDPR Article 28(3) processor terms | Processing happens only on documented instructions, including for transfers and subprocessors | Data processing agreement, written instructions to the operator, list of subprocessors such as payment and video providers | Learner data flowing to third-party tools that were never named in instructions |
| GDPR Article 32 security of processing | Measures such as encryption, access restriction and restoration tests are in place and tested | Encryption settings, backup and restore test records, pseudonymization of learner identifiers in analytics | Analytics dashboards exposing identifiable learner data to staff who do not need it |
Why named Open edX releases force a planned upgrade cadence
Open edX supports only its latest named release, and the project states it cannot support more than one release at a time. For a SaaS academy tied to a product release calendar, this means the academy's upgrade schedule is set by the Open edX release train, not by the product team. The current named release is Verawood, published on 30 July 2026. The next releases are Willow, listed for December 2026, and Xylon, listed for June 2027. Before committing to a launch date, confirm these dates against the official release notes, because the academy's upgrade plan depends on them.
Plan the cadence as a recurring project with three tracks. First, schedule a staging environment that mirrors production (LMS, Studio, the MySQL and MongoDB databases, the cache layer and the Tutor configuration) and run the upgrade there before any customer-facing change. Second, run regression on the theme and every plugin, including certificate templates, SSO and LTI connections, and any frontend plugin slots, because these are the parts most likely to break on a new release. Third, agree on a customer communication window with the product and customer success teams, covering the course changes, certificate behavior and any downtime that learners and partners will notice.
Compare this with Moodle, where the 5.3.0 release (5 October 2026) carries bug fixes until 4 October 2027 and security fixes until 1 October 2029 as the next long-term support release. A Moodle academy can therefore stay on one supported line for years and schedule upgrades less often, though it still needs security patching. Ask any implementation partner, in writing, which release line they will maintain, how many releases they expect to upgrade through per year, and whether the upgrade is included in a retainer or quoted separately.
What a self-hosted SaaS academy costs and what it needs from the company
What drives the cost of a self-hosted SaaS academy?
The cost follows the number of integrations, identity sources, payment flows, analytics depth and the team that will run the platform after launch. Setup is usually a one-time project cost, while hosting, licensed services, upgrades and support recur. Ask the implementation partner to price each component separately: hosting in your cloud account, identity integration with the product account, payment and tax setup, theming, analytics and the upgrade plan. A written scope lets you compare options on the same basis and see which items you can take over internally.
- One-time: discovery, architecture, integrations, theming, content migration and testing
- Recurring: hosting, backups, monitoring, security patching and named-release upgrades
- Variable: learner volume, video delivery and the number of catalogs or audiences
How much does single sign-on with our product account add to the project?
Single sign-on with the product account adds integration work that grows with each identity source and each user type. Open edX supports OAuth2 providers, SAML 2.0, Shibboleth and LTI for third-party authentication, so a product account built on one of these standards is usually the simplest path. Confirm which protocol your identity provider exposes, how customer and partner accounts map to learner records, how roles are provisioned, and what happens when a user leaves your customer organization. Each additional identity source adds testing and support effort, so ask for it as a separate line in the quote.
How long does a self-hosted customer academy take to launch?
The timeline depends on the scope you agree in writing, not on a standard duration. The main variables are the number of integrations, whether certificates and paid tracks are in the first release, how much theming is required and how many courses must be migrated or authored before launch. Ask your partner to split the plan into discovery, platform build, integrations, content, testing and cutover, with a named owner and acceptance criteria for each phase. Be cautious of any timeline quoted before the identity, payment and analytics requirements are documented.
What internal team do we need to run a self-hosted academy?
You need an accountable product owner, someone who can operate infrastructure, and a content owner who keeps courses current with each product release. Either your platform team or a partner must handle hosting, backups, monitoring, patching and upgrades. Because Open edX supports only the latest named release, plan for a recurring upgrade cycle rather than a single launch. Moodle has its own long-term support schedule, which changes the upgrade rhythm. Confirm in writing who is on call, who approves upgrades and who owns learner support.
Is a SaaS course platform a better option than self-hosting?
A SaaS course platform is often faster to start and removes most infrastructure work, but it charges subscriptions or a share of sales and limits control over identity, data location and analytics. Self-hosting suits companies that need the academy inside their product identity, want learner data in their own infrastructure, or expect volume that makes per-seat or revenue-share pricing expensive. Build the comparison with the same requirements list: identity integration, certificate rules, analytics export, accessibility obligations and exit terms. The EU Data Act requires data processing service providers to let customers switch providers or move to on-premises infrastructure, so ask any SaaS vendor for its switching terms in writing.
How much do analytics on course completion add to the build?
Basic completion reporting is usually included in the platform, while deeper analytics add data pipelines, storage and dashboards that need ongoing care. 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. Each of those components needs configuration, retention rules and maintenance. Decide which product questions the analytics must answer, such as completion by customer account or onboarding impact, before you size the pipeline. Ask the partner to confirm how the data is exported to your own product analytics tools.
What should a written scope confirm before we sign?
A written scope should state what is delivered, what is excluded and how each item is accepted. Most engagements are fixed-scope, so the document should name the platform and release, identity sources, payment and tax handling, certificate rules, theming boundaries, analytics outputs, migration volume, testing, handover, and any retainer for upgrades and support. Ask who holds the hosting account, who owns the code and configuration, and what documentation you receive at handover. DeployOpen does not publish a price list, so request a quote built from this written scope and compare line items across bidders.
Which compliance evidence does a customer academy add to our audit scope?
A customer academy handles learner accounts, product identities and possibly payment-related data, so it can fall within the scope of your information security and privacy programs. The platform can support evidence for controls on access management, logging, change management and backups. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any report or certification. Confirm with your auditor whether the academy is in scope for a SOC 2 examination or an ISO/IEC 27001 certification, and whether it processes personal data under GDPR, so the processor terms and security measures are documented from the start.
How DeployOpen scopes, builds and supports a customer academy
DeployOpen starts every customer academy engagement with a written scope that names the audiences, the tracks, the identity sources and the integrations to be built, and agrees the deliverables and timelines before any build work begins. For a SaaS company, the scope decisions that matter most are the ones that touch the product account: which identity provider is the source of truth, whether the academy shares the product's login or runs its own, how partner accounts are separated from customer accounts, and which events (such as course completion or certification issued) must be pushed back to the CRM or customer success tools. Those decisions shape the Open edX or Moodle configuration, so they are settled in the scope document rather than discovered during the build. Pricing follows from that written scope, and the scope is the place to confirm what is included in the first release and what is deferred.
Implementation runs in the client's own cloud account, data center or private network. The academy is deployed with the client's infrastructure-as-code and secrets management, the identity integration is configured against the client's identity provider, and the operating model is documented so the client's platform team can run it. Before go-live, DeployOpen runs security testing against the academy and its integrations, including the SSO flow, the certificate verification endpoints, the enrollment and payment callbacks and any API that exposes learner or completion data. Findings are triaged with the client and retested. Where a client needs evidence for a compliance assessment, DeployOpen prepares the system description, control mapping and operating records that the client's auditor will request. DeployOpen does not issue audit reports or certifications, so the client should confirm with its auditor which evidence is needed for its assessment.
After launch, most SaaS customers choose a retainer for upgrades, security patching, backups, monitoring and content support. The retainer scope should state how named releases of the learning platform are tested and applied, since only the latest named Open edX release is supported and the platform's support windows differ from Moodle's. Ask the partner to show the upgrade runbook, the restore test results and the on-call hours before signing. Ask who owns the product integration when the SaaS product changes its authentication or API, because that change can break learner access overnight. Confirm in writing who pays for hosting, third-party licenses and any managed services, and what happens to the academy if the retainer ends.
