Why an Ulmo site needs a planned move to Verawood
If your live LMS and Studio run on Ulmo, deployed with Tutor, your site is running a release that Open edX no longer supports. The project states that the latest named release is the only supported release and that it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026. Staying on Ulmo means no upstream fixes for security or defects, and each month the gap grows wider. Before anything else, confirm the current supported release on the Open edX release notes page, since the named release sequence moves forward on its own schedule.
Moving from Ulmo to Verawood is a platform change, not a version bump. The upgrade includes data migrations that alter existing course and platform data, including the course ID uniqueness migration, MariaDB table rewrites that can run for a long time on large databases, notifications that are enabled by default, and the legacy library migration. Several XBlocks have been extracted from the core platform, and the instructor dashboard and catalog defaults have changed. Do not schedule a window until you have read the Verawood release notes and confirmed the supported upgrade path, including whether any intermediate Tutor or platform steps are required from Ulmo.
The practical decision is how to sequence the work. Ask your partner or internal team to inventory every custom plugin, theme, XBlock and Tutor hook on the current site, and to check each one against the Verawood changes before the move. Confirm how long a full backup and restore takes for your database and media storage, because the migrations will be run against a copy of production first. Agree who signs off on the staging results and who can call a rollback. A quote should list these checks, the staging rehearsals and the production cutover as separate line items so you can see what is one-time and what carries forward into ongoing operations.
What changes between Ulmo and Verawood
This table lists the changes that affect an Ulmo to Verawood upgrade, from the data migrations to the new Verawood features. Read each row from left to right: the impact column describes what learners, authors or staff will notice, and the action column is the work to schedule before cutover. Start with the first rows, because the data migrations carry the most risk to existing course content.
| Change | Impact on operators | Action needed |
|---|---|---|
| Course ID uniqueness migration | Existing course identifiers are checked against the new uniqueness rules, which can stop or change migration results. | Run a duplicate course ID check on a copy of production data before scheduling cutover. |
| MariaDB table rewrites | Some table changes rewrite large tables, which needs extra disk space and a longer maintenance window. | Measure table sizes on staging and confirm the window and free disk space with your database team. |
| Notifications on by default | Users may receive notifications that were off before the upgrade. | Review notification settings and decide which defaults to keep before go-live. |
| Legacy library migration | Content libraries are migrated, so imports, references and course links can change. | Test library content and its references in courses on staging before cutover. |
| Extracted XBlocks | Some blocks now ship as separate packages, so custom XBlocks may need dependency changes. | Review every custom XBlock and confirm each dependency is installed and pinned in your build. |
| Instructor dashboard and catalog defaults | The redesigned instructor dashboard changes staff layouts, and catalog defaults change what learners see. | Brief course staff on the new dashboard and confirm catalog defaults with the business owner. |
| Studio sidebar, tagging and taxonomy | Authors see a new Studio sidebar, and tagging and taxonomy management adds new metadata to content. | Run author training on staging and agree who owns taxonomy terms before tagging starts. |
| AI Extensions Framework | The release adds a framework for AI extensions, which requires a decision on whether to use it. | Confirm its default state in your build, then decide whether to enable it and review the data it handles. |
| Frontend plugin slots and LTI Advantage Complete certification | New frontend plugin slots and LTI Advantage Complete certification affect custom frontend code and LTI tool integrations. | Check custom frontend plugins against the new slots and confirm LTI support with each tool provider. |
Which migrations touch data and why they take longer
Three changes in the Ulmo to Verawood upgrade read or rewrite stored data, so this part of the work cannot be handled as a code deploy. They are the course ID uniqueness migration, the MariaDB table rewrites, and the legacy library migration. Each one can block the upgrade or extend the cutover window, and each depends on the content and database your own LMS has accumulated over the years. The course ID uniqueness migration checks that every course key in your LMS is unique and well formed. A course key combines an organization, a course number and a run, and the platform uses it to tie together enrollments, grades, certificates and links. Duplicate keys can appear after old imports, manual copies or renamed courses. Keys with characters or structures the platform no longer accepts can also stop the migration. Before you schedule anything, run an audit of your course keys, list every duplicate and malformed key, and agree with course teams how each one will be resolved. Renaming a key is a content decision with downstream effects, so it should be made deliberately.
The MariaDB table rewrites are the main reason the upgrade needs a maintenance window. When a schema change rebuilds a table, the database copies its rows into new storage and then swaps the table in. That copy needs free disk space, often in an amount tied to the size of the table being rebuilt, so check disk headroom on the database host before the upgrade starts. While a rebuild runs, writes to that table can be delayed or blocked, which is why learners and course authors must be away from the platform. The duration depends on the row counts and sizes of your own tables, especially large tables that grow with activity. Measure those sizes with queries against the database catalog, then rehearse the rewrites on a restored copy of production. Confirm which tables the Verawood migrations rewrite and in what order in the Tutor and Verawood documentation.
The legacy library migration moves content from the older library structure into the current content library model. The reader's responsibility is to check the result, not only to confirm that the command completed. After the migration, verify that every library still appears in the courses that used it, that components render for learners and authors, and that author permissions carried over to the new structure. Sample libraries from each course team, since a library that works in one course may depend on a component or setting that another course does not use. Record any library that cannot be migrated cleanly and decide, with its owners, whether to fix, rebuild or retire it before cutover.
Measure your own platform before you estimate time for any of these steps. Count your courses and libraries, record the sizes and row counts of the largest database tables, and note the free disk space on the database host. Restore a recent backup into a staging environment that matches production as closely as possible, and time a full rehearsal of the data migrations there. Use those results, not figures from other sites, to plan the maintenance window and the rollback point. Exact migration commands, their order and any prerequisite checks should come from the Tutor and Verawood documentation for the versions you run. A written scope can include these audits and rehearsal runs as separate deliverables, so the window is planned from evidence.
Preparing the Open edX site before the upgrade window
Most of the upgrade risk for Ulmo to Verawood is settled before the window opens. The six cards below cover the preparation work: a verified backup, a complete inventory of site-specific code and configuration, a rebase plan for custom images, a staging copy to rehearse on, a review of integrations tied to the platform version, and a plan for the people who use the site.
Verified full backup and restore test
Take a full backup of the MySQL or MariaDB databases and the media storage that hold course content, uploads and certificates. Then restore that backup into a scratch environment and confirm that the LMS and Studio both start and show expected course listings and learner records. A backup that has never been restored has not been verified. The artifact is a restore record listing the backup identifiers, the restore date, the checks performed and any gaps found.
Inventory of custom code and overrides
List every custom XBlock, theme, plugin and Tutor configuration override, with the version or commit each one pins to. Tutor plugins and override settings are easy to miss because they live in environment files and plugin settings alongside the application code. Note which entries touch areas changed in the Verawood release notes, such as the instructor dashboard or Studio. The artifact is a dependency inventory with an owner, a source location and a risk note for each item.
Fork and custom image rebase plan
If the site runs a fork of edx-platform or custom Tutor images, decide how each carried change moves onto the Verawood base. Check whether upstream has already absorbed any patch, since keeping the patch list short reduces what must be retested. Build the image from the new base in a branch and record each build step so the next upgrade can repeat it. The artifact is a rebase plan listing every patch, its status on the new base, its owner and the test that proves it works.
Staging environment from production copies
Build a staging environment from a recent copy of production data, running the same Tutor version, plugins and configuration as the live site. Sanitize learner personal data in the copy according to your privacy policy before anyone outside the operations team uses it. The copy must be large enough that table sizes represent production, because the course ID migration and MariaDB table rewrites take longer on large tables. The artifact is a staging runbook with the copy date, sanitization steps and known differences from production.
Identity and analytics integration review
Review each third-party authentication provider and each Aspects analytics component against the Verawood release. Providers may be OAuth2 services, SAML 2.0 identity providers, Shibboleth or LTI tools, and Aspects routes tracking logs as xAPI statements into ClickHouse for Superset dashboards. Confirm the configuration owner for each provider and test sign-in and event flow in staging. The artifact is an integration matrix recording provider type, owner, test result and any change still needed.
Communication plan for authors and learners
Tell course authors and learners what will change and when. Authors need a freeze date for edits, notes on any course ID or library changes they will see in Studio, and a named contact for problems. Learners need notice of planned downtime and of any sign-in, dashboard or certificate differences they may notice. Agree the messages with the site owner before the window is announced. The artifact is a communication calendar listing each audience, message, send date and owner.
How to sequence the Ulmo to Verawood upgrade with Tutor
The sequence moves a live Ulmo site to Verawood through a frozen configuration, a verified backup, a staging rehearsal and a planned database window, with a check and a rollback point at each stage. Exact Tutor command syntax and any intermediate release stops must be confirmed against the Tutor and Open edX upgrade documentation for the versions in use.
Freeze configuration and code
The platform owner and the Tutor operator agree a change freeze on the Ulmo site, covering the Tutor configuration, plugins, custom XBlocks, theme and any forked edx-platform code. Record the current Tutor version, the configuration file and the image tags in use, because the previous image tag becomes the rollback target. Store the frozen configuration in version control and confirm that no changes land outside the upgrade branch. This step is done when the frozen snapshot exists and a second person has signed off on it.
Back up and verify restore
The operator takes a full backup of the LMS and Studio databases, the document store holding course structure, media and course asset storage, and the Tutor data volumes. The backup is then restored into a separate environment, which becomes the rollback point together with the previous image tag. Confirm with the Verawood notes which database engine and version the upgrade assumes, since backup tooling depends on it. This step is done when the restored copy starts, a learner and a course author can sign in, and a sample course loads with its content intact.
Build the staging upgrade with Tutor
Run the Tutor upgrade path against the restored copy in staging, following the Ulmo to Verawood steps and any intermediate release stops listed in the Open edX and Tutor upgrade notes. Rebuild custom images from the frozen configuration and plugins, and confirm that each plugin has a release compatible with Verawood. Stop at the first failed migration or image build and record the error before changing anything. This step is done when the staging stack starts from the new images and the running build identifies itself as Verawood.
Run course ID and library checks on staging
Run the course ID uniqueness migration against staging copies of the course data, then review the report for duplicate or conflicting course identifiers. Inventory every legacy content library that the Verawood notes require to be migrated, and assign an owner to each finding. For each affected course, record a decision to correct it in the source, remap it during migration, or exclude it, and get the course team to confirm that decision. This step is done when the report has no unresolved conflicts and every legacy library has a recorded migration decision.
Apply MariaDB table changes in the planned window
Schedule a maintenance window with stakeholders, keep learners and authors out of the platform for its duration, and apply the table rewrites on production exactly as rehearsed on staging. Use the staging run to plan the window, and record the actual time taken for the next upgrade. Take a fresh backup immediately before the change, since some table rewrites cannot be reversed in place. This step is done when the migration completes without errors, row counts on the largest tables match pre-change figures, and the backup taken just before the change has been verified as restorable.
Deploy Verawood images and run smoke tests
Deploy the Verawood images to production while keeping the previous image tag available, so the rollback can run without a rebuild. Run smoke tests on the LMS and Studio: sign in, open a course outline, load a unit, edit and save a component, publish it, and enroll a test learner. Check the service logs on both applications for errors raised during these actions. This step is done when the smoke test checklist passes on both services. If any check fails, roll back to the restored backup and previous image tag before the next step begins.
Validate instructor dashboard and catalog defaults
Open the redesigned instructor dashboard on a test course and confirm that the sections instructors depend on load and show enrollment and grade data that matches staging. Confirm the notifications setting with the platform owner, because Verawood enables notifications by default and the site should choose its position on purpose. Review catalog defaults, including course visibility and listing settings, against the approved configuration. This step is done when instructors sign off on the test course and catalog settings match the frozen configuration.
Reopen the site to users
Lift maintenance mode, announce the reopening to learners and course teams, and watch error logs, sign-in success and background task queues through the first working period. Keep the rollback point, the restored backup and previous image tag, available until the platform owner confirms stability. Record the final build, the database migration log and each sign-off decision in the upgrade record. This step is done when the platform owner signs the upgrade record and the site accepts learners without a rollback decision.
Testing and rollback for an Open edX upgrade
The most important decision in an Ulmo to Verawood upgrade is the point after which you stop being able to go back. Because the upgrade includes MariaDB table rewrites, rollback means restoring the pre-upgrade database backup, not reversing individual migrations. Set that decision point in the cutover plan before the rewrites start, name who can call it, and agree the criteria that must be met before it is passed. Everything before that point is a go or no-go checkpoint. Everything after it is a forward fix.
Testing should run in layers, each aimed at a different failure. First, run the data migrations as dry runs against a recent copy of production data, timing them and recording every warning, including the course ID uniqueness migration and the legacy library migration. Second, run functional tests that cover courses, enrollments, certificates and grading, since these are the paths learners and instructors depend on most. Third, run regression tests for each custom XBlock and each theme against the new release, including the extracted XBlocks that now need to be installed separately. Fourth, test every identity provider login path, including SSO, because login failures block every learner at once. Fifth, measure the new instructor dashboard under realistic instructor load and compare response times with the current site.
Plan for the learner activity problem before you rehearse the rollback. A database restore returns the platform to the state captured in the backup, so enrollments, submissions, progress and certificates earned after cutover are lost if you roll back. Decide whether the site will be placed in read-only or maintenance mode at cutover, how long the parallel period lasts, and whether activity logs or event data will be exported and reconciled. Confirm with your own team how tracking logs are retained, because analytics pipelines that read from the platform may also need to be rewound or flagged.
Rehearse the full rollback, not just the restore command. Restore the pre-upgrade backup into a separate environment, start the Ulmo images, run the health checks and confirm that courses, grades and logins work. Time each step and compare the result with your decision window. Confirm that the backup includes the MongoDB content store and any media storage that the platform references, since a database-only restore can leave course content and database records out of step. Record who signs off the rollback and where the communication to learners will be posted.
Ask your implementation partner to show the test plan, the migration dry-run logs, the rollback rehearsal record and the cutover decision criteria in writing before go-live. Confirm which tests are automated, which are manual, and who owns each test result. The quote should list these tests and the environments they run in, so that the cost of rehearsal and test data preparation is visible and not left to the internal team to absorb.
What makes an Open edX upgrade take longer
This table lists the sizing drivers that most often lengthen an Open edX Ulmo to Verawood upgrade and what each adds to the work. Count each driver in every environment before requesting a quote, because the same platform can need very different effort depending on its customizations. The main takeaway is that custom code, data volume and integrations usually matter more than the release notes alone.
| Driver | Why it adds effort | What to measure |
|---|---|---|
| Custom XBlocks | Each custom XBlock must be tested against Verawood and checked for any dependency on the XBlocks extracted in this release. | Count of custom XBlocks, and which ones import or depend on extracted XBlocks. Inventory from source control. |
| Courses and libraries | The course ID uniqueness migration and the legacy library migration both touch every course and library, so collisions and library types need review. | Total courses and libraries per environment, legacy libraries, and course IDs that would collide under the new uniqueness rule. |
| MariaDB database size | The table rewrites copy and lock large tables, so run time and free disk space grow with table size. | Per-table size of LMS and Studio schemas on a recent production copy, plus free disk space. Confirm rewrite requirements in the release notes. |
| Themes and frontend plugins | Themes and frontend plugins built against older slots need rebuilds, and Verawood adds new plugin slots and a redesigned instructor dashboard. | Count of themes, frontend plugins and overridden components, each checked against changed or new slots. |
| Tutor plugins and image forks | Custom Tutor plugins and forked images pin hooks and versions that must move to the new Tutor release and rebuild cleanly. | Count of plugins, fork differences from upstream, and steps in the image build pipeline. |
| Integrations | Identity providers, Aspects analytics pipelines and external graders each need re-verification after the platform changes. | Identity providers and their protocols (OAuth2, SAML, Shibboleth, LTI), whether Aspects runs, and external grader endpoints. |
| Environments | Each environment repeats the upgrade and test cycle, and configuration drift between them multiplies the work. | Number of environments, their current release and configuration differences, and whether production data can be refreshed for testing. |
Open edX Ulmo upgrade cost, time and what it needs from your team
What drives the cost of this Open edX upgrade and who gets paid?
Cost depends on who does the work and how much of your platform is customized. Internal staff time is easy to overlook, since your operations, development, content and quality assurance people spend time on testing, decisions and sign-off, all paid from your budget. A partner's work is usually fixed-scope, with deliverables and timelines agreed in writing before work starts. Retained support, upgrades and continuous testing are recurring and optional. Costs rise with custom XBlocks, forks, plugins, third-party authentication and analytics integrations, data volume and the number of environments you need for testing. Infrastructure, such as staging servers and backups, is billed by your own cloud or data center provider. Ask for a quote that lists each deliverable, the environments included, the test cycles, and which items recur.
How long does an Ulmo to Verawood upgrade take and what sets it?
Duration depends on scope and on how much testing your site needs before cutover. The main drivers are the number of custom components and plugins that must be tested against Verawood, the size of the database tables affected by the MariaDB table rewrites, the number of environments you run, how many test cycles your content owners need, and whether your change calendar allows a maintenance window when you want it. A current backup and a staging copy of production shorten the early discovery work, so ask how each one changes the schedule. Any timeline should appear in the written scope with its assumptions listed. Ask which assumptions would move the date, such as late decisions on course identifiers or delayed access to infrastructure.
Can an internal team upgrade Open edX to Verawood without a partner?
Yes, an internal team can perform the upgrade if it has Open edX operations skills, Tutor experience and developers who can maintain your custom code. The edx-platform maintainers recommend running Open edX in production through a service provider or with Tutor, because bare-metal installation is complex and receives limited community support. Before deciding, check four things: whether your team has moved a Tutor-based site through a release change, who owns custom XBlocks and forks, who will own the test plan and cutover, and who will handle incidents after go-live. If any of these gaps exist, a fixed-scope engagement can cover them while your team keeps the knowledge of the site.
What does the upgrade need from our team?
The work needs access, data, decisions and time from your side. Provide access to the cloud account, data center or network where the site runs, along with the accounts needed to build and deploy staging and production. Supply a recent copy of production data for test runs, with your data protection rules applied before it leaves production. Name decision makers who can settle questions about course identifiers, notifications, catalog defaults and the instructor dashboard changes in Verawood. Content owners must check courses after the test migration. Agree a maintenance window with the business, including a rollback plan and a message for learners and instructors. Also share your custom code, plugin list and integration details, including identity providers and analytics.
Can the Ulmo to Verawood upgrade be done in one step?
It depends on your configuration and on the release notes for each release between your site and Verawood, so confirm the path before you commit to a schedule. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time, so a site still on Ulmo is running a release the project no longer supports. The number of steps depends on how Tutor versions map to the releases, which plugins you run, and whether your custom code and forks still work at each stage. Ask the provider to show the upgrade path in the written scope, listing each intermediate step, its tests and its rollback point. Do not assume a single change is safe just because the platform permits it.
What happens after cutover to Verawood?
After cutover, the work moves to verification, handover and operations. Confirm that learner sign-in, course delivery, grading, certificates and integrations work in production, and that backups run and restore correctly. Hand over runbooks, configuration records and a list of changes made to custom code. Your team then takes over monitoring and incident response, or a retainer covers them. Plan for the next releases as well: Open edX lists Willow for December 2026 and Xylon for June 2027, and each release needs its own upgrade work. Ask whether post-cutover support is in the written scope, how long it lasts, and what a retainer covers for upgrades, testing and security updates.
Does DeployOpen issue compliance reports for an Open edX upgrade?
No. DeployOpen does not issue audit reports, attestations or certifications. It prepares the systems, controls and evidence an assessment may need, such as configuration records, change logs, backup test results and access reviews for the upgrade. An independent auditor or certification body reviews that evidence and issues any report. Ask the provider which evidence it will produce for your assessment, in what format, and who will own it after handover. Also confirm with your auditor which records they accept before the upgrade starts, since requirements differ by framework and by organization.
How DeployOpen scopes and delivers an Open edX upgrade
DeployOpen scopes the Ulmo to Verawood upgrade as a fixed-scope piece of work, agreed in writing before changes start. Delivery covers the Tutor-based upgrade, the data migrations and the verification of each affected feature. The work starts from the Verawood release notes and your current customizations. Ongoing support after handover is available as a retainer.
How we scope
- Written scope lists each Ulmo to Verawood change that affects your site, including the courses and data involved.
- Inventory covers custom XBlocks, themes, plugins and forks, so each one gets a keep, adapt or retire decision.
- Deliverables, exclusions and acceptance checks are agreed before work starts, and the quote follows from that written scope.
How we build
- Rehearse on a copy of production data, timing the course ID uniqueness migration and MariaDB table rewrites.
- Review the legacy library migration, extracted XBlocks and notifications on by default against your course settings.
- Test the instructor dashboard redesign and catalog defaults with staff accounts before any learner-facing change goes live.
How we hand over
- Handover includes the upgrade runbook, the migration log, and the configuration changes made to Tutor and plugins.
- A rollback procedure and a post-upgrade verification checklist are documented for your operations team to run.
- Walkthrough sessions with your administrators cover what changed, where to look and what to watch after go-live.
How we support
- Post-go-live fixes are scoped separately, so the upgrade record stays accurate for your change board.
- Ongoing support and upgrades for later releases are available as a retainer, once the handover is complete.
- Plan the Willow release next, since Open edX supports only its latest named release at any time.
