Реалії міграції 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 і Microsoft. Під час анонса на 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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.