La Миграция между клиенти на Microsoft 365 Миграцията от наемател на наемател е станала нещо обичайно при сливания, придобивания, отделяния и вътрешни реорганизации. Вече не говорим само за преместване на пощенски кутии: говорим за мигриране на самоличности, имейли, файлове, екипи, устройства, автоматизации и политики за сигурност, без това да нарушава бизнеса.
Ако работите в ИТ и сте чували поговорката „Няма как да се провали и всички просто трябва да дойдат в понеделник, сякаш нищо не се е случило“, това ръководство е за вас. Тук ще видите Как работи миграцията между клиенти на Microsoft 365?Какви инструменти разполагате (нативни и на трети страни), какви ограничения налага платформата и как може всичко да бъде организирано, за да се гарантира, че потребителите, сигурността и бизнесът са обхванати?
Какво представлява мигрирането на клиент на Microsoft 365 и кога е необходимо?
а Миграция от клиент на клиент на Microsoft 365 Това е процесът на преместване на потребители, пощенски кутии, OneDrive, SharePoint, Teams, домейни, устройства и настройки за сигурност от един клиент на Microsoft 365 към друг, като се опитва да се сведе до минимум въздействието върху ежедневните операции.
На практика тази ситуация възниква, когато Промените в бизнеса съвпадат с вече зрели облачни средиКомпаниите използват Microsoft 365 от години, създавайки автоматизации, интранет мрежи, екипи в Teams, политики за съхранение и управлявани устройства с Intune, и изведнъж се налага да „преместят всичко това“ към друг клиент.
Типични сценарии: защо една организация решава да премести наематели
Най-честите причини за Миграция между клиенти на Microsoft 365 Те са склонни да се повтарят и напълно обуславят обхвата на проекта.
В сценарий на сливане или придобиванеДве компании вече използват Microsoft 365, всяка със собствен клиент, а ръководството иска всички евентуално да си сътрудничат в една среда: един и същ имейл домейн, едни и същи Teams, един и същ модел на сигурност, едни и същи политики за управление.
В един отделяне или отделянеИли се случва обратното: част от бизнеса става независима и се нуждае от собствен наемател, с нов домейн, нови лицензи и само част от потребителите и данните. Предизвикателството тук обикновено е да се определи какво ще вземе новата организация, какво ще остане при първоначалния наемател и какво трябва да се пресъздаде от нулата.
Също често срещани са вътрешни реорганизации и исторически консолидацииГрупи, които са натрупали наематели по държава, дъщерно дружество или партньор, сега искат да опростят процеса. Обединяването на множество наематели помага за намаляване на разходите, рисковете, свързани с различни конфигурации, и главоболията, свързани с поддръжката.
Накрая, има сценарии на промяна на корпоративния домейн или ребрандиранеИмето на фирмата се променя, имейл адресите се променят и се използва възможността за препроектиране на самоличности (UPN), домейни и в много случаи за почистване на натрупани години сайтове и оборудване.
Методология и управление: без проект, миграцията не може да бъде устойчива
Миграция от този тип не е просто „изпълнение на скриптове“: тя изисква методология, управление и много фина координация между ИТ, сигурност, бизнес и често правни/съответстващи изисквания. Начинът, по който е организиран проектът, е по-важен от конкретния използван инструмент.
Най-здравословното нещо е да работиш за миграционни вълниПредставителен пилотен проект (реални потребители, реални бизнес процеси), няколко прогресивни вълни за усъвършенстване и окончателно внедряване на контролиран домейн. Всяка вълна трябва да включва комуникационен план, бизнес изисквания, тестване на потребителското изживяване (UAT) и ясни показатели.
Успоредно с това е препоръчително да се създаде комитет за наблюдение Този комитет включва представители на ИТ, сигурност, бизнес и, където е приложимо, правни/съответстващи отдели. Целта му е да преглежда рисковете, зависимостите, решенията за запазване на данни, обработката на чувствителна информация, критични устройства и други.
Ключов момент за правителството е да изясни, че миграцията не е „просто системен проблем“. Решения като например какво да се мигрира, какво да се архивира и какво да се остави да умре Това са бизнес решения, а не технически. Ако това не е правилно съгласувано от самото начало, ще последват изненади.
Първоначална оценка: инвентаризация, зависимости и ограничения на платформата
Преди да се докоснем до каквото и да било, трябва да отговорим, с данни, на три въпроса: Какво има там, какво може да се премести и какво блокира миграциятаТова е фазата на оценка или откриване и обикновено тя определя качеството на последващия план.
В областта на самоличността и имейла е важно да се идентифицира потребители, групи, домейни, хибридни взаимоотношения, политики за условен достъп, многофакторна автентичност (MFA) и лицензиУспоредно с това, пощенските кутии на Exchange Online трябва да бъдат инвентаризирани (размер, архивиране, запазване, квоти, правни спирания, използване на криптиране с клиентски ключ и др.).
В сътрудничеството и архивите фокусът е върху OneDrive, SharePoint и TeamsВ OneDrive: размер на потребител, брой елементи (практическото ограничение е 1 милион на акаунт), вътрешни/външни споделени връзки, акаунти с правни задържания и акаунти, надвишаващи ограничението от 5 TB, наложено от Microsoft. В SharePoint: типове сайтове (модерен, класически, комуникационен, свързан с групи и Teams), размер на колекцията (не повече от 5 TB или 1 милион елемента на сайт в оригинални сценарии), наследени работни потоци (2010/2013), Power Apps и свързани автоматизации.
В Teams е полезно да се изброят екипи, канали, раздели, интегрирани приложения, записи на срещи (стрийминг в SharePoint) и зависимости с ключови процесиЧесто срещано е много отдели да са създали свои собствени „мини ERP“, поддържани от Teams, SharePoint и Power Platform.
Накрая, трябва да погледнем устройства и IntuneКолко екипа се управляват, какви платформи (Windows, macOS, мобилни устройства), какви профили за съответствие съществуват, дали се използва Windows Autopilot, какви приложения се разполагат от Intune и какви BYOD стратегии са налице. Всичко това влияе върху начина, по който ще се подходи към повторното записване в целевия клиент.
Съвместно съществуване: самоличност, календари и имейл по време на мигриране
За да предотвратите спирането на бизнеса, трябва да проектирате съвместно съществуване между наематели това обхваща най-малко самоличност, наличност в календара (свободен/зает) и маршрутизиране на поща между източника и местоназначението.
По отношение на самоличността, Microsoft Entra ID предлага достъп между наематели и синхронизация между наемателиС тези възможности можете да установите доверителни взаимоотношения между наемателите, да дефинирате как се третират B2B потребителите и, ако е необходимо, да автоматизирате предоставянето на определени синхронизирани атрибути на гостите.
В календарите Exchange Online ви позволява да конфигурирате Взаимоотношения в организацията Това позволява на потребителите и в двата наемателя да виждат наличността на колегите си по време на периода на съвместно съществуване. Това е от решаващо значение, за да могат екипите по продажбите, поддръжката, управлението и проектите да продължат да планират, без да се натоварват.
В пощата е обичайна практика да се запази MX запис, сочещ към изходния клиент До момента на спирането използвайте CTUDM или миграционни партиди, за да поддържате пощенските кутии синхронизирани, а когато настъпи договореният прозорец, преместете MX, SPF, DKIM и DMARC записите към целевия клиент. Тестването на това спиране в контролирана среда или с тестови домейни е много полезно.
CTUDM и лицензиране: вграденият инструмент за мигриране на пощенски кутии и OneDrive
Microsoft представи добавката Миграция на потребителски данни между наематели (CTUDM)Този лиценз вече е крайъгълният камък на поддържаните миграции между клиенти за пощенски кутии на Exchange Online и акаунти в OneDrive. Всеки потребител, който се мигрира, се нуждае от този свързан лиценз и той е само за еднократна употреба на обект.
При планирането не е достатъчно само да се изчисли CTUDM: общата стойност на смесения проект Лицензи за Microsoft 365, вътрешни екипни усилия, потенциални партньорски услуги и време, прекарано в тестване и поддръжкаМигрирането на 200 пощенски кутии от 20 GB не е същото като преместването на 5000 потребители с големи пощенски кутии, милиони файлове в SharePoint и десетки критични потоци на Power Platform.
Освен това има и правен компонент, който не може да бъде пренебрегнат: преместването на лични данни между наематели включва преглед Споразумения за обработка на данни, партньорски споразумения, местоположения на центрове за данни и съответствие (GDPR, финансов сектор, здравеопазване, публична администрация и др.)Правните отдели и отделът по съответствие трябва да бъдат информирани за това какво се случва, кога и с какви гаранции.
Миграция на Exchange Online между наематели
Имейлът и календарите често са най-критичните компоненти: ако те се провалят, проектът е „счупен“, дори ако всичко останало е минало добре. Ето защо Миграция от клиент на клиент на Exchange Online Обикновено е проектиран със специално внимание.
С възможностите за мигриране на пощенски кутии между клиенти, администраторите конфигурират Приложение за миграция на Microsoft, крайна точка за миграция и организационна връзка с клиент-източник. В източника се дава съгласие на това приложение, пощенските кутии, които могат да бъдат преместени, са ограничени от групи за сигурност с активирана поща и се установява изходящата връзка.
Потребителите, които ще бъдат мигрирани, трябва да съществуват в целевия клиент като Потребител на поща, с копирани критични атрибути: ExchangeGUID и ArchiveGUID (ако архивирането е активирано), LegacyExchangeDN, трансформиран в X500 адреси, UPN и основен SMTP адрес, подравнени с новия домейн, и targetAddress, сочещ към текущата пощенска кутия в изходния клиент.
След като всичко е готово, от целевия клиент се създават следните елементи: миграционни партиди При CSV файловете синхронизацията е активирана и се оставя да работи до крайния срок. На ден D пакетите се завършват, състоянието на всяка пощенска кутия се валидира (включително разрешенията за пълен достъп, „Изпращане като“, „Изпращане от името на“, споделени и ресурсни пощенски кутии) и се координира промяната на Outlook профила, която в много случаи ще трябва да се пресъздаде, защото пощенската кутия вече ще бъде в друг клиент с различна самоличност.
Сред важните ограничения на Exchange Online в тези сценарии са невъзможността за преместване на пощенски кутии с определени видове задържане и ограничението до максимум 12 помощни файла за пощенски кутии с автоматично разширяващи се архиви и фактът, че публичните папки и съобщенията от Teams, съхранявани в папките за чат на пощенската кутия, не се мигрират.
Миграция на OneDrive между наематели
В OneDrive проблемът обикновено не е преместването на файлове, а споделени връзки и очаквания на потребителите за това къде са „техните“ неща и какво ще се случи с документите, споделени с клиенти и доставчици.
В оригиналния сценарий на миграция на OneDrive между клиенти, администраторите на SharePoint Online установяват връзка между клиенти с Set-SPOCrossTenantRelationshipТе подготвят файл за съпоставяне на идентичността източник-дестинация и стартират миграции на акаунти с Старт-SPOCrossTenantUserContentMoveМожете да имате до 4000 акаунта на опашка едновременно, с предимството, че данните никога не напускат облака на Microsoft, а OneDrive прекарва само няколко минути в режим само за четене.
Необходимо е да се следят няколко ограничения: Максимална дължина на пътя от 400 знака, максимален размер 5 TB и 1 милион елемента на акаунти проблеми с определени символи (например апострофи в URL адреси). Акаунти, които са под правно забранено действие, не могат да бъдат мигрирани, докато задържането не бъде премахнато и приложено отново в целевия клиент.
След като миграцията приключи, Microsoft поставя автоматични пренасочвания от стария URL адрес към новия, така че съществуващите връзки да продължат да работят, докато съществува оригиналният клиент. Разрешенията се запазват, стига потребителите и групите да са правилно картографирани във файла с идентичност.
Миграция на SharePoint Online между клиенти
С SharePoint фокусът се измества към не нарушавайте структурата на сайта, разрешенията и автоматизациите които поддържат бизнес процесите. Това е мястото, където се намират интранет мрежи, проектни сайтове, документация за качество, формуляри и критични работни потоци.
Microsoft е включила възможностите на Миграция на сайтове на SharePoint между клиенти С помощта на SharePoint Online PowerShell могат да се планират до 4000 миграции на сайтове в опашката, а след завършване се поддържа пренасочване, така че старите връзки да продължат да водят към съдържанието в новото му местоположение.
Поддържаните типове сайтове включват Модерни сайтове (със или без групи на Microsoft 365), сайтове, свързани с Teams, класически сайтове и сайтове за комуникацияМигрират се документи, структура на папки, разрешения на потребителско и групово ниво, версии и основна информация за метаданни (дати на създаване/модификация и автори).
Някои елементи не се движат: приложения, работни потоци 2010/2013, задачи на Power Automate или вградени Power Appsкоито трябва да бъдат пресъздадени в целевия клиент. Сайтове, по-големи от 5 TB или с повече от 1 милион елемента, също не се поддържат, а проблемите с дълги пътища (повече от 400 знака) се решават, точно както в OneDrive, чрез преместване или преименуване на папки и файлове.
Специално внимание се изисква от етикети за поверителностАко файловете са защитени с етикети, които прилагат криптиране, работата след мигриране може да е лоша. Препоръчително е да декриптирате или премахнете етикетите преди преместването (например с `Unlock-SPOSensitivityLabelEncryptedFile`) и след това да приложите нови етикети, които са в съответствие с политиките на целевия клиент. Етикетите с потребителски дефинирани разрешения ще блокират директно миграцията, докато не бъдат премахнати.
Многогеографски среди и функции за кръстосани наематели
Когато наемателите са Мулти-геоНещата стават малко по-сложни: трябва да конфигурирате доверие между всички участващи географски екземпляри, да качите файла за съпоставяне на идентичността във всяка дестинация и да не забравяте, че се прилага ограничението от 4000 миграции в опашка. по екземпляр на произходОсвен това, ако даден сайт се окаже в грешна географска област, той не може да бъде преместен между екземпляри на един и същ клиент, използвайки една и съща функция за кръстосани клиенти; за преместването му ще трябва да се използват специфични команди за няколко географски области.
Microsoft Teams: какво може да се премести и какво обикновено се пресъздава
В Teams реалността днес е, че Няма магически бутон, който да копира всички екипи, канали и чатове между наемателите точно такива, каквито са.Типичната стратегия комбинира няколко части.
От една страна, Файловете, свързани с екипи и канали, се преместват с миграцията на SharePoint/OneDriveтъй като те се намират в специфични сайтове и папки на SharePoint. От друга страна, екипите и каналите се пресъздават в целевия клиент, ръчно, с помощта на PowerShell/Graph или с инструменти на трети страни.
Историческият канал говори и най-вече 1:1 или чатове в малки групиТези проблеми обикновено се решават за всеки отделен случай. API-тата за мигриране на Teams ви позволяват да импортирате съобщения от външни платформи, но няма рационализиран, автоматизиран и ефикасен начин за преместване на цялата история между клиенти. Много организации избират да запазят клиент-изходник достъпен за определен период от време за исторически заявки, докато в целевия клиент се създават нови екипи и разговори.
Важно е да се управляват очакванията: потребителите трябва да знаят какво ще остане, какво ще бъде пресъздадено и какво ще бъде достъпно само за гратисен период. И, между другото, това е фантастична възможност да почистете остарялото оборудване, унифицирайте номенклатурата и приложете правилата за изтичане на срока на годност.
Power Platform: гарантиране, че невидимите потоци не са нарушени
Един от най-големите източници на страх при миграциите от наемател на наемател са Автоматизирани процеси в Power Apps, Power Automate и Power BIЧесто никой няма ясна инвентаризация, но потребителите разчитат на тях ежедневно за задачи, вариращи от одобряване на разходи до задействане на известия за инциденти.
Препоръчителната стратегия е да се направи инвентаризация на критични приложения и работни процеси, техните собственици на бизнес и конекторите, които използватСлед това ги пакетирайте в решения, експортирайте ги от изходната среда и ги импортирайте в местоназначението, където връзките и идентификационните данни ще трябва да бъдат преконфигурирани.
Възползвайки се от миграцията, има смисъл да се стандартизират минимум ALM (Управление на жизнения цикъл на приложенията) В Power Platform: отделете средите за разработка, тестване и производство в новия клиент, използвайте управлявани решения, където е уместно, и документирайте зависимостите. Това значително намалява риска привидно незначителна промяна да наруши критичен процес след преместването.
Intune и устройства: повторно записване, без да оставяте хората блокирани
С Intune няма автоматична „миграция на Intune между клиенти“ като такава. Това, което се случва, е Пресъздайте конфигурацията в целевия клиент и планирайте повторното записване на устройството, като разчитате на Windows Autopilot, когато е възможно.
Първо те се експортират или документират политики за съответствие, конфигурационни профили, внедряване на приложения, профили за сигурност и настройки на Defender в изходния клиент. След това в дестинацията се създават еквиваленти, съобразени с новата стратегия за сигурност и управление.
Що се отнася до отборите, се взема решение дали те ще бъдат Повторно осигуряване с автопилот (идеално, когато можете да се възползвате от възможността да оставите устройствата „чисти“ и вече присъединени към новия наемател) или ако ще се използва ръчен процес на влизане и излизане с преживяването „Свържете се с работа или училище„и фирмения портал. За личните устройства (BYOD) е необходима много ясна комуникация относно това какво се изтрива, какво не се изтрива и как да се пререгистрира устройството.“
Преместване на домейн имена: MX, SPF, DKIM и DMARC без изненади
Промяната на домейна обикновено е най-видимият момент на Миграция между клиенти на Microsoft 365Ако имейлите спрат да пристигат или започнат странни връщания, всички забелязват това.
Теорията е добре известна: седмици преди съкращението намалете TTL на DNS записите От основния домейн, домейнът се проверява в целевия клиент (без все още да може да се използва като основен), конфигурациите на SPF, DKIM и DMARC се подготвят и тестват с вторични домейни, ако е необходимо.
По време на промяната трябва да се уверите, че Домейнът не се използва за нито един обект на изходния клиент. (UPN имена, имейл адреси, групи, приложения и др.) се премахват от стария клиент, добавят се към новия и записите MX/SPF/DKIM/DMARC се актуализират с DNS доставчика. След това се наблюдава потокът от поща, проверяват се карантините и се коригира DMARC политиката (започвайки с p=none и увеличавайки до quarantine/reject, след като всичко е стабилно).
Имайте документиран план за връщане към предишните етапиДори и никога да не се използва, това осигурява много спокойствие на всички: ръководството, поддръжката и най-вече техническия екип, който ще наблюдава по време на периода на промяна.
Инструменти на трети страни за миграция между наематели
Въпреки че вградените възможности на Microsoft са се подобрили значително (CTUDM, миграции между наематели за Exchange, OneDrive и SharePoint, Teams API и др.), в много големи проекти те се допълват от специализирани инструменти на трети страни.
Решения като Миграция при поискване на Quest, Cloudiway или BitTitan MigrationWiz Те предлагат централизирани табла за управление за проектиране на вълни, картографиране на самоличности, преместване на поща, документи, екипи и в някои случаи истории на разговори, с много подробни отчети за одит и отстраняване на проблеми.
Тези инструменти са особено полезни, когато е необходимо Разширено отчитане, автоматизирани повторни опити, разширено съвместно съществуване или миграции между множество платформи (например, когато част от средата идва от Google Workspace или други услуги). Те обикновено работят съвместно с API и възможностите на Microsoft, а не срещу тях.
В сравнение с чисто ръчните подходи (PST, IMAP, персонализирани скриптове), използването на зрели инструменти Това намалява оперативния риск и значително ускорява миграциите с хиляди потребители, при условие че те са правилно конфигурирани и тествани предварително с реалистични пилотни проекти.
Сигурност и съответствие: заздравете дестинацията на наемателя от първия ден
Добре планираната миграция от наемател на наемател се използва за вдигнете летвата за безопасност в целевия клиент. Това е идеалният момент да прегледате многофакторното удостоверяване (MFA), правилата за условен достъп, конфигурацията на Defender, защитата от фишинг и политиките за управление на информацията в Microsoft Purview.
Това техническо подкрепление трябва да бъде придружено от основно обучение за потребителиКак да разпознаваме подозрителни имейли, как да споделяме документи сигурно, какво да правим в случай на странно поведение на акаунта и т.н. Няколко кратки, добре проведени сесии предотвратяват много инциденти веднага след преминаването към нова технология, когато потребителите са най-уязвими към объркване.
Оперативни контролни списъци и често срещани грешки
Преобразувайте всичко по-горе в ясни контролни списъци (преди, по време и след всяка вълна) Това е, което в крайна сметка прави разликата в ежедневното изпълнение. Предотвратява загубата на критични стъпки в имейл или импровизиран разговор.
Сред най-често срещаните грешки са Твърде късно закупуване на CTUDM, импровизиране на преместването на домейна, подценяване на Power Platform, забравяне за Intune и неправилно пресъздаване на политики за запазване и етикетиранеДруг класически случай е лошата комуникация с потребителите, което води до широко разпространена паника относно промените в паролите, профили в Outlook, които не се свързват, и Teams, където „неща липсват“.
Работи с Изчистване на KPI (процент на мигрираните пощенски кутии без инциденти, брой билети на потребител, средно време за разрешаване, стабилност на имейла след прекъсване и др.) и съгласуването на критериите за приемане с бизнеса помага за контролиране на миграцията и демонстрира, че проектът не е просто за „преместване на данни“, а за защита на начина, по който работи организацията.
Добре изпълнената миграция между клиенти на Microsoft 365 съчетава Добър първоначален анализ, внимателно съвместно съществуване, интелигентно използване на CTUDM и/или инструменти на трети страни, солидно управление и честна комуникация с потребителите.Когато всички тези елементи си дойдат на мястото, смяната на наемателя престава да бъде скок на вярата и се превръща в контролиран преход, при който бизнесът продължава да работи, докато ИТ отделът се реорганизира, засилва сигурността и оставя къщата по-чиста от преди.