Привет, Хабр! Предположим, у вас есть база в Airtable, где живет маркетинг, рекрутинг, операционка или любой другой ключевой рабочий процесс. После того как компания объявила о прекращении доступа к ним из России, нужно как можно быстрее и безболезненнее перенести данные, профили пользователей, систему доступов, вложения, сценарии автоматизации.
Меня зовут Артем Михеенко, я продакт-оунер MWS Tables. Ниже по шагам расскажу, как можно оперативно мигрировать из одной системы в другую и восстановить рабочие процессы. Поехали!
Что надо учесть перед миграцией
В Airtable таблички — верхушка айсберга. Сами данные — строки, колонки, даже связи — перенести относительно легко. Проблемы начинаются с процессами вокруг них, так как Airtable обычно глубоко встраивается в операционную деятельность.
На функциях используемого сервиса строится вся операционная работа с задачами: представления дают интерфейс для взаимодействия с ними, через формы проходит вся рабочая информация (заявки, брифы, кандидаты, обращения), права доступа синхронизированы со структурой организации, а сотрудники привыкли к сценариям автоматизации. К тому же вокруг таблиц копится большой объем информации, который может потеряться: вложения, комментарии, история изменений, зависимости.
Когда Airtable исчезает, ломается механика работы. Вывод из этого простой и неприятный: миграция не ограничена простым экспортом данных, а требует полного восстановления операционных процессов в новой.
Опаснее всего на старте миграции — это потеря времени
Начать нужно со скучной, но важной задачи: зафиксиро��ать все, что происходило в старой системе. Потому что через время вы уже не вспомните, где у вас критичный процесс, а где «красивый дашборд для души».
Начните с инвентаризации
Вам нужно понять, какие базы реально используются бизнесом, кто их владелец и сколько людей завязано. Для этого создайте табличку и заранее определите владельца таблицы.
Это удобно сделать в MWS Tables — сервисе для командной работы на основе таблиц. Он сочетает в себе основной функционал Airtable, свою workflow-платформу и функционал заметок. Можно собрать здесь четкий список сущностей — с названием, типом, ответственным, дедлайном и наглядном оповещением, что что-то идет не по плану:
Шаги каждого ответственного за переезд можно зафиксировать в Диаграмме Ганта:
Параллельно зафиксируйте интеграции, веб-хуки, автоматизации. Хорошо подойдет детальное описание: что является триггером, что система делает дальше и к кому обращаться за подробностями.
В дальнейшем автоматизации также можно перенести в MWS Tables — данные и процессы останутся в безопасности. Для этого нужно настроить необходимые триггеры (по наступлению условия, созданию записи или заполнению формы) и выбрать действия, которые после них выполняются — например, отправка rest-запроса или имейл.
Дальше — входящие потоки
Соберите список форм и источников: откуда приходят заявки или другие данные (сайт, бот, реклама, внутренняя заявка, ручной ввод, выгрузка из базы данных), куда они попадают и что происходит дальше. Удивительно, но многие узнают о существовании форм ровно в тот день, когда они перестали работать. Сейчас у вас редкий шанс узнать о них заранее.
И наконец, права доступа
Если вы не зафиксируете их, то есть риск оказаться в одной из двух ситуаций: «всем все видно» или «никто ничего не может». Самый простой тест на зрелость системы звучит так: можете ли вы ответить, кто имеет право удалять записи?
В результате подготовки к миграции вы должны уметь ответить на четыре вопроса:
Какие базы нельзя потерять?
Какие штуки «само работает» критичны?
Откуда приходят данные и что сломается, если поток остановится?
Кто что должен видеть и иметь право менять?
Теперь, наконец, можно приступать к настройке новой системы. Создавать основные таблицы, представления, автоматизации и ролевую модель:
Также заранее нужно определить сущности: кандидат, вакансия, кампания, сделка. Потом решите, что должно быть отдельными таблицами, а что — справочниками, чтобы не плодить параллельные вселенные с одинаковыми названиями. Если у вас есть события (созвоны, интервью, касания), им обычно нужна отдельная таблица, иначе вы быстро приходите к 14 колонкам «интервью_1 … интервью_14».
Решаем проблемы автоматического экспорта
Просто нажать кнопку «экспортировать» не выйдет. Почти всегда она делает просто снимок таблицы, но не передает поведение системы и контекст.
Отдельная история с вложениями. Вам нужно заранее понимать их количество, места хранения, критичность и существующие ссылки на них. Иначе вы получите кучу пустых карточек.
Второй важный момент — связанные таблицы. В Airtable связь выглядит простой, но после экспорта другие системы могут их не считать. Спасает только сопоставление полей по стабильным ключам. Если их нет — заведите External_ID и заполните. Хоть UUID’ами. После импорта обязательно проверьте, сколько образовалось висячих ссылок и дубликатов сущностей.
И финал: проверка качества. Сверяйте количество строк, уникальность ключей, базовые суммы/диапазоны по важным полям, целостность связей и несколько десятков карточек руками — включая файлы.
Когда данных много и нет желания делать копировать и вставлять их по 100500 раз, можно взять API в MWS Tables. Там и проверка корректности миграции есть:
На этапе запуска новой системы обычно выясняется, что простого переноса данных мало. Не пытайтесь перенести все представления «как было». Вам нужен минимально жизнеспособный продукт (MVP): несколько рабочих представлений для операционки («в работе», «просрочено», «мои») и одно аккуратное для руководства, чтобы у них не чесались руки «поправить одну ячейку». Формы поднимайте только ключевые — те, которые дают основной поток, — и сразу фиксируйте обязательные поля.
Автоматизации включайте последними и приоритизируйте их. В первую очередь восстанавливайте критичные уведомления и потоки, без которых все встанет.
Выбор варианта миграции
Идеально переехать практически невозможно — всегда приходится идти на компромиссы:
Если нужно максимально быстро перезапустить работу, то перенесите: минимальный набор данных и связей, поднимите пару критичных представлений, восстановите основные формы, включаете минимальные права и только жизненно важные уведомления. Не забудьте определить дату финального переноса всех функций, иначе все может зависнуть в таком состоянии надолго.
Если время есть, нужно делать пилот: вы берете процесс, доводите его до совершенства. Увы, этот вариант подходит тем, у кого железная дисциплина и кто готов выдерживать бесконечные разговоры о каждом статусе в новой системе
Переключение между системами
Самый опасный момент не экспорт или восстановление связей, а когда вы говорите коллегам: «С завтрашнего дня работаем в новом месте».
В этот момент нужен один человек, который возьмет на себя ответственность. Он должен зафиксировать час X, когда старая система переводится в режим архива, а новая становится единственным рабочим инструментом. Команда должна получить четкое сообщение по одному каналу: куда идти, с какого времени, куда писать, если что-то не работает.
Можно сделать заметку в MWS Tables, которая будет дополняться и актуализироваться в процессе миграции.
Проведите обучение по реальным задачам. Если есть возможность — устройте несколько ежедневных прогонов. Если нет — проводите контрольные сверки по критичным таблицам и выборочно проверяйте связи и файлы.
Что делать сразу после переезда
После переезда есть редкое окно — первые 3–7 дней, пока команда еще готова к изменениям. Потом все снова привыкнут. Не пытайтесь улучшить всё. Достаточно трех вещей:
Проверьте количество статусов и составьте справочник, чтобы в новой системе можно было быстро ориентироваться.
Создайте для повторяющихся вопросов и сообщений форму с понятным маршрутом и уведомлением.
Сделайте один дашборд для руководства и включите запрет «править базу руками».
Реальные кейсы миграции на MWS Tables
Миграции не бывают легкими и приятными, но их можно сделать быстрыми и предсказуемыми, если переносить процесс, а не отдельные поля и файлы. И вот какие есть примеры из моей практики:
Synergetic вместо ручного Excel-свода сделали связанную систему, добавили автоуведомления по важным событиям, уменьшили число рутинных операций и потерянных задач.
«Ашан» перевел на наш продукт процесс обработки обращений на «горячую линию», закрепив за ними ответственных и получив предсказуемое время ответов.
Успех определяет не список перенесенных файлов, а порядок действий: от инвентаризации старой до запуска работы в новой системе. А если хочется упростить для себя этот процесс — оставляйте заявку у нас на лендинге, и мои коллеги помогут с переносом, а заодно и предложат новые функции, которые улучшат ваши процессы и сделают их более эффективными.
