Снова переезд или с чего начать если закрыли очередную Asana. 5 важных аспектов миграции

Снова переезд или с чего начать если закрыли очередную Asana. 5 важных аспектов миграции

Привет,

На связи Сергей и я время от времени с философской отстранённостью взираю на взрыв популярности тех или иных систем на замену платформ, которые неожиданно ушли из той или иной юрисдикции. У меня есть как личный опыт переезда личных проектов, кстати в моем случае пришло переезжать с сервисов Яндекс, счет от которых за 3 месяца (1 год уже на самом деле) я так и не дождался. Так же, как и используя нашу RPA платформу puzzle-rpa.ru, в отдельных направлениях крупных корпораций или целым компаниям, которым приходится спешно переезжать с разнообразных платформ от почты до облачных ERP.

Давайте подумаем, что нужно сделать перед тем, как мы начнем переезд.

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

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

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

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

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

Мы кстати делали такие проекты на puzzle-rpa.ru. Здесь часто требуется привлечение команды, в которой есть аналитик чтобы описать и разобраться с функционалом будущих процессов, здесь вы можете обратиться к нашим коллегам из mkskom.ru которые за 20 лет собаку съели на миграции данных с миллионами сущностей

автор

Ну и если у нас нет готового мигратора старая-новая система и нет API, по которому можно было бы забрать данные то перед нами встает вопрос будем ли мы делать все руками или попробуем автоматизировать. Для этих целей идеально подходит RPA, вы можете за пару часов настроить робота, который будет создавать и переносить данные между системами используя интерфейсы старой и новой системы, валидируя данные и подготовить отчет по итогам. Конечно, в случае с RPA всегда встает вопрос стоимости лицензий, но вы, например можете обратиться к интеграторам, которые используют RPA платформы без лицензирования роботов или приобрести среду разработки, например у нас в puzzle-rpa и сделать все самостоятельно. Конечно, всегда есть возможность использования open source, но, как и в случае с разработкой своими руками нужны будут специалисты, которые могут быстро вникнуть в систему и которые обладают специализированным опытом для того, чтобы данные не были потеряны.

Вывод и итоговые мысли

Вообще интересно как мы видим мир. Находясь внутри бесконечных проектов замены иностранных вендоров на российских невольно возникает ощущение, что все кто хотел давно переехал и мигрировал. Уж за 2 то с лишним года можно было, но оказывается нет. Постоянно появляются новые задачи с учетом ухода старых систем, да и по беглому опросу оказалось, что есть большое количество компаний от малых до больших кто по-прежнему сидит на иностранном облачном софте и никуда не собирается. Хотя скорее это контртренд и все потихоньку начинают понимать уязвимость SaaS и тренд постепенно двигается назад к on-premise приложениям и решениям, которые нельзя выключить одним кликом по политическим или иным причинами.

Удачи вам с переездом!

22
Начать дискуссию