Why an Open edX course catalog needs its own implementation plan
An Open edX course catalog is set up as its own piece of work because programs, credentials and external catalogs all depend on it. A team that needs a public or partner-facing catalog on a self-hosted platform should plan it alongside the course build, before course metadata is entered at scale. This page covers the build, the data setup, the dependencies, the effort drivers and the handover, so that the decisions behind each one are visible before a partner is asked for a quote.
The catalog is delivered through two parts that work together. The Catalog micro-frontend is the React-based interface that visitors use to browse courses. The Course Discovery application is the service that holds the course and program data the interface displays and that other services rely on. Open edX is built from independently deployable applications and micro-frontends, so each part has its own deployment, configuration and upgrade path. The team needs to decide where each one runs, who operates it, and which data it owns before any frontend work starts.
The legacy catalog is planned for removal in Willow, which the Open edX release notes list for December 2026. Verawood is the current named release, published on 30 July 2026, and Open edX states that only the latest named release is supported. A catalog built on the legacy approach will therefore need to move before or during the Willow upgrade. Confirm the current status of the removal in the release notes, and record the catalog as a named dependency in the upgrade plan from the first day of the project.
Start with three decisions: which catalog frontend the public site will use, which systems will read catalog data and so need stable interfaces, and who owns course metadata after launch. Each decision changes the data setup, the number of services to deploy and the effort the work requires. When you ask a partner for a quote, request a scope that names the Discovery deployment, the data loading approach, the search and display configuration, the Willow transition and the handover materials, and ask them to state which of these items is excluded.
What the catalog and Discovery services do in Open edX
Open edX splits catalog work into four parts: publishing course records, the learner-facing catalog front end, the Course Discovery data service, and the external readers that consume that data. Each part has its own deployment and dependency decisions, so plan them together rather than one at a time.
Publishing courses to a catalog
Publishing makes a course visible in the catalog so learners and other systems can find it. Check how course data reaches the catalog in your target release, which fields learners see, and who approves a course for listing. Decide how course runs are chosen for display, since a course can have more than one run. Confirm these steps against the Open edX documentation for the release you plan to deploy.
The Catalog micro-frontend
The Catalog micro-frontend is the learner-facing catalog interface. Open edX builds its newer interfaces as React-based micro-frontends that sit alongside the core LMS and Studio applications, so the catalog is a separately deployed part of the platform. Decide how it is routed, themed and served under your domain, and confirm which catalog front end ships by default in your release. Test search and course pages after every upgrade.
Course Discovery as the data source
Course Discovery is the application that holds the catalog records other services use, including program records. A Discovery outage or stale data affects more than the catalog page, because other services depend on the same records. Decide whether Discovery runs in the same cluster as the LMS or separately, and confirm its data model and sync behavior in the documentation for your release.
Programs and credentials depend on Discovery
Program certificates are issued through the Credentials service, which relies on Course Discovery for program definitions. Map which programs, program types and credential rules need Discovery records before the build starts. Test the full path from course completion to program award in staging, not only the catalog listing. Confirm which Credentials and Discovery versions are compatible with your target release.
External catalogs reading from Discovery
External catalogs read catalog data from Course Discovery, which makes its API an interface you must plan, secure and version. Identify which endpoints partners and aggregators will call, how each client authenticates, and whether caching or request limits apply. Confirm the API contract and any changes between releases in the Discovery documentation before you promise a feed to an outside party.
Legacy catalog removal in Willow
The legacy catalog is scheduled for removal in Willow, which the Open edX release notes list for December 2026. Any integration, theme or link that depends on the legacy catalog needs a replacement path before you upgrade. Inventory those dependencies now, test the Catalog micro-frontend and Discovery path in a staging copy, and confirm the final removal scope in the Willow release notes.
How Course Discovery feeds programs, credentials and external catalogs
Course metadata published through Course Discovery is not only used by the catalog pages. Other parts of the Open edX platform read from it, so a change to a course record can reach more places than the one screen where an editor made it. Before you change the data model, map every consumer that reads Discovery data and decide who owns each field. This section explains the dependency chain and what to check before any change ships.
In plain terms, course details are authored and published into Course Discovery, which holds the catalog records: course runs, descriptions, dates, organizations and the programs that group courses. Other components then read from that store. The sibling topic on the Certificates and Credentials service describes the dependency for program certificates: the Credentials service relies on Discovery data to recognize which courses belong to a program. The exact interfaces, caching and refresh behavior should be confirmed against the Verawood documentation and your own deployment rather than assumed from this summary.
This is why a metadata change can travel. Renaming a program, changing a course run's identifier or altering which courses a program includes may affect what learners see in the catalog, which certificate or credential a learner is eligible for, and what an external listing shows. External catalogs and partner sites usually receive the same records through their own feeds or exports. A field that looks cosmetic in the Discovery admin can therefore change a credential rule or a listing on another site.
Map the consumers before you touch the model. For each field you plan to add, rename, retype or remove, list the components and external systems that read it, the owner who approves changes to it, and the release process that will update each consumer. Run the same mapping for program definitions and course run identifiers, since these are the keys most often referenced elsewhere. Ask the platform team to confirm which consumers are enabled in your installation, because an unused integration still needs a plan for its data.
Illustrative example: a university renames a program from a diploma title to a shorter marketing name. The catalog page updates as expected, but the credential template and a partner's listing still show the old name until each consumer is refreshed or updated. A consumer map built beforehand would have listed those three places and assigned an owner and a test for each, so the rename would have been scheduled as a coordinated change rather than discovered after release.
Configuration decisions for the catalog build
This table lists the decisions a team should settle before building the Open edX catalog, with the options for each, when they fit and what they affect later. Read it top to bottom as a sequence, because the frontend choice and the source-of-truth choice shape most of the rest. Teams that defer the release target and hosting questions often rework their Discovery data model during testing.
| Decision | Options | When each fits | What it affects downstream |
|---|---|---|---|
| Catalog frontend | Catalog micro-frontend, or a custom frontend that reads Discovery data through its API | The Catalog micro-frontend fits sites that want the standard course listing and search pages. A custom frontend fits sites with a branded marketplace or non-standard course cards. | Frontend effort, styling work, and how much of the catalog layout must be rebuilt on each named release |
| Single source of course metadata | Discovery as the system of record, or a parallel store such as an external CMS or spreadsheet | Discovery as the system of record fits teams that want one place for course, run and program data. A parallel store fits organizations that already maintain approved catalog data elsewhere. | Sync jobs, data ownership rules, and the risk of two catalogs disagreeing about course titles, dates or pricing |
| Program definition model | Programs defined in Discovery, or programs defined only in the Credentials service | Discovery-defined programs fit multi-course credentials that need to appear in the catalog. Credentials-only programs fit cases where the catalog does not list programs. | Which service owns program rules, and how program certificates depend on Discovery data |
| External catalog consumers | Direct API consumers, feeds to partner sites, or no external consumers | Direct API consumers fit partner portals and marketing sites that pull course data. Feeds fit partners that cannot call an API. No external consumers fits closed internal catalogs. | API versioning, access control on Discovery endpoints, and the data fields partners can rely on |
| Hosting alongside the LMS and Studio | Same cluster and network as the LMS and Studio, or a separate environment reached over the network | Same cluster fits smaller deployments that want one set of operations. A separate environment fits teams that need independent scaling or separate access controls. | Shared cache and database planning, network paths between services, and the number of components to back up and monitor |
| Release target | Latest named release, or an earlier named release kept for a planned rollout | Open edX supports only the latest named release, so a team targeting Verawood builds against that release. Teams close to a release change should confirm the schedule for Willow before committing. | Upgrade effort later, the window for removing the legacy catalog, and which release notes and upgrade pages apply to the build |
| Legacy catalog removal | Keep the legacy catalog during transition, or switch to the new catalog at launch | Keeping the legacy catalog fits sites with existing links and partner feeds. Switching at launch fits new deployments with no published legacy links. | Redirects, partner communication, and the testing scope for both catalogs during the transition |
Setting up catalog data and moving from the legacy catalog
Start the catalog work with the data, not the interface. Before anyone configures the Catalog micro-frontend or the Course Discovery application, the organization needs a written course metadata standard that says which fields every course record must carry, who owns each field, and what format each one takes. Course titles, short descriptions, subject tags, languages, levels, partner or organization names, start and end dates and enrollment windows are the usual starting set. Decide early which of these are required for publication and which are optional, because Discovery will display whatever it receives, and inconsistent records produce inconsistent listings across the catalog, programs and any external catalog that reads from it.
Next, map every existing course record to the catalog fields. Export the current inventory from the legacy catalog and from the course metadata held in Studio, then build a mapping table with one row per target field. Record the source of each value, any transformation needed (for example, normalizing language codes or splitting a combined level field), and the owner who signs off on the result. Mapping usually exposes gaps: courses with no description, no owning organization or no run dates. Treat those gaps as a content decision for the course owners rather than something a script should guess at. Ask your implementation partner to show how they would handle partially complete records before the import is scheduled.
Clean duplicates and stale listings before anything moves. Duplicates often appear when the same course has been listed under several course keys, or when a re-run was published as a new course without retiring the old entry. Stale listings are courses whose enrollment windows have closed, whose runs were archived or whose content no longer reflects what is taught. Define a rule for each case: which record is canonical, which is archived and which is removed from the transition set entirely. Keep a log of every exclusion with a reason and an approver, because program and credential pages may still reference some of these records and the log is how you trace a broken link back to a decision.
Decide which records move during the transition. Not every legacy listing deserves a place in the new catalog. A practical approach is to classify records into three groups: those to migrate and publish, those to migrate as archived for reference, and those to retire without migration. Base the classification on enrollment activity, program membership and what the business still offers. Put the decision rules in writing and get them signed off by the people who own the courses and the credentials.
Plan for removal of the legacy catalog in Willow, the next Open edX release listed for December 2026. Verawood is the current named release, published on 30 July 2026, and Open edX supports only the latest named release, so an organization on Verawood will need a dated plan for its catalog transition before Willow arrives. Confirm the exact removal scope, which components and data paths are affected and whether any migration tooling is provided, in the Willow release notes and upgrade guidance. Do not assume a tool exists or that a command will do the work for you until those documents confirm it. Schedule a dry run on a non-production copy and agree the cutover, rollback and communication steps with the catalog owners.
Rollout sequence for the catalog and Discovery build
This sequence moves the catalog from planning to production in order, so each dependency is confirmed before the next step builds on it. Each step closes with a named artifact that the operations team and dependent system owners can review and keep.
Confirm the target release and support status
Start by fixing the named Open edX release the catalog will run on, and confirm its support status against the official release notes before any build work begins. Open edX supports only the latest named release at a time, so the team should also check when the next release is listed and what that means for the upgrade window. DeployOpen records the decision, the release notes reviewed and the owner who accepted the support position. The output is a release decision record that the steering group signs off before the build is scoped.
Inventory dependent consumers
List every system that reads course or program data from the catalog. Typical consumers include program and credential pathways, certificate issuance tied to programs, external course catalogs, marketing sites and partner feeds. For each consumer, record the data it reads, how it calls the service, the team that owns it and the change window it needs. The output is a consumer map with one row per dependency. Gaps found here usually change the metadata model and the test scope in later steps, so the map should be reviewed with each owning team.
Define the metadata model
Write a metadata specification that defines course, run, program and organization fields, their formats, required values, identifiers and ownership. Map each field to the source of truth, such as Studio course data, the LMS or an external system, and decide which system wins when values conflict. Include taxonomy and tagging decisions if the catalog will use them. DeployOpen reviews the specification with each consumer owner from the consumer map. The output is a versioned metadata specification with an approval record, which becomes the contract for the loader, the validation rules and the consumer tests.
Stand up Discovery and the Catalog frontend
Deploy the Course Discovery application and the Catalog micro-frontend in a non-production environment that matches the target release and the hosting model chosen for production. Confirm the runtime and data store requirements published for the release, including database, cache and search components, and record each version used. Configure authentication, the connection to the LMS and the routing that exposes the catalog. The build is complete when the services start cleanly, the frontend loads and the team can log each configuration choice. The output is a build record with versions, configuration and known issues.
Load and validate sample data
Load a representative sample of courses, runs, programs and organizations that follows the metadata specification. Include edge cases from the consumer map, such as courses with multiple runs, programs with shared courses, missing optional fields and unpublished content. Run the validation checks defined in the specification and compare search results and detail pages against the expected values. Each failure should be logged with its cause and either fixed in the loader or recorded as a specification change. The output is a validation record showing which sample records passed, which failed and why.
Test dependent consumers
Run each dependent consumer against the non-production catalog, using the calls and data formats recorded in the consumer map. Test program and credential pathways, external catalog feeds, and any marketing or partner integration that reads catalog data. Confirm that field mappings, pagination, caching and error handling behave as the owning team expects. Retest after each metadata change. The output is a consumer test record that lists each dependency, the test cases run, the results and the owner who accepted the outcome. Consumers that fail must be resolved or formally excluded before cutover planning proceeds.
Plan the legacy catalog transition
Plan how the legacy catalog will be retired, given that the topic plan places its removal in the Willow release. Identify which pages, links, feeds and API calls still depend on the legacy catalog, and decide how each one moves to the new service. Set redirects, decide how historical data is kept, and agree the communication plan with learners, course teams and partners. Confirm the removal timing against the release notes for the chosen target release. The output is a transition plan with a dependency checklist, redirect map and an agreed retirement date for the legacy catalog.
Run cutover and document operations
Move the validated metadata and configuration into production during an agreed change window, then run the post-cutover checks defined in the consumer tests. Confirm that each consumer reads from the new catalog, that redirects respond correctly and that the legacy catalog is set to read-only or retired according to the transition plan. Document the operating procedures: how data is loaded, how the release is upgraded, how backups are taken and how incidents are escalated. The output is a cutover record and an operations runbook that the platform team owns after handover.
What drives effort and cost in a catalog implementation
This table lists the factors that most change the effort of a catalog build, the direction each one pushes cost, and how to reduce it. Read it before you request a quote, because the same drivers should appear in the written scope. The main takeaway is that metadata quality and the number of dependent consumers often matter more to the final effort than the hosting choice.
| Driver | Effect on cost and effort | How to keep it down |
|---|---|---|
| Number of courses and programs | Cost rises with each course to migrate, map and test. Programs add linked course sets that Discovery must resolve correctly. | Limit the first load to published, active courses and phase the rest. Confirm the counts before scoping. |
| Quality of existing metadata | Missing or inconsistent titles, course codes, dates and images usually need manual cleanup, which can take longer than the load itself. | Agree a required field list and naming convention before import. Ask the quote to include a metadata audit. |
| Number of dependent consumers | Each site, credential service, app or report that reads catalog data needs its own API check, testing and sign-off. | Inventory consumers early and retire unused ones. Agree one API version and one test checklist for all of them. |
| External catalog connections | Feeds to partner or public catalogs add mapping, scheduling, credential handling and monitoring that continue after launch. | Limit feeds to those with a named owner. Confirm each external system's formats and update frequency in writing. |
| Hosting model | Kubernetes adds cluster, ingress and secrets work. Other self-managed setups need the same runtime tasks built by hand. | Use Tutor's documented deployment path where it fits your standards. Confirm which support contract covers it. |
| Authentication for private catalogs | Restricting catalog pages or API access to signed-in users adds identity integration and access testing for each audience. | Reuse the identity provider already connected to the LMS. Confirm the supported provider options for your setup first. |
| Timing of the Willow transition | Willow is listed for December 2026 and plans removal of the legacy catalog. Legacy catalog work started now may need rework later. | Build on the Catalog micro-frontend and Discovery, and confirm the Willow release notes before scoping. |
How the catalog connects to the rest of the Open edX platform
The catalog sits between course authoring, learner records, sign-in and reporting. Each connection has its own owner, configuration and failure mode, so plan them as separate work items. Confirm exact settings for your named release in the Open edX documentation before you commit to a design.
Studio and LMS as content sources
Studio is where course teams author content, and the LMS is where learners take it. Course metadata that teams maintain in Studio determines what appears in catalog listings, so the catalog is only as accurate as those records. Check which course fields feed the catalog in your release, and confirm how course runs, start dates and enrollment settings are published. Test one course end to end in staging before you load the full catalog.
Certificates and Credentials for programs
Program credentials depend on the Credentials service, which relies on the Discovery service to define which courses belong to a program. Course certificates come from the LMS, so a learner's program record is only as complete as the course records behind it. Confirm program definitions, course run mappings and certificate templates in staging before publication. Plan how a change to a course run affects credentials that have already been issued.
Identity providers for restricted catalog views
Open edX third-party authentication supports OAuth2 providers, SAML 2.0, Shibboleth and LTI, with older provisional support for CAS and SSL client certificates. Use these only where a catalog view must be limited to signed-in or organization members. Decide which system holds the authoritative user list, and map the attributes that control access. Test sign-in for a learner, a staff user and an anonymous visitor, then confirm the provider settings for your release.
Aspects analytics for catalog usage
Aspects captures tracking logs from the platform through the event-routing-backends plugin as xAPI statements. Those statements are stored in ClickHouse through Ralph or Vector and presented in Superset dashboards. Confirm which catalog interactions emit events that Aspects captures in your release before you promise catalog usage reporting. Plan ClickHouse storage, retention and dashboard access before learners arrive.
External catalogs and partner portals
Some organizations publish courses to a public site, a partner portal or another catalog. Treat each outbound feed as an integration with its own owner, data fields and refresh process. Confirm which Discovery interfaces or data exports your release supports for external consumers, how those consumers authenticate, and what happens to listings when a course is retired. Agree the feed schema in writing before the build starts.
Legacy catalog removal in Willow
The legacy catalog is planned for removal in Willow, which is listed for December 2026. Any link, widget, partner feed or identity rule that reads from the legacy catalog must be inventoried and moved before that release. Confirm the removal scope and migration path in the Willow release notes when they are published. Schedule this work alongside your Discovery and Credentials changes rather than after them.
What to plan now for the Willow removal of the legacy catalog
Start planning now, before the Willow release, because the legacy catalog removal is listed for December 2026 and the release notes will settle its exact scope. Open edX supports only the latest named release, and Verawood, published on 30 July 2026, is the current one. A team that runs Verawood, or any earlier release, will need to move its catalog setup onto the replacement within the same upgrade window. Waiting for the release itself leaves little room to test, fix dependencies and decide who signs off on the change.
Read the Willow release notes and the deprecation notices for the legacy catalog before you make any decisions. Confirm which legacy components, settings and interfaces are removed, which replacement the project names, and whether any step is required before the upgrade. Check the Verawood release notes too, since earlier deprecation warnings may already show up in your logs or configuration. Record each item with its source and link it to an owner. Where a notice is unclear, ask the vendor or the Open edX community for a written answer rather than assuming the removal is limited to one application.
Inventory every custom component and external link that depends on the legacy catalog. Look at custom themes and frontend plugins, LMS and Studio settings that reference catalog data, scripts or reports that read catalog output, and integrations with programs and the Credentials service, which depend on Discovery data. Also list external catalogs, partner sites, marketing pages and bookmarked course URLs that point into your catalog. For each item, note the owner, the business function it supports and how it would fail if the catalog changed. This list becomes the scope for testing and for any remediation work.
Test the replacement in a staging environment built on the same release you run in production. Staging should match production in version, configuration, plugins and a realistic copy of course and program data. Verify course discovery, search, program pages, certificate links, external feeds and every item on your dependency list. Run the same checks after each change, and keep a tested rollback path. If you deploy with Tutor, pin the versions you tested so that production matches the staging results.
Budget for the planning work separately from the upgrade itself. The release-note review, the dependency inventory and the staging tests are one-time efforts, but a quote should also cover ongoing checks when later releases change the catalog again. Ask for a written scope that names the release notes reviewed, the inventory deliverable, the staging environment, the test cases and the rollback plan. Confirm who pays for fixes to custom code and who approves go-live. A fixed-scope quote with these items makes the Willow change easier to schedule and audit.
Questions teams ask before building the Open edX catalog
How much does an Open edX course catalog implementation cost?
The cost follows from the written scope, and DeployOpen does not publish a price list. The main components are discovery and metadata design, configuration of the Catalog micro-frontend and the Course Discovery application, integration with the LMS and, where programs are shown, the Credentials service, testing, and handover documentation. Most of this is one-time work. Recurring costs include hosting in your own accounts, upgrades for each named Open edX release, and any support retainer you choose. Costs rise with the number of courses and programs, the quality of existing metadata, the number of external catalog feeds, and the amount of custom branding. Ask for a quote with one line per component, the assumptions about who supplies metadata, the upgrade and support options, what is excluded, and the milestones tied to payment.
How long does a catalog project take from start to launch?
No duration is fixed for every catalog, so the timeline is set by the scope agreed in writing. The factors that move it most are how ready your course and program metadata is, how many catalog sources must feed into Discovery, how quickly decision owners sign off on visibility and naming rules, and when staging environments and identity details become available. Release timing also matters. The Open edX release notes list Verawood as published on 30 July 2026, Willow for December 2026 and Xylon for June 2027, and those pages are the place to confirm current dates. Because Open edX supports only the latest named release, plan the catalog build against the release you will run at launch and the upgrade you expect next. Ask for milestones with written acceptance criteria.
What must our team provide for a catalog build?
Most delays come from inputs the client owns, so agree on them before the build starts. You will need course descriptions, subject and category taxonomy, images and branding assets, run dates and enrollment windows, and any pricing or access rules that the catalog will display. For programs, you need written definitions with the ordered list of courses and the rules for completion. You also need named decision owners for catalog visibility, naming and program rules, and a single approver for sign-off. On the technical side, provide access to staging and production-like environments, DNS and certificate ownership, identity provider details for any single sign-on, and contacts for the hosting team. Confirm each item in the statement of work so that gaps are visible early.
Can an internal team build an Open edX catalog without a partner?
An internal team can build it if it has skills in Python and Django, React for the frontend, Docker and Kubernetes, and enough time to run a production system. 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. A Tutor-based deployment still needs MySQL 8.0, MongoDB 7.x and Memcached for the Open edX development stack, and a multi-node deployment needs a shared Django cache backend such as Redis or Memcached. Before deciding, confirm your team's skills, the staffing you can commit for the build and for ongoing upgrades, and whether a fixed-scope partner would help with knowledge transfer and documentation.
How does the Willow release change the catalog work?
Willow is the release in which the legacy catalog is planned for removal, so any site still using it needs a migration to the Catalog micro-frontend and the Course Discovery application before that upgrade. Start with an inventory of everything that depends on the legacy catalog: links, embedded listings, program pages, external feeds and any custom templates. Then map each dependency to its Discovery equivalent, test the data in staging, and schedule the change alongside the Willow upgrade. The Open edX release notes list Willow for December 2026, and they are the authority on what is removed and what changes. Confirm those details with the release notes and your upgrade plan, and check whether the Willow upgrade affects other applications you run.
How is the course catalog different from the Credentials service?
The catalog publishes what learners can find and enroll in, including courses, course runs and programs, through the Catalog micro-frontend and Course Discovery. The Credentials service issues and displays certificates, including program certificates. The two are separate applications with separate data, but they are linked: program certificates depend on program definitions held in Discovery, so a change to program structure affects both. Plan them together. Decide who owns program definitions, how changes are versioned, and how learners see their achievements. Check the Credentials service page for certificate templates and generation rules, and confirm the Discovery dependency for your planned programs before fixing any program design.
What should a written quote for a catalog implementation include?
A useful quote lists the deliverables and the systems they touch, not only a total. Ask for the scope of the catalog and Discovery configuration, the metadata and program design work, integration points with the LMS and Credentials, and the testing approach with named acceptance criteria. It should state who hosts each environment and who holds the credentials, which items the client supplies and by when, and what is excluded, such as custom XBlocks or frontend work outside the catalog. Also request the handover package, the change request process, the payment milestones, and the terms for upgrades and support after launch. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so ask for the same level of detail from any provider you compare.
How DeployOpen scopes and delivers the catalog implementation
DeployOpen plans the catalog as part of the wider Open edX platform, so the Catalog micro-frontend, the Course Discovery application and the Tutor deployment are designed together. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before build work starts. Ongoing support is available as a retainer.
How we scope
- The written scope lists which catalog pages, course data sources and external consumers are included.
- We identify which programs and credentials depend on Discovery data before any build begins.
- We confirm the release line and the planned Willow removal of the legacy catalog against the release notes.
How we build
- We deploy the Course Discovery application and Catalog micro-frontend with Tutor in your chosen environment.
- We connect catalog data to published courses and test how course metadata and images appear.
- We test catalog pages, API access and external consumers in staging before any production change.
How we hand over
- We document the deployment, configuration, data flows and runbooks so your team can operate the catalog.
- We walk the platform owners through Tutor settings, plugin choices and environment configuration.
- We record the steps for retiring the legacy catalog, with an inventory of every consumer still reading from it.
How we support
- We plan upgrades per named release, since Open edX supports only the latest named release at a time.
- We review each release's catalog changes before upgrading, including the planned Willow removal of the legacy catalog.
- Ongoing support, upgrades and testing are available as a retainer once fixed-scope delivery ends.
