Rate this post

Повний посібник з перенесення середовища між орендарями

Нова можливість у центрі адміністрування Power Platform дозволяє адміністраторам переносити ціле середовище з одного орендаря (tenant) до іншого. Це відрізняється від традиційної міграції рішень, яка переносить лише компоненти між середовищами в межах одного tenant. Міграція tenant-to-tenant дає змогу переміщувати повністю всю середу між організаційними межами.

У цій статті розглянуто сценарії використання, вимоги, підтримувані типи середовищ, попередні умови, процес міграції, адміністративні дії та важливі обмеження.

1. Типовий сценарій міграції між орендарями

Розглянемо організацію, яка використовує кілька tenant-ів:

  • Основний корпоративний tenant для робочих застосунків, потоків, агентів та операційних задач.

  • Окремий tenant для розробки, де команда досліджує можливості, тестує функції та проводить експерименти.

Припустимо, що в dev-tenant створено щось важливе, і це потрібно перенести до основного tenant компанії. Замість експорту окремих компонентів або рішень можна перенести все середовище повністю з одного tenant до іншого.

Це принципово відрізняється від міграції між середовищами в межах одного tenant, де зазвичай використовуються:

  • керовані рішення (managed solutions)

  • некеровані рішення (unmanaged solutions)

Ці методи переносять лише компоненти. Міграція між орендарями переносить усе середовище.

2. Переміщення середовища в Power Platform Admin Center

Коли адміністратор вибирає середовище в центрі адміністрування Power Platform, з’являється опція Move environment.

Після запуску перенесення відображаються статуси, наприклад:

  • Pending request for approval to move environments

  • Your request to move environments is pending approval

Можливі дві ситуації:

  1. Ви надіслали запит на перенесення середовища до іншого tenant.

  2. Інший tenant надіслав запит на перенесення середовища до вас.

Кожен запит має бути переглянутий і затверджений.

3. Вимога керованих середовищ (Managed Environments)

Міграція tenant-to-tenant підтримується лише для керованих середовищ.

Кероване середовище надає розширені можливості керування та контролю, недоступні у звичайних середовищах.

4. Підтримувані та непідтримувані типи середовищ

Не всі середовища можна переносити.

Підтримуються

  • Production

  • Sandbox

Не підтримуються

  • Developer

  • Default

  • Trial

  • Teams

Також не можна переносити Dataverse-організації, пов’язані з Finance and Operations (станом на кінець 2025 року).

5. Відмінності ідентифікації та ліцензування

Вихідний і цільовий tenant незалежні, тому:

  • домени користувачів різні

  • email-адреси різні

  • ліцензії можуть відрізнятися

  • адміністративні ролі розділені

Приклад:

  • джерело: girish.onmicrosoft.com

  • призначення: girishinc.onmicrosoft.com

Користувачів потрібно зіставити під час міграції.

6. Необхідні адміністративні права

Міграція — це адміністративна операція.

Потрібні права адміністратора:

  • у вихідному tenant

  • у цільовому tenant

7. Що переноситься

Переноситься все середовище, включно з:

  • Power Apps

  • Power Automate flows

  • ресурсами Copilot Studio

  • даними Dataverse

Однак деякі елементи потребують ручних дій.

8. Що потрібно експортувати або налаштовувати вручну

Ручний експорт

  • рішення Power Apps

  • чат-боти Copilot Studio

Ручне налаштування

  • connectors

  • environment variables

  • connections

  • gateways

Очищення

  • solution-aware apps потрібно видалити після експорту

9. Вимога PowerShell

PowerShell для адміністрування Power Platform має бути встановлений:

  • у адміністратора джерела

  • у адміністратора призначення

Він встановлюється з PowerShell Gallery і використовується для виконання команд міграції.

Деякі дії не можна виконати через інтерфейс.

10. Переналаштування інтеграцій після міграції

Деякі служби потребують переналаштування:

  • Dynamics 365 for Outlook

  • server-side synchronization

  • інтеграція з SharePoint

Наприклад, якщо SharePoint був підключений у вихідному tenant, потрібно повторно налаштувати зв’язок у цільовому.

11. Файл зіставлення користувачів (критично важливий)

Потрібно створити файл зіставлення користувачів (зазвичай Excel).

Він містить:

  • user principal name джерела

  • відповідного користувача призначення

Приклад:

Користувач джерела Користувач призначення
g@g.onmicrosoft.com g1@gcorp.onmicrosoft.com

Після міграції власники записів змінюються відповідно до зіставлення.

12. Надсилання запиту на перенесення

Процес починається з вибору середовища та команди Move environment.

Система формує:

  • migration request

  • target tenant ID

  • migration ID

Середовище не переноситься одразу — потрібне схвалення цільового tenant.

13. Команди PowerShell

Submit migration request

Вказати середовище та tenant призначення.

View migration requests

Перевірити статус.

View approval requests

Переглянути запити, що очікують схвалення.

Approve migration

Використати migration ID.

14. Визначення source і destination

Кожен tenant має:

  • унікальний tenant ID

  • власний домен

  • окремий набір користувачів

Перенесення можливе в обидва боки за наявності адмін-доступу.

15. Як дізнатися target tenant ID

У Power Platform Admin Center:

  • відкрити session details

  • знайти target tenant ID

16. Надсилання запиту не запускає перенесення одразу

Перенесення починається лише після:

  1. перевірки запиту

  2. схвалення через PowerShell

17. Перегляд запитів, що очікують

Адміністратор може:

  • переглянути запити

  • перевірити деталі

  • скасувати перенесення

18. Схвалення міграції

Потрібно:

  1. отримати migration ID

  2. виконати команду approval

Через інтерфейс це поки зробити неможливо.

19. Відстеження статусу

Можливі статуси:

  • pending

  • submitted

  • awaiting approval

20. Скасування міграції

Можна скасувати до схвалення:

  • відхилити запит

  • не виконувати approval

21. Обмеження (на початок 2026 року)

  • лише managed environments

  • лише production і sandbox

  • Finance and Operations Dataverse не підтримується

  • частина компонентів експортується вручну

  • інтеграції налаштовуються повторно

  • approval тільки через PowerShell

22. Загальний алгоритм міграції

  1. Підготовка середовища

  2. Ручний експорт компонентів

  3. Створення файлу зіставлення користувачів

  4. Встановлення PowerShell

  5. Надсилання запиту

  6. Отримання migration ID

  7. Схвалення у цільовому tenant

  8. Переналаштування сервісів

23. Висновок

Міграція середовища між орендарями в Power Platform Admin Center дозволяє переносити повністю робочі середовища між tenant-ами, а не окремі компоненти. Це особливо корисно, коли розробка, тестування та експлуатація виконуються в різних орендарях.

Процес потребує підготовки, адміністративної координації, використання PowerShell і правильного зіставлення користувачів. За умови правильної організації перенесення середовища між орендарями стає керованим процесом, що підтримується технологіями Microsoft.