Как сменить маркетинговое агентство без потери данных

Соберите реестр активов

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

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

Определите данные и правовое основание

Компания отделяет свои бизнес-данные, лицензированные платформой данные и интеллектуальные материалы подрядчика. Право на выгрузку проверяется по договору и условиям сервиса. Персональные данные передаются только в необходимом объеме, безопасным способом и уполномоченным ролям. Желание сохранить все не отменяет минимизацию и сроки хранения.

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

Передайте логику, а не только файлы

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

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

Выдайте новые доступы по ролям

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

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

Передавайте работу волнами

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

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

Проверьте непрерывность

Контрольный сценарий проходит путь от объявления до CRM и отчета. Проверяются расход, события, формы, уведомления, статусы и доступ к исходным данным. Отдельно смотрят расписания, лимиты и автоматические правила, которые могут сработать позже. Зеленый экран сегодня не доказывает, что ночная загрузка или месячный отчет сохранены.

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

Закройте старый контур

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

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

Проведите контрольную передачу без подсказок

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

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

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