Уходите из Confluence? Вот что делать с тысячами страниц документации

С 30 марта 2026 года Atlassian прекратил продажу новых лицензий Confluence Data Center. Полное завершение поддержки серверных версий запланировано на март 2029 года. Для российских компаний, которые годами держали Confluence на собственных серверах, это означает одно: пора переходить.

Статей о том, куда переходить — десятки. Но почти никто не пишет о том, что происходит с документацией в момент перехода. А именно там — самая болезненная часть миграции.

Почему перенос документации — это не просто «экспортировать и импортировать»

Технически перенести страницы из Confluence в другой сервис несложно. Большинство российских альтернатив поддерживают импорт. Проблема не в переносе — в содержании.

За годы работы в Confluence накапливаются сотни, а у крупных компаний — тысячи страниц. И значительная часть из них:

• Описывает интерфейсы, которые давно изменились

• Написана под процессы, которых уже нет

• Создавалась «на потом» и никогда не использовалась

• Хранит скриншоты трёхлетней давности

Если перенести это в новую систему без разбора — вы получите то же кладбище, только в новом интерфейсе. Сотрудники быстро поймут, что документации доверять нельзя, и перестанут ею пользоваться.

Миграция — это возможность начать с чистого листа. Но только если подойти к ней системно.

Шаг 1. Проведите аудит до переноса

Прежде чем что-то переносить, нужно понять, что вообще есть и в каком состоянии.

Выгрузите список всех страниц пространства. В Confluence это делается через Space Settings → Content. Для каждой страницы вам важны три параметра:

Дата последнего обновления. Страница, которую не обновляли больше двух лет — кандидат на удаление или полную переработку. Исключение: справочные материалы, которые по природе не меняются (глоссарии, описание архитектуры).

Количество просмотров. Confluence хранит статистику. Страница с нулевыми просмотрами за последние 6 месяцев, скорее всего, никому не нужна.

Владелец. Кто последний редактировал. Если этот человек уже не работает в компании — содержание нужно перепроверять.

Распределите всё по трём категориям:

• Переносить как есть — актуально, используется, не требует изменений

• Переработать — нужна, но устарела

• Удалить — не используется или дублирует другие страницы

Большинство компаний обнаруживают, что 40–60% документации попадает в категорию «удалить». Это нормально.

Шаг 2. Расставьте приоритеты по критичности

Переработать всё за один раз невозможно. Нужна очерёдность.

Критичная документация — та, без которой процессы ломаются: инструкции по онбордингу, доступы к системам, порядок обработки заявок, финансовые процессы. Эти страницы переносятся и актуализируются в первую очередь, до завершения миграции.

Важная документация — регламенты, описания процессов, технические руководства. Их переносят во вторую очередь, в течение первых двух недель после перехода.

Архивная документация — всё остальное. Можно перенести отдельным пространством с пометкой «архив» и вернуться к ней позже — или не возвращаться вообще.

Шаг 3. Решите, что переносить, а что пересоздавать

Это ключевое решение, которое определяет качество итоговой документации.

Переносить имеет смысл, если страница актуальна и не содержит скриншотов устаревших интерфейсов. Текстовые регламенты, политики, глоссарии — хорошие кандидаты на перенос с минимальными правками.

Пересоздавать нужно всё, что описывает работу в конкретных системах: как войти в CRM, как выставить счёт, как создать задачу. Эти инструкции устаревают быстрее всего, и редактировать старый текст со старыми скриншотами часто дольше, чем записать процесс заново.

Пересоздание кажется дорогим, пока не попробуешь сделать это с правильным инструментом. Если инструмент автоматически фиксирует действия и делает скриншоты — одна инструкция занимает 5–10 минут, а не час редактирования.

Шаг 4. Выберите новую платформу до начала переноса контента

Это важно: не начинайте актуализировать документацию в Confluence, а потом переносить. Определитесь с платформой сначала.

На российском рынке сейчас несколько направлений:

Wiki-системы (Teamly, Yonote, Яндекс Wiki) — ближайшие функциональные аналоги Confluence. Подходят, если вам нужно хранить большие объёмы разнородного контента с вложенной структурой.

Платформы для пошаговых инструкций (Steppo) — оптимальны, если основная боль — процессные инструкции и онбординг. Позволяют создавать инструкции автоматически, без ручного написания.

Комбинированный подход — для большинства компаний оптимален: вики-система для политик и регламентов + специализированный инструмент для пошаговых инструкций по работе в системах.

Шаг 5. Перенесите структуру, затем контент

Не переносите контент без структуры — получите свалку.

Сначала воссоздайте иерархию пространств и разделов в новой системе. Не копируйте структуру Confluence один в один — используйте аудит из шага 1, чтобы убрать лишние уровни вложенности.

Хорошая структура для большинства компаний:

• Начало работы (онбординг, доступы, первые шаги)

• Процессы по отделам

• Инструменты и системы

• Политики и регламенты

• Архив

После того как структура готова — переносите контент категориями: сначала критичное, потом важное.

Шаг 6. Назначьте ответственных за актуализацию

Самая частая ошибка при миграции — думать, что проблема решена после переноса файлов.

Каждый раздел документации должен получить владельца — человека, который отвечает за актуальность. Не за написание всего контента, а за то, чтобы раздел не устаревал незаметно.

Зафиксируйте это формально: список разделов и ответственных, с которым согласны сами ответственные. Устная договорённость работает до первого дедлайна.

Шаг 7. Сообщите команде о переходе

Документация существует только если ею пользуются. Люди не будут искать инструкции в новом месте, если не знают, что они там есть.

Минимальный план коммуникации:

• Объявление о дате перехода и новом месте хранения документации

• Короткая инструкция «как найти нужное» в новой системе

• Ответ на вопрос «что делать, если не нашёл»: к кому обращаться, как запросить создание новой инструкции

Первые две недели после перехода — самые важные. В этот период при каждом вопросе в чате давайте ссылку на инструкцию, а не отвечайте текстом. Это быстрее формирует привычку.

Типичные ошибки при миграции документации

Переносить всё без аудита. Через полгода окажется, что 70% перенесённого контента никто не читает. Лучше перенести меньше, но актуальное.

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

Не назначить ответственных. Документация без владельцев умирает за 3–6 месяцев — проверено на сотнях компаний.

Выбирать платформу под старую структуру. Новый инструмент — повод пересмотреть как устроена документация, а не просто сменить оболочку.

Забыть про внешнюю документацию. Если у вас есть клиентские инструкции или публичные базы знаний в Confluence — их перенос требует отдельного плана и уведомления пользователей.

Сколько времени занимает миграция

Зависит от объёма. Ориентиры из практики:

• До 100 страниц: 1–2 недели при наличии одного ответственного

• 100–500 страниц: 1–2 месяца с командой из 3–5 человек

• Больше 500 страниц: квартал и выше, нужен отдельный проект с владельцем

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

Miграция из Confluence — это не катастрофа, если относиться к ней как к плановому проекту, а не к аварийному переезду. Большинство компаний, которые подходят к этому системно, в итоге получают документацию лучше, чем была: меньше по объёму, актуальнее и понятнее.