Preparing Open edX for the Willow release

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. Verawood is the current named release, published on 30 July 2026, so a Verawood site has no supported version to wait on. The next releases, Willow and Xylon, are listed for December 2026 and June 2027. A site that waits for Xylon would spend the gap running software the project no longer supports, because Willow ends Verawood's supported status when it ships. The planning question is therefore not whether to move to Willow, but how much preparation fits before the Willow release. Confirm the exact Willow release date in the Open edX release notes before you fix a calendar.

Staying on Verawood after Willow ships means the site owner carries the consequences alone. Core fixes for the release stop coming from the project, so any security patch, dependency update or bug fix must be written, tested and maintained by your team or a provider. You also lose the community answers and the compatibility work that follows the supported release, including support from newer Tutor versions and from plugins that move to Willow. Infrastructure cost continues while the platform stops changing with the ecosystem. Ask your team to list every plugin, fork and custom image that pins a Verawood-specific behavior, because that list is the real measure of how much staying put would cost you.

The move to Willow should be planned as a dated project with a named owner for each dependency. Start with the items that block the upgrade: replacing the MinIO plugin, moving edx-val storage to Django STORAGES, testing the extracted XBlocks and confirming RBAC course authoring behaves as your course teams expect. Set a content and customization freeze date so that course authors and developers stop changing code paths you are about to test. Record each decision in a short plan that names who tests what, which environment holds the staging copy, and who signs off the cutover. Confirm each dependency's Willow compatibility with its maintainer rather than assuming it from the Verawood release notes.

Choosing between an in-place Tutor upgrade and a rebuild depends on how far the running site has drifted from stock Tutor. An in-place upgrade suits a site that runs standard Tutor configuration, uses plugins with Willow-compatible releases and keeps its data in a predictable state. A rebuild suits a site with heavily modified forks, custom images that no longer match upstream, or settings edited by hand outside Tutor's configuration. Illustratively, a site with one maintained plugin and no forks may upgrade in place, while a site with three diverged forks may find a fresh Willow build with migrated data is easier to test. Ask for a written assessment and a test upgrade on a copy of production before committing to either path, and check the upgrade steps for your Tutor version in the Tutor documentation.

Storage is the first item to check because it is the most likely to block a Willow upgrade from starting. Verawood sites that use the MinIO plugin to hold uploads, video assets, course exports and other files in object storage need a replacement path before Willow arrives in December 2026. Confirm in the Open edX release notes and the Tutor plugin documentation whether the MinIO plugin is still supported on Willow, and whether any Tutor-level settings change with it. Start by listing every place your deployment writes files: the LMS and Studio media stores, edx-val video storage, and any custom XBlock or plugin that saves to a bucket. This inventory turns a broad dependency into a finite list of settings to move.

The replacement has to do more than accept uploads. It must keep the object paths that existing course content and video records point to, serve public and private assets under the access rules your courses already use, and authenticate with credentials held in your secrets store and kept out of configuration files. Decide early whether the new backend will be another S3-compatible service in your infrastructure, such as a Ceph deployment or a MinIO instance operated separately, or a service from a different provider. Confirm with the replacement package's documentation that it supports the S3 API features your media pipeline uses, including object metadata and content types. Test those assumptions before any settings change reaches staging.

edx-val stores video metadata and encoded video files, and its file storage has to be configured through Django's STORAGES setting, the framework's mechanism for naming storage backends and their options. Moving edx-val onto STORAGES means replacing any older storage-class setting with a named backend entry, then confirming which entry edx-val reads for video files and which one handles default media. Confirm the exact setting names, backend class paths and any edx-val override against the Willow release notes and the Tutor documentation before you write them into your settings overrides. Keep the change in one reviewed commit so the MinIO-era and STORAGES-era configurations can be compared line by line.

Configuration changes are the smaller part of the work. Existing objects must be copied from the old bucket to the new backend with their keys unchanged, and each copy must be verified by object count, total size and sampled checksums. Measure volume before you plan the window, because the number of objects and bytes in each bucket determines how long the copy runs and how much bandwidth it uses. Video storage is often the largest share. Keep the old bucket readable until the new backend passes verification, then switch settings in a planned window. Ask the release notes and Tutor documentation whether the Willow upgrade rewrites any storage keys. If it does, that step belongs in the same plan.

Test in staging with a copy of production-shaped data, including a meaningful sample of existing videos. Upload a course image and a file asset in Studio, upload a video and confirm it processes and plays in the LMS, export a course and re-import it, and download a file as a learner would. Check that URLs and permissions behave the same for public and enrolled users, and that certificates and other generated files still render. Record each result against the inventory from the first step. Keep the MinIO plugin and the old bucket in place as the rollback path until production has run cleanly for a period your operations team agrees on. When you request a quote, ask for the inventory and settings work, the data copy and verification, and the staging test cycle as separate lines, with the responsible party named for each.

The rollback plan depends on three restore points that must exist and be verified before the Willow cutover starts. The first is the database snapshot taken immediately before any migration runs. For a Tutor-managed site, this covers the relational data behind the LMS and Studio, and it should be taken with writes frozen so that it is internally consistent. The second is the state of object storage, which holds course assets, uploads and, once the edx-val storage move to Django STORAGES is complete, the video files that the platform resolves through that configuration. Confirm whether your storage backend supports versioning or snapshots, because a database rollback that leaves storage pointing at newer objects will break course pages. The third is the previous Tutor configuration, plugin list and container images, kept in version control with the exact tags that ran in production.

Set the rollback criteria in writing before the window opens. Name the person who makes the decision, list the checks that must pass after migrations, and record the point after which rolling back costs more than fixing forward. Likely triggers include failed migrations, errors on a smoke test of course launch, broken video playback once the storage change is live, and failed sign-in through your identity provider. Note the time by which the decision must be made, because every hour of learner activity after cutover adds data that a rollback must reconcile. Assign one person to own the rollback runbook and rehearse its commands in the order they will run. Ask your internal team or implementation partner to confirm how long a restore takes at your data volume, since that depends on your own infrastructure.

An untested restore gives no assurance. Before cutover, restore the pre-migration snapshot, the storage state and the saved Tutor configuration into an isolated copy of the environment, using the same images and plugin versions that production runs. Then check what learners and course teams notice first: sign-in, course outline and unit rendering, a sample of graded assessments, discussion threads, Studio access for an author, and playback for a sample of video assets. Confirm that the database and storage come from the same point in time by comparing a few known records, such as the most recent enrollment and the most recent asset upload. Repeat the same checks after any restore in production, and record the results so the team can show what was verified and when.

Any data written between the snapshot and the rollback must be reconciled before users return. This includes new enrollments, certificate issuance, grades, forum posts, Studio edits, uploads and analytics events. Start by listing what the platform wrote during the window, using database transaction logs if you keep them and application logs otherwise. Then decide, for each data type, whether to replay the records into the restored system, ask learners or authors to resubmit, or accept the loss and tell stakeholders. Grades and certificates usually need the most care because they affect credentials. If you run Open edX Aspects, analytics pipelines may already hold events that the restored database no longer contains, so plan how those will be corrected. Document each decision so the change record is complete.