Підтримка Moodle 5.0 завершується: план переходу
Актуально для: Moodle LMS 5.0.x
Оновлено: 11 серпня 2026 року
5 жовтня 2026 року Moodle 5.0 перестане отримувати виправлення безпеки. Станом на 11 серпня до цієї дати залишається 55 днів — 7 тижнів і 6 днів. При цьому загальна підтримка гілки 5.0 уже завершилася 20 квітня 2026 року: зараз вона отримує лише виправлення, передбачені для security-only гілки. Це підтверджує офіційний календар релізів Moodle.
Для закладу це не означає, що 5 жовтня платформа раптом перестане запускатися. Змінюється інше: після завершення security support не варто розраховувати на нові виправлення безпеки для Moodle 5.0. Тому завдання на найближчі тижні — не «оновитися будь-якою ціною», а підготувати керований перехід із перевіреним резервним копіюванням, тестовим середовищем і планом відкату.
Зміст
- Що саме закінчується 5 жовтня
- Чим ризикує заклад на непідтримуваній версії
- Куди переходити
- Реалістичний графік на 8 тижнів
- Якщо не встигаєте
- FAQ
Що саме закінчується 5 жовтня
У Moodle є два важливі строки підтримки: general support і security support. Для звичайних major-релізів Moodle HQ передбачає приблизно 12 місяців загальної підтримки та 18 місяців безпекової. LTS-релізи отримують довший період виправлень безпеки. Цю модель описано в політиці життєвого циклу Moodle.
Для Moodle 5.0 загальна підтримка завершилася 20 квітня 2026 року. Відтоді гілка має статус security-only: до неї можуть бекпортувати виправлення безпеки, приватності, втрати даних та пов’язаних регресій. Після 5 жовтня 2026 року закінчується і цей період. Політика бекпорту Moodle прямо розрізняє підтримувані security-only та непідтримувані гілки; для останніх можливості бекпорту дуже обмежені. Детальніше — у Moodle Backporting policy.
Важливо й інше: 10 серпня 2026 року вийшла Moodle 5.0.9. Тобто до міграції сайт на 5.0 варто принаймні тримати на актуальному point-релізі своєї гілки, але це не скасовує дедлайн 5 жовтня. Актуальний перелік point-релізів також наведено на офіційній сторінці Releases.
Чим ризикує заклад на непідтримуваній версії
Головний ризик — не сам номер версії, а відсутність гарантованого потоку виправлень для нових уразливостей. Якщо після завершення підтримки буде виявлено проблему, яка зачіпає Moodle 5.0, заклад не повинен планувати безпеку так, ніби виправлення для цієї гілки обов’язково з’явиться. Сам Moodle рекомендує переходити на підтримувані версії.
Для освітньої платформи наслідки потенційного інциденту особливо неприємні, бо в Moodle зазвичай зосереджені облікові записи, навчальні матеріали, подані роботи, оцінки та інші дані навчального процесу. Тому технічний борг у вигляді непідтримуваної LMS варто розглядати разом із ризиками доступності сервісу, конфіденційності даних і відновлення після інциденту.
Є й організаційний аспект. Внутрішні політики безпеки, вимоги аудиту, умови кіберстрахування, грантові або контрактні зобов’язання можуть містити власні правила щодо підтримуваного ПЗ та строків встановлення оновлень. Універсальної вимоги для всіх закладів тут немає: потрібно перевірити саме свої документи. Але якщо організація декларує використання підтримуваних компонентів, Moodle 5.0 після 5 жовтня вже не відповідатиме цьому критерію з боку upstream-підтримки.
Практичний висновок: не варто чекати на конкретну вразливість, щоб почати міграцію. До дедлайну корисніше закрити керовані речі — сумісність сервера, плагінів, теми, автентифікації, інтеграцій і резервного копіювання. Окремо варто перевірити, хто в закладі приймає рішення про аварійний відкат, де зберігається актуальна копія конфігурації та хто має доступ до неї. Без цього навіть технічно коректна міграція може затягнутися через організаційні паузи.
Ще один практичний ризик — відкласти перевірку до production window і лише тоді виявити, що цільова версія потребує іншого PHP, новішої СУБД або несумісна з критичним плагіном. Такі блокери дешевше виявляти на етапі аудиту, коли ще можна змінити сценарій, а не під час простою LMS.
Куди переходити
Для власника Moodle 5.0 є три практичні сценарії.
1. Перейти на Moodle 5.2 зараз. Це поточна stable-гілка; 10 серпня 2026 року вийшла 5.2.2. Загальна підтримка 5.2 триває до 19 квітня 2027 року, безпекова — до 4 жовтня 2027 року. Водночас 5.2 підвищила мінімальні серверні вимоги: потрібен PHP 8.3+, а для PostgreSQL — версія 16+. Офіційні release notes дозволяють оновлення до 5.2 з Moodle 4.4 або новішої, тому 5.0 формально входить у допустимий upgrade path. Але це не гарантує сумісності сторонніх плагінів і локальних доробок — їх потрібно перевіряти окремо. Перед вибором цього шляху варто звірити інфраструктуру з офіційними вимогами Moodle 5.2.
2. Дочекатися Moodle 5.3 LTS, але підготуватися до нього вже зараз. Реліз 5.3 LTS заплановано на 5 жовтня 2026 року, а безпекову підтримку — до 1 жовтня 2029 року. Для оновлення до 5.3 потрібна вихідна версія Moodle 4.5 або новіша, отже 5.0 відповідає мінімальному upgrade path. Вимоги до PHP і основних СУБД у поточних release notes 5.3 відповідають підвищенням, запровадженим у 5.2. Див. Moodle 5.3 release notes.
Проблема цього сценарію — календар: 5.3 заплановано на ту саму дату, коли закінчується security support 5.0. Якщо продакшн не буде мігровано одразу після релізу, виникне період роботи на непідтримуваній гілці. Тому «чекаємо LTS» має означати не паузу, а готове тестове середовище, перевірені плагіни, бекап і погоджене вікно міграції.
3. Перейти на Moodle 5.1 як тимчасовий компроміс. Безпекова підтримка 5.1 триває до 19 квітня 2027 року, але загальна підтримка завершується вже 5 жовтня 2026-го. Тому для більшості закладів це слабший довгостроковий варіант, ніж 5.2 або 5.3 LTS. Він може мати сенс лише тоді, коли конкретні плагіни, інтеграції чи серверні обмеження поки блокують новішу гілку.
| Версія | Статус на 11.08.2026 | Загальна підтримка до | Безпекова підтримка до |
|---|---|---|---|
| 4.5 LTS | security-only | 06.10.2025 | 04.10.2027 |
| 5.0 | security-only | 20.04.2026 | 05.10.2026 |
| 5.1 | stable | 05.10.2026 | 19.04.2027 |
| 5.2 | stable | 19.04.2027 | 04.10.2027 |
| 5.3 LTS | заплановано | 04.10.2027 | 01.10.2029 |
Детальніше критерії вибору варто винести в окреме порівняння: яку версію Moodle обрати у 2026 році.
Реалістичний графік на 8 тижнів
Нижче — не офіційний графік Moodle, а практичний план міграційного проєкту на ті 55 днів, що залишаються до завершення підтримки. Його потрібно адаптувати до навчального календаря закладу.
| Період | Що зробити | Результат |
|---|---|---|
| 11–17 серпня | Інвентаризувати точну версію Moodle, PHP, СУБД, вебсервер, плагіни, тему, способи автентифікації та інтеграції | Карта поточного середовища й список блокерів |
| 18–24 серпня | Вибрати ціль: 5.2 або підготовка до 5.3 LTS; перевірити серверні вимоги | Погоджений цільовий сценарій |
| 25–31 серпня | Зробити копію продакшну, повний бекап коду, moodledata і бази; перевірити відновлення |
Робоче тестове середовище і підтверджений rollback |
| 1–7 вересня | Перевірити сумісність плагінів, теми, SSO, API та інших інтеграцій | Список оновлень, замін і доробок |
| 8–14 вересня | Провести тестову міграцію | Фактична тривалість апгрейду і журнал помилок |
| 15–21 вересня | Перевірити вхід, курси, оцінки, завдання, пошту, cron, мобільний доступ | Протокол приймального тестування |
| 22–28 вересня | Виправити знайдені проблеми, повторити критичні тести, погодити production window | Рішення go/no-go |
| 29 вересня – 4 жовтня | Виконати продакшн-міграцію або завершити готовність до 5.3; залишити резерв часу на відкат | Платформа на підтримуваній гілці або максимально короткий контрольований перехід |
Офіційна інструкція Moodle радить спочатку тестувати оновлення на копії production-сайту, перед апгрейдом створювати резервні копії коду, moodledata та бази даних, перевіряти плагіни й переводити сайт у maintenance mode. Це базові контрольні точки, які не варто стискати навіть за дефіциту часу: MoodleDocs — Upgrading.
Якщо заплановане вікно припадає на сесію, масове зарахування, вступну кампанію або інший критичний період, першу спробу production-оновлення краще не ставити всередину такого навантаження. Спочатку репетиція на копії, потім — погоджене вікно з відкатом. Після репетиції варто зафіксувати не лише те, що «оновлення пройшло», а й фактичний час кожного етапу: створення фінального бекапу, переведення в maintenance mode, апгрейд коду й бази, оновлення плагінів, smoke-тести та можливий rollback. Саме ці виміряні значення дають реалістичне вікно простою для користувачів.
Якщо не встигаєте
Найгірший сценарій — визнати дедлайн лише 4 жовтня і почати з продакшну. Якщо повна міграція до 5 жовтня нереалістична, потрібно хоча б зменшити невизначеність.
По-перше, переконайтеся, що Moodle 5.0 оновлено до 5.0.9 або пізнішого доступного point-релізу своєї гілки на момент робіт. По-друге, створіть і перевірте повний резервний комплект. Moodle визначає три складові site backup: база даних, moodledata та код; див. MoodleDocs — Site backup.
По-третє, скоротіть зовнішню поверхню атаки там, де це можливо без порушення навчального процесу: обмежте непотрібний публічний доступ до адміністративних інтерфейсів, перегляньте мережеві правила, посильте журналювання та моніторинг. WAF може бути частиною тимчасового «virtual patching», але не замінює штатного оновлення — саме таку роль WAF описує OWASP у рекомендаціях щодо virtual patching.
І нарешті, зафіксуйте конкретну дату переходу. Формулювання «оновимося на зимових канікулах» прийнятне лише як погоджений план із відповідальним, тестовим середовищем і переліком тимчасових заходів. Інакше технічний борг просто переноситься без контролю.
FAQ
Чи можна залишитися на Moodle 5.0 після 5 жовтня 2026 року?
Технічно сайт не вимкнеться через сам факт завершення підтримки. Але гілка 5.0 перестане бути security-supported, тому для публічного production-середовища це означає роботу без нормального upstream-циклу безпекових виправлень. Moodle рекомендує переходити на підтримувані версії.
Скільки триває міграція Moodle?
Універсальної цифри немає. Тривалість залежить від розміру бази й moodledata, кількості та стану плагінів, кастомної теми, SSO, інтеграцій і готовності сервера. Точне production window доцільно визначати після тестової міграції на копії реального сайту, а не оцінювати «на око».
Чи втратимо ми курси та дані після оновлення?
Штатний процес оновлення Moodle розрахований на збереження даних і оновлення структури бази, але нульового ризику для конкретної інсталяції гарантувати не можна. Саме тому офіційна документація вимагає перед апгрейдом резервувати код, moodledata і базу та радить спочатку протестувати оновлення на копії production-сайту.
Якщо у закладу немає ресурсу самостійно провести інвентаризацію, перевірку сумісності й тестову міграцію, доцільно замовити аудит Moodle перед переходом. Практичний результат такого аудиту має бути конкретним: поточний стан платформи, блокери для 5.2/5.3, критичні плагіни й інтеграції, вимоги до сервера, сценарій переходу, вікно простою та план відкату. Це значно корисніше, ніж починати production-оновлення без репетиції за кілька днів до дедлайну.