Реалии миграции SharePoint в облако
Постоянно возникающие вопросы о миграции являются очень неплохим измерителем интереса к платформе SharePoint. В прошлом все изменения представляли собой апгрейды на новые онпремисные версии, поэтому грядущий переход в облака станет не столь простым, как предыдущие обновления.
Выраженность проблемы для заказчиков с длительным опытом эксплуатации SharePoint зависит от интенсивности использования, степени кастомизации платформы и приверженности решениям сторонних разработчиков. Данные факторы могут затормозить или даже сорвать миграцию.
Одна из крупнейших миграций SharePoint в SharePoint Online была реализована Microsoft для внутренних нужд, при этом все планы и решения готовились задолго до начала процесса. Microsoft IT (MSIT) разработали детальную методологию, определили контент каждой фермы, групп и отдельных сайтов и проработали понимание дальнейшего применения. Рабочая группа классифицировала, расставила приоритеты и наметила место в миграции для каждого сайта, базируясь на данных о рабочей нагрузке, бизнес-результате и сложности архитектуры.
Консультант и эксперт по миграции Доринда Рейс из американской компании Gtconsult отмечает наличие нескольких подходов. Методика «Lift and Shift» — подход, когда вы сохраняете всю структуру SharePoint и просто мигрируете в новую среду, чаще всего Office 365. Однако, как вариант, такая методика применима и при апгрейде с SP2010 до SP2013.
Намного чаще, по словам эксперта, применяется подход «Map and Restructure». В таком случае меняется структура, реорганизуется контент и перераспределяется в более удобные локации. Встречаются случаи, когда среда SharePoint становится хранилищем файлов, где необходимо все подчистить и сделать применимым для пользователя. Большинство миграций требуют реструктуризации в связи с развитием организации и появлением новых идей и планов создания новой среды.
Почему же миграция в Office 365 идет так медленно? Именно эта проблема является опасением №1 для крупных организаций. Есть множество причин. Microsoft использует множество методов для защиты пользователей и целостности серверных ферм, включая балансировку нагрузки и сканирование на вирусы. Все они могут повлиять на скорость самого процесса миграции.
Кроме того, работоспособность SharePoint Online ограничена не только шириной канала и скоростью передачи данных. Многопользовательская среда, несмотря на раздельность и безопасность данных, имеет ограничения активностей, способных повлиять на других клиентов, целью которых является сохранения качества обслуживания всех пользователей.
Для помощи в решении этой проблемы Microsoft разработала API для миграции, который обеспечивает увеличение пропускной способности между SharePoint Online и Azure. Во время анонса на Ignite сообществу были представлены обзоры производителя с описанием продукта. К сожалению, они не дали ясной картины возможностей и ограничений нового Migration API.
По сообщениям западных экспертов, новинка действительно позволяет быстрее мигрировать в Office 365, но предназначена преимущественно для контента. Перенос списков, библиотек и сайтов требует ручного создания всех элементов и создания пакетов миграции для правильной маршрутизации к местам назначения.
Бенджамин Ниаулин, эксперт по миграции и Office 365 MVP, отметил, что нет ничего приятнее чем смотреть на Гигабайты информации, мигрирующей в Office 365, после полной настройки и подготовки процесса. Однако будет ошибкой считать ее простым и легким процессом, особенно если требуется реорганизовать и реструктурировать SharePoint. По мнению эксперта новый API ориентирован на партнеров Microsoft, которые будут строить решения для миграции. Именно партнеры предоставят конечным клиентам необходимую детализацию и гибкость в сочетании с высокой скоростью, требуемой для переноса значительных массивов данных в Office 365.
Как отмечает Рейс, даже использование инструментария сторонних вендоров с новым API оставляет необходимость ручного труда для настройки процесса миграции. По мнению специалистов, миграционный API лучше подходит для простого переноса данных по методике «Lift and Shift». Подход «Map and Restructure» потребует пакетирования каждого элемента данных с выполнением определенных требований, например, указанием специфического URL или GUID экспортируемого объекта, пути, отключения компрессии данных.
Использование процессов Azure позволяет увеличить скорость, но здесь вы теряете контроль над базовыми параметрами миграции. Безопасность, метаданные и версионность ограничены. Когда вы создаете пакеты для каждого из переносимых блоков данных, создается потенциальная угроза потери одной из частей. Поэтому для комплексной миграции с реструктуризацией, когда дизайн и конфигурация также важны, как перенос контента, традиционные подходы, включая разработку скриптов и специализированных пакетов, остаются предпочтительными вариантами. Применение миграционного API в таких кейсах может создать больше проблем, чем выгод. Именно для упрощения комплексной миграции и создаются решения сторонних разработчиков.
Может ли новый API использоваться без решений сторонних разработчиков? Конечно же, да. Однако специализированные решения дают пользователю больше контроля и снижают риски миграции. В следующей статье постараюсь сделать обзор и сравнение таких решений.
По материалам www.cmswire.com
