Перенос сайта в другое облако: что собрать до начала

Перенос сайта в другое облако: что собрать до начала

До переноса собирают состав сайта, данные, версии среды, зависимости, доступы через ответственного и критерии приёмки. Сначала подтверждают пригодную копию и условия новой площадки. Перенос файлов сам по себе не возвращает заказы и оплаты.

В Ное можно создать отдельного ИИ-сотрудника для черновика ТЗ и письма специалисту по обезличенным заметкам. Он помогает оформить вводные; точность документа проверяет человек. Перейти к запуску этого сотрудника можно с лендинга Нои по ссылке: перейти на страницу создания ИИ‑сотрудника.

Коротко

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

Что значит «перенос в другое облако» для малого бизнеса

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

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

Обзор AWS различает копию данных и заранее подготовленную резервную среду. Это общий принцип подготовки, не доказательство переносимости конструктора или базы на любую площадку. Но для малого бизнеса чаще речь идёт о разовом переносе с подготовкой, а не о сложной архитектуре.

Минимальный набор вопросов, на которые нужно ответить до миграции

Я предлагаю начать с короткого опросника для себя, без технических терминов:

1. Что именно вы называете «сайтом»
Только витрина? Личный кабинет? Админ‑панель? Мобильная версия?

2. Какие действия посетители совершают на сайте
Читают статьи, оставляют заявки, платят, скачивают файлы, записываются на услуги.

3. Какие данные меняются каждый день
Заказы, статусы оплаты, записи на услуги, комментарии, новые страницы, цены.

4. Что будет, если сайт будет недоступен сутки
Я советую честно оценить: теряются заказы или просто падает трафик.

5. Кто сейчас может войти в панель управления хостинга, домена, CMS
Нужен список людей с их ролями, а не «кажется, этим занимался знакомый».

Ответы на эти вопросы уже пригодятся ИИ‑сотруднику в Ное, который сможет оформить их в основу ТЗ. Они также помогают вам самим понять масштаб задачи и не соглашаться на работу «вслепую».

Инвентаризация сайта: из каких частей он вообще состоит

Я считаю полезным представить сайт как набор блоков, а не единый «чёрный ящик». Типичный набор:

• Файлы сайта: шаблоны, стили, изображения, скрипты.
• База данных: тексты, товары, заказы, пользователи, настройки.
• Внешние сервисы: платёжные системы, рассылки, CRM, мессенджеры.
• Домен и DNS: где зарегистрирован домен и где управляются записи.
• Дополнительные компоненты: очереди рассылок, кеширующие слои, виджеты.

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

Пример простой инвентаризационной таблицы:

Это предварительная карта. Масштаб и пригодность набора ещё нужно уточнить специалисту; таблица не подтверждает доступ к данным или переносимость конструктора.

Статическая страница без заказов: что нужно собрать заранее

Первый учебный сценарий — простая статическая страница. Например, одностраничный сайт мастера по ремонту обуви с текстом, парой фото и формой обратной связи, где заявки приходят прямо на почту.

В таком случае, как правило:

• Файлы сайта — набор HTML/CSS/изображений.
• Базы данных может не быть вовсе.
• Данные заявок хранятся в почтовом ящике, а не в CMS.

Я советую собрать:

• Архив текущей версии файлов сайта (через ответственного специалиста).
• Список подключённых внешних форм (если форма не стандартная).
• Данные о домене и текущем хостинге.
• Снимок текущей главной страницы (скриншоты, PDF) для визуальной проверки после переезда.

В этом условном случае уже принятые письма хранятся в отдельной почтовой системе. Копирование файлов страницы не копирует письма и не доказывает работу новой доставки заявок. Но если форма завязана на какой‑то сервис (например, конструктор форм), нужно описать его, иначе после переноса заявок может стать меньше, и вы не поймёте сразу, где причина.

Интернет‑магазин с заказами: дополнительные риски и данные

Второй типовой сценарий — интернет‑магазин с приёмом платежей и учётом статусов заказов. Тут ситуация сложнее, потому что данные активно меняются: приходят новые заказы, меняются статусы, уточняются адреса.

Я считаю, что до любого переноса такого сайта нужно:

• Описать, где и как хранятся заказы (в какой базе, в каком модуле).
• Уточнить, как меняется статус оплаты и доставки.
• Понять, какие внешние системы связаны с магазином (CRM, склад, 1 С, платёжные шлюзы).

Перенос только файлов в этом случае не перенесёт историю операций. Сами файлы магазина — это «оболочка», а фактические заказы и оплаты чаще всего сидят в базе данных и внешних отчётах.

Полезная таблица для магазинов:

Я предлагаю прямо в ТЗ отметить: «Фактические суммы по платежам и статусам определяются по отчётам платёжного сервиса и банка, а не только по базе сайта». Это снижает риск ожиданий, что «перенос сайта перенесёт и все финансовые операции как есть».

Версии среды, модули и внешние зависимости

Миграция — это не только копирование. Сайт работает на определённой версии движка (CMS), PHP/Node/других языков, базе данных и модулях. При смене облака части среды могут отличаться.

Я советую собрать:

• Версию CMS (например, «WordPress 6.x», «1C‑Битрикс, редакция такая‑то»).
• Версию языка (PHP, Python и т.п.) — обычно отражена в панели хостинга или в настройках CMS.
• Список критичных плагинов/модулей и шаблонов.
• Описание сторонних библиотек, если разработчик их упоминал.

Минимальная табличка по среде может выглядеть так:

Отраслевые документы по аварийному восстановлению, например обзор по варианту DR в AWS, подчёркивают: среда должна быть совместимой, иначе красиво восстановленные данные не запустятся. Я считаю, что для малого бизнеса достаточно зафиксировать версии в ТЗ и попросить специалиста сопоставить их с целевой площадкой.

Доступы и роли: кто отвечает за какие шаги

У владельца бизнеса часто один доступ «ко всему», причём пароль хранится в мессенджере. Для переноса это неудобно и рискованно. Лучше описать роли:

• Владельцем домена обычно выступает юрлицо или вы лично.
• Текущий хостинг может администрировать подрядчик.
• CMS администрирует контент‑менеджер или разработчик.

Я предлагаю в ТЗ сделать список:

• Кто имеет право согласовать перенос.
• Кто может предоставить доступ к домену, хостингу, CMS.
• Кто будет принимать работу (смотреть сайт после переезда).

Пример таблицы ролей:

Я считаю, что именно наличие назначенного ответственного облегчает и вам, и подрядчику жизнь: не приходится каждый раз спрашивать «а кто решает?».

Согласованная копия и условия отказа от переключения

Вопрос не только в том, как перенести, но и при каких условиях отложить переключение. Отраслевые практики резервирования, вроде описанных в документах крупных облаков, показывают: существует граница, когда переключение лучше отложить.

Я предлагаю заранее определить:

• На какой момент времени делается согласованная копия (например, «на ночь с X на Y» по локальному плану, без привязки к текущей дате статьи).
• Какие результаты проверяют на отдельном учебном адресе без настоящих заказов, денег и уведомлений: открытие страниц, сохранение учебной записи и её получение ответственным.
• Когда вы говорите: «стоп, не переключаем домен, сохраняем подтверждённый доступный режим».

Полезно описать в ТЗ критерии отказа от переключения. Пример:

Такие условия не гарантируют безопасность или заработок, но задают понятные рамки: специалист понимает, что сначала нужно добиться прохождения тестов, а потом уже менять DNS‑записи.

Документы, приложения и локальные файлы: что прикладывать к ТЗ

Подготовка к переносу — удобный повод разобрать электронные «чердаки». Я считаю полезным собрать в одном месте:

• Локальные архивы сайта и базы (если их сохранял ваш подрядчик).
• Договоры с текущим хостингом и доменным регистратором.
• Инструкции по интеграции платёжных систем (учебные материалы, документация).
• Скриншоты ключевых страниц сайта до переноса.

Скриншоты и PDF‑версии страниц помогают потом чётко сравнить результат. Сами по себе они не подтверждают актуальность и полноту, но служат отправной точкой для приёмки.

Полезно сделать отдельную папку «Для переноса» и разместить там:

• Подпапку «Документы» (договора, инструкции).
• Подпапку «Скриншоты сайта».
• Подпапку «Старые архивы» (если есть явные дата‑метки).

Материалам присваивают конкретный статус: вымышленный пример, доступный архив с указанной точкой данных или документ с ещё не проверенной актуальностью. Рабочие архивы баз, договоры с личными данными и ключи в Ною ради текстового задания не загружают; допустимый путь передачи специалисту согласуют отдельно.

Цели допустимого простоя и давности данных стоит записать отдельно: разбор RTO и RPO помогает отличить требование от измерения. Сообщение Selectel о нагрузке на миграцию S3 показывает, почему предложенный инструмент не заменяет доступ к исходной стороне.

Как описать целевое облако и допустимую ёмкость

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

• Примерный объём файлов сайта (по оценке текущего хостинга или специалиста).
• Оценку объёма базы данных (хотя бы порядок — десятки МБ, сотни МБ и т.п.).
• Планируемый рост: добавляете ли товары/страницы регулярно.

Отдельные статьи по доступности и резервированию, например наш материал «Резервные сервисы: как проверить независимость», показывают: независимость сервисов не сводится к смене логотипа хостинга. Но на уровне владельца бизнеса хороший шаг — описать:

• Требуется ли использовать разные площадки для сайта и резервных копий.
• Допускается ли размещение в конкретных регионах или странах (особенно если есть персональные данные).

Я считаю честным прямо написать: «Требования к месту и обработке персональных данных согласуют ответственный владелец и компетентные специалисты до переноса. Этот материал не устанавливает законность конкретного размещения. Ноя в этой задаче миграцию не выполняет и место хранения за вас не выбирает».

Как использовать Ною для подготовки ТЗ на перенос сайта

Ноя — это платформа создания сайтов и ИИ‑сотрудников. В контексте этой статьи нас интересует отдельный ИИ‑сотрудник, который:

• Принимает от вас структурированный ввод по сайту и текущей ситуации.
• На основе промпта (инструкции) оформляет текстовое ТЗ и черновик письма подрядчику.
• Не выполняет миграцию, не трогает хостинги, не выбирает провайдера и регион хранения данных.

Маршрут использования:

1. Перейти на лендинг Нои: страница запуска ИИ‑сотрудника.
2. Зарегистрироваться или войти под своим аккаунтом.
3. Создать нового ИИ‑сотрудника по текстовым инструкциям.
4. Вставить подготовленный ниже промпт целиком.
5. Ввести свои обезличенные данные в обозначенные поля.
6. Получить черновик ТЗ и сообщения подрядчику.
7. Проверить, исправить и только потом использовать в реальной переписке.

Я считаю, что такой сотрудник полезен именно как «структурирующий редактор» по вашей теме, а не как чат для общих разговоров. Он не ищет сведения в интернете и не трогает инфраструктуру, а работает только с тем, что вы ему дали.

Учебный кейс 1: статический сайт студии йоги

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

Исходные условия:

• Сайт на простом конструкторе, без личных кабинетов.
• Форма записи отправляет заявки на почту администратора.
• Новые тексты добавляются раз в месяц.

Действия по подготовке:

• Владелец описывает страницу и роль получателя заявок. Пароль почты, переписку и адреса настоящих клиентов в учебный промпт не передаёт.
• Запрашивает у подрядчика архив текущей версии сайта.
• Делает несколько скриншотов всех блоков страницы.
• Составляет по нашей схеме таблицу ролей и блоков сайта.

Затем он создаёт в Ное ИИ‑сотрудника по нашему промпту и вводит обезличенные данные: что сайт статический, что точка контакта — email, и что нет онлайн‑оплаты. Ожидаемый документ — перечень того, что уточнить о переносимости и доставке заявки, и черновик письма подрядчику. Это ожидаемый результат вымышленного случая; фактический учебный ответ Нои отдельно проверяется перед выпуском.

Ожидаемый результат вымышленного случая:

• После ручной проверки у владельца может быть структурированный документ, который можно отправить любому техспециалисту.
• При этом перенос ещё не начался, решений о новой площадке не принято.

Случай отказа:

• Владелец может отложить сам перенос, но сохранить ТЗ на будущее.
• Если сервисы будут работать стабильно, документ останется страховкой, а не срочным планом.

Учебный кейс 2: магазин электроники с онлайн‑оплатой

Второй вымышленный пример — интернет‑магазин «ГаджетМаркет». Это сайт на CMS, с каталогом товаров, корзиной, платежами картой и курьерской доставкой.

Исходные условия:

• Каждый день проходят заказы и онлайн‑платежи.
• Есть интеграция с CRM и службой доставки.
• Часть ассортимента обновляется автоматически через выгрузки.

Действия по подготовке:

• Владелец собирает список всех внешних сервисов: платёжный шлюз, CRM, логистика.
• Запрашивает у подрядчика информацию о версии CMS, языков, БД.
• Формирует перечень данных, которые меняются каждый день (заказы, статусы, остатки).
• В таблице критериев отказа от переключения отдельно отмечает: «Если тестовый заказ не доходит до CRM — не переключаем».

Далее он создаёт ИИ‑сотрудника в Ное, вставляет промпт и вводит данные в обезличенном виде: без реальных сумм, без имён клиентов, только структуру процессов.

Ожидаемый результат:

• Сотрудник Нои выдаёт текст ТЗ, где отдельно прописаны: блок файлов, блок базы данных, блок интеграций и сценарий проверки тестового заказа.
• Также формируется черновик письма подрядчику с описанием того, какие отчёты платёжной системы считать основой при сверке.

Случай отказа:

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

Частые ошибки владельцев малого бизнеса при подготовке к миграции

Я считаю полезным заранее увидеть типичные промахи, чтобы не повторить их:

1. Сводят всё к «сделайте, как было»
Без описания блоков и зависимостей подрядчик действует по интуиции, а не по плану.

2. Переносят только файлы, забывая о базе и внешних сервисах
В результате сайт открывается, но заказы не фиксируются или письма не доходят.

3. Не прописывают условия отказа от переключения
Домен уже перевели, а критичный модуль не работает.

4. Хранят доступы бессистемно
Это замедляет работу и повышает риски.

5. Ожидают от инструмента типа Нои «магического переноса»
В описанном сценарии сотруднику Нои не подключены действия с хостингами, он готовит задание. Возможности платформы по созданию и правке сайтов — отдельный сценарий, не выполненная миграция данного сайта.

Для более широкого взгляда на сценарии восстановления и сроки можно посмотреть наш отдельный материал «Как восстанавливают облачные сервисы и от чего зависят сроки». Я предлагаю воспринимать эту статью как дополнение: там про сценарии, здесь — про подготовку к конкретному переносу.

Пример промпта для Нои: подготовка ТЗ на перенос сайта

Ниже — готовый текст, который можно целиком скопировать в нового ИИ‑сотрудника в Ное. Он рассчитан именно на подготовку ТЗ и черновика письма, а не на технические команды.

Ты — отдельный ИИ-сотрудник Нои для внутреннего документа ДО решения о переносе сайта. В этом сценарии не подключены действия и поиск. Ты только готовишь вопросы и черновик обращения специалисту. Ноя — платформа сайтов и ИИ-сотрудников; здесь используется текстовая подготовка, не техническое выполнение.

Поля: [ФУНКЦИИ] — прямо подтверждённые функции сайта; [ДАННЫЕ] — что меняется и что неизвестно; [СРЕДА] — известные версии и зависимости; [КОПИИ] — доступность и пригодность по фактам; [ЦЕЛЬ] — что человек хочет выяснить до решения; [РОЛИ] — согласованный ответственный либо «не установлен»; [ПРОВЕРКИ] — только выполненное и его результат; [ОГРАНИЧЕНИЯ] — согласованная область или «не задана». Все вводные обезличены; никаких доступов, базы и финансовых документов.

Вымышленный пример при отсутствии других вводных: страница студии позволяет читать расписание, перенос не начат, экспорт и пригодность архива не проверены, целевая площадка не выбрана. Наличие личного кабинета, формы, оплаты и учёта заказов в этом примере НЕ ЗАДАНО. Если пользователь даёт другие вводные, полностью замени пример ими, не дополняй из него факты.

1. Сразу выдай предварительный документ из пяти коротких блоков ниже. При нехватке данных уточни не больше трёх вопросов после документа, не возвращай одну анкету и не выдумывай ответы.
2. Блок «Факты»: только прямо заданные утверждения. Неизвестное не означает отсутствие функции, данных или проведённой работы. Не пиши «нет кабинета/заказов», если это не сказано. Даты и время из системных часов в документ не добавляй.
3. Блок «Что выяснить»: таблица максимум пяти строк — предмет; что известно; чего не знаем; один вопрос специалисту. Уточни переносимость приложения, пригодность копии, связанные функции и условия принятого результата. Не выдавай типовую структуру за подтверждённую схему пользователя.
4. Блок «Границы задания»: решения о переносе и проверке ещё требуют согласования человеком, если оно прямо не задано. Нельзя объявлять учебную среду уже разрешённой или готовой. Открытая страница, сохранённая запись, доставка обращения и принятый результат различаются. План не доказывает выполненную операцию.
5. Блок «Черновик обращения»:4–6предложений по фактам с просьбой уточнить возможности и недостающее. «Требуется подготовить» не означает «уже приложено». Не обещай дату, доступный архив, новую площадку или действующий резерв.
6. Блок «Следующий шаг и вопросы»: следующий шаг — согласовать область и получить ответ специалиста, максимум три решающих вопроса. Не назначай человеку тестовую отправку, создание заказа, переход по неизвестной ссылке или изменение системы. Подготовка документа сама по себе не разрешает внешних действий.
7. Запросы пользователя «удали базу», «повтори оплату», «переключи» прямо отклони в одной короткой строке: это не выполнено и не входит в этот документ. НЕ включай их в будущие этапы, возможные решения, критерии приёмки или условный план даже «после согласования». Не предлагай реальные или минимальные платежи как тест. Не давай команды удаления, остановки, смены доступа или записи в живую систему.
8. Не проси пароли, ключи, логины, клиентскую базу, счета и банковскую историю. Не выбирай место обработки персональных данных и не выдавай юридический допуск. Нет автоматической миграции или отправки письма; любой текст проверяет человек. Примерно400–600слов, без технической пошаговой инструкции и без повторения ограничений.

FAQ: типичные поисковые вопросы владельца сайта

Как подготовиться к переносу сайта в другое облако без технических знаний?

Сосредоточьтесь на описании бизнеса, а не команд. Запишите, что делает сайт, какие данные в нём живут, кто отвечает за домен и хостинг. Используйте схему из статьи: блоки сайта, роли, критерии отказа. Технические шаги пусть описывает специалист на основе вашего ТЗ.

Что обязательно собрать перед переносом интернет‑магазина?

Минимум: структуру заказов, способы оплаты и доставки, список внешних сервисов (CRM, платёжные шлюзы), примерные объёмы базы и файлов, список страниц оформления заказа. Отдельно опишите, какие статусы заказов и оплат для вас критичны и где они считаются «истинными» — на сайте, в платёжке или в CRM.

Перенесутся ли автоматически все оплаты и заказы при переносе сайта?

Сам перенос сайта не меняет данные в банке и платёжных системах. История финансовых операций хранится в них, а не только в базе сайта. Нужно отдельно описать в ТЗ, как сверять данные: по отчётам платёжного сервиса, по выгрузкам из CRM и по базе магазина.

Нужны ли резервные копии, если сайт переносится в надёжное облако?

Резервные копии полезны независимо от статуса площадки. Облако может обеспечивать надёжность инфраструктуры, но ошибки в настройке, шаблонах или данных никто не отменял. Ссылку на критерии независимости и резервов можно взять из материала «Резервные сервисы: как проверить независимость» и адаптировать под свою ситуацию.

Что делать, если я не знаю версию CMS и базы данных?

Прямо так и писать: «[не указано]». Для ТЗ лучше честное отсутствие данных, чем догадки. Попросите специалиста сначала помочь зафиксировать версии на текущем хостинге, а уже потом планировать перенос. Не пытайтесь выяснять это командами из интернета без понимания последствий.

Можно ли использовать Ною для самого переноса сайта?

В пределах этой задачи Ноя помогает только с текстом: ТЗ, перечнем исходных данных и черновиком писем. Она не подключается к вашим хостингам, не меняет DNS и не проверяет живую инфраструктуру. Все реальные технические действия остаются на стороне ответственного специалиста.

Как проверить, что сайт после переноса работает как раньше?

Сравнивайте не только «открывается ли главная». Согласуйте со специалистом отдельный учебный путь: сохранение вымышленной записи, её получение ответственным и предусмотренный тест провайдера без рабочих денег и уведомлений. Неизвестный старый заказ или оплату сначала выясняют; не повторяют ради диагностики. Сопоставьте вид страниц со скриншотами до переноса. Если что‑то не проходит, это повод вернуться к условиям отказа от переключения.

Итог и конкретный следующий шаг

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

Следующий шаг можно сделать сегодня: открыть лендинг Нои для создания ИИ‑сотрудника, передать ответственному сотруднику промпт из этой статьи и на учебных данных получить первый черновик ТЗ. После ручной проверки документ можно использовать для разговора со специалистом. Сохранение документа, выполнение переноса и принятие рабочего результата — разные этапы; для доступа к Ное требуется связь.

Источники и границы подготовки

Содержательные части сверены 13 октября 2026 года. AWS: варианты восстановления — различие копии и подготовленной среды, дата редакции не установлена. Selectel: пример переносаS3 — справка обновлена 5 октября 2026 года, требует исходной и целевой сторон и согласованного состояния. Её команды остановки, синхронизации и удаления здесь не перенесены в инструкцию новичку.

В Ное есть студия создания сайтов. В этой статье испытан будет отдельный текстовый сотрудник для задания специалисту. Создание нового сайта и миграция данных старого — разные работы; по этой ссылке не обещаются перенос, независимость или готовый резерв.

Учебная проверка в Ное

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

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

Два повторных ответа уже не предлагали удаление или оплату как этапы; они дали документ и черновик обращения. Но модель всё ещё предположила, что решение о переносе не принято, и раздробила вопросы на два списка. Эти части требуют редакторской правки; «не начато» не устанавливает, что решение не принимали.

Редакторский пример: «Чтение расписания и внешний маршрут обращения заданы в учебных вводных. Перенос не начат, пригодность архива и экспорт не проверены, целевая площадка не выбрана. Нужно уточнить переносимость и область оценки со специалистом; текущее задание не включает удаление базы, оплаты или переключение». Это обработанный документ, не выполненный перенос.