Есть вероятность, что они полностью переехали в облако. М.б. также вариант с поставкой evaluation после заполнения листа опросника от компании. А в чем проблема написать им в суппорт и спросить?

Всем, кто использует серверный Confluence. В 2024 он всё. То есть, пользоваться им можно, но продаваться лицензии на него скоро не будут, как и выпускаться обновления. Направление полностью будет отдано Cloud.
https://www.atlassian.com/migration/key-offering-changes?tab=server-key-changes#key-changes

😱 мы на Клауде и это боль)

Так как раз не о чем беспокоится

Клауд жив будет и даже процветать

Как и новый редактор)

Сегодня только с саппортом ругался, а то они в пятницу учудили и вырубили Legacy Editor, сегодня опять включили.

Ух ты, а так еще один человек на клауде, приятно видеть.

Я про то, что всех на эту боль хотят пересадить. Мы сами, вероятно, будем переезжать с атлассиана - медленный, пихают кучу ненужных никому фич, а то, что просят годами - не делают, или нужное убирают. В общем, когда-то боль пересилит удобство и популярность

Это да, но есть надежда, что может много допилят. А так на них надо просто нажимать по всяким рычагам. Только к сожалению угрозы судами и штрафами на них действуют. Там была проблема, вроде летом или весной, что перестали срабатывать ссылки в оглавлении. Причем это было, как в старом, так и в новом редакторах. Ну они багу завели и заявили мне, что вот мол, голоса соберутся тогда и поправим. Ну тогда я им всю диспозицию объяснил быстро, что парни, мы заплатили вам очень много за лицензии и базовая функциональность сломана, если не хотите судебных тяжб и требования штрафами, то лучше взять в работу, а не рассказывать нам о том, как вы будете работать с командами разработки. Причем написал всем и руководству и другим людям там, через месяц выкатили исправление, и это еще быстро. Сегодня также сказал, чтобы вернули старый редактор и не выпендривались.

суровый ты)

Это могут понять, только клиенты Atlassian Cloud)

Мы так сурово не подходили к вопросу, но я ставила те самые голоса примерно в десятилетний юбилей одной таски (
Ей уже скоро 11, совсем большая...

Эти голоса просто пшик)

Кстати относительно опыта исследования и миграции на различные платформы сделал @AbashkinIvan

История про базу знаний внутри компании.

Около 5 лет я выстраивал службу поддержки клиентов. Сфера технически сложная. Много нюансов в инженерной части. Небольшие вариации обстановки у Клиента в корне могут поменять процесс работы над его проблемой. Поэтому специалистам поддержки очень много информации необходимо держать в голове, чтобы в онлайн-режиме подстраивать диалог, направляя его в нужное русло.
Продукты, которые мы поддерживали, так же технически сложные. Необходимо помнить как именно работают эти штуки их ттх и нюансы взаимодействия с внешним миром.

В компании была развернута MediaWiki, но ею никто не пользовался - слишком муторно.
В то время я уже использовал Evernote для ведения собственной базы знаний по работе. Предложил коллегам воспользоваться моими наработками. Получил от них положительные отзывы, некоторые даже начали писать туда свои статьи.
Потихоньку база знаний в Evernote наполнялась и был реально заметен эффект от её существования.

Но я всё равно был не доволен. В коллективе знания продолжали теряться. Люди из раза в раз ходили по одним и тем же граблям.

Я обратился к подходу Knowledge Centered Support (KCS). Его основная идея состоит в том, чтобы сотрудник после решения проблемы клиента, оставлял в системе ссылку на статью, по которой решается эта проблема. Если такой статьи нет, то сотрудник обязан её написать, законспектировав каким именно способом он решил проблему.

Параллельно внутренней базе знаний я взялся за организацию внешней: портала поддержки, где пользователи могли сами найти ответы.
Статьи в общем доступе должны быть качественные. Проработанные, понятные, красивые. Совсем не такие, какие мы позволяли себе вести во внутренней БЗ.

Нужно было выстраивать процесс по накоплению знаний. Когда сначала человек делает себе заметку. Потом превращает заметку в статью для коллег во внутренней БЗ. А потом выбираются наиболее популярные статьи и прорабатываются до уровня возможности выложить их на публику.

Чтобы всё это работало, нужно иметь несколько разных инструментов:
- Система, в которой определяется востребованность статей. (У нас это было специализированное ПО, в котором сотрудники общались с клиентами. По количеству и типу вопросов можно было оценить, что наиболее востребовано клиентами)
- Система, позволяющая быстро создавать личные заметки. (Здесь у нас до поры, до времени отлично справлялся Evernote)
- Система, позволяющая разворачивать личные заметки в более подробные статьи (Тут Evernote то же справлялся, но уже хуже. Для понимания на каком этапе находится конкретная заметка, нужно было учить сотрудников работе с определенной системой тегов, а они тяжело в это въезжали. Так же напрягало, что было не отследить кто и когда внёс какие изменения. Тяжело было откатить версию статьи назад).
- Процесс работы над превращением внутренних статей в статьи для внешних пользователей.  (Здесь нам помогали технические писатели)
- Система, в которой выполнялась публикация статей для внешних пользователей. Она должна была хорошо индексироваться поисковиками и подсказывать клиентам о существовании статьи по их вопросу.
(В качестве системы для внешних пользователей мы сначала использовали Copiny, а потом переехали на UserEcho)

Зоопарк изрядный. Всё это работало довольно хреново. Тяжело было за всем следить.

Вскоре всплыл ещё один момент - необходимо было отказаться от Evernote. Это был прекрасный инструмент. В нём было легко искать информацию и легко её создавать.
Но дело в том, что политика компании запрещала привязываться к облачным сервисам (в целях безопасности и для того, чтобы не зависеть от работоспособности сторонней инфраструктуры).
Работа с Evernote у нас была по собственной инициативе и как-бы из под полы. Неофициально.
А для Knowledge Centered Support мне необходимо было создать официальные регламенты, которые необходимо было бы соблюдать всем сотрудникам.

На замену Evernote я рассматривал всяческие Wiki-движки, корпоративные порталы по накоплению знаний. Сервисы документирования:
После отсева остались вот такие варианты:
- Atlassian Confluence
- Xwiki
- Bookstack
- И вариант, который выиграл.

Atlassian Confluence
Это был топ жир. Система специально предназначенная, чтобы большие компании вели там свою документацию. Отточенная, отлаженная, с большим сообществом. Дорогая. Связывающая руки.
В тот момент мы не могли себе позволить потратить такие деньги, которые требовались за 20-50 лицензий на Конфлюенс.

Xwiki
Корпоративная Open-Source замена Конфлюенсу.
Тяжелая, глючная, сложная. Бесплатная.
Мы в неё копнули, но вынуждены были остановится из-за непреодолимых приступов тошноты.

Bookstack
Прекрасный Open-Source аналог и Confluence и XWiki. Красивая, простая, удобная система с контролем доступа. Там даже можно нативно подключить draw.io для рисования блоксхем и совместного их редактирования.
Погоняли её, но не взлетела.
Два нюанса:
- По какой-то причине движок разметки ломал оглавление на длинных документах
- На тот момент было всего два уровня вложенности каталогов и народ не понимал как распихать текущие проекты на такую бедную структуру.

Вариант который выиграл
Это текстовые файлики. Вернулись обратно к истокам.
В тот момент у нас развернули корпоративный портал - Bitrix24. Там можно было создавать аналог яндекс.диска, но по проектам.
Мы делали общий шаренный диск, куда складывали файлы в удобном нам формате.
Там же можно было отследить историю изменений.
Битрикс это не только корпоративный портал, но и система управления задачами. Поэтому жизненный цикл статьи мы выстараивали через задачи.
Правда тут речь уже не шла о "выращивании" статей из зародышей. Тут уже были запросы "сверху" на написание той или иной статьи исходя из потребностей.
Поиск по базе файликов выполнялся с помощью DocFetcher.

Но Битрикс система глючная. То и дело у кого-то случался конфликт синхронизаций. Процесс работы со статьями вызывал споры из-за разных форматов. Написание статей по запросам попахивало бюрократией и не позволяло статьям появляться органичным образом.
База со статьями разросталась и вместе с ней рос её размер. Это создавало проблемы на компьютерах с заканчивающимся жестким диском.
DocFetcher был костылём, который люди тяжело воспринимали.
Ну и весь этот подход не очень пересекался с идеей KCS.

А я размышлял. Людям явно зашла работа с простыми файликами. И тут мы в отдел разработки установили GitLab.
Вот  оно!
Репозиторий со статьями в Markdown-формате. Гит как контроль версий. Поиск по всем репозиториям!  Ишью! Теги!

Сейчас мы перевели всю базу внутренних и внешних статей в Git-репозитории.
Новые статьи пишем сразу туда. Чуть позже накатим на них какой-нибудь генератор статических сайтов и откажемся от стороннего сервиса UserEcho в качестве хостинга статей для клиентов.

Параллельно прорабатываем вопрос по работе с документацией как с кодом. Идея в том, чтобы техпис работал с текстовым файлом и языком разметки и не заморачивался по поводу форматирования. Форматирование будет выполнять машина по заранее заданному шаблону.
В общем, всё то же, что и в абзаце выше, только более богатый язык разметки. Вместо markdown - asciidoc

Ведение статей и документации в простом языке разметки в git развязало нам руки, для того чтобы полноценно внедрить KCS.

О, меня перепощивают! Спасибо! =)

А чем md хуже asciidoc?

База разметки есть и в md, + двиг типа грав на сервере, и yaml можно вообще свои теги для разметки создать, если php не пугает.

Спрашиваю почему - asciidoc не знаю, но на первый взгляд как то он "устарел", ну т.е. не дружит с модными новыми технологиями, а то что там больше всего, зачем мне, если я с пол щелчка его не смогу заводить на другом софте (представлении, парсинг в базу к примеру, без регулярок сложных)

Это к чему вопрос был? Или это как рассуждение?