Migracja Microsoft 365 między dzierżawami (Tenant-to-Tenant) — kompletny przewodnik 2026

W świecie fuzji, przejęć, wydzieleń i reorganizacji przedsiębiorstw migracja Microsoft 365 z jednej dzierżawy do drugiej stała się jednym z najtrudniejszych, a zarazem najczęściej podejmowanych projektów IT. W przeciwieństwie do prostej migracji z serwera lokalnego do chmury, przenoszenie danych, tożsamości i konfiguracji pomiędzy dwoma środowiskami Microsoft 365 to wieloetapowy proces, który przy braku starannego planowania może zakończyć się utratą danych, przestojami w komunikacji i chaosem organizacyjnym. W tym artykule przedstawiamy aktualny stan wiedzy na rok 2026 — obejmujący natywne narzędzia Microsoft, rozwiązania zewnętrzne, typowe pułapki i sprawdzone strategie, które pozwolą przeprowadzić migrację bezpiecznie i z minimalnym wpływem na ciągłość biznesową.

Czym jest migracja tenant-to-tenant i kiedy jest konieczna

Migracja typu tenant-to-tenant (T2T) polega na przeniesieniu użytkowników, skrzynek pocztowych, danych SharePoint, zespołów Microsoft Teams, plików OneDrive oraz zasobów pokrewnych z jednej dzierżawy Microsoft 365 do drugiej. Obie dzierżawy są niezależnymi instancjami usługi — każda z własnym Azure Active Directory (obecnie Microsoft Entra ID), własną domeną domyślną, subskrypcjami i przypisanymi licencjami.

Do najczęstszych scenariuszy wymagających migracji T2T należą:

• Fuzje i przejęcia (M&A) — przejmowana firma posiada własną dzierżawę M365, którą należy wchłonąć do środowiska przejmującego.
• Wydzielenie jednostki biznesowej (divestiture) — część organizacji odłącza się, tworząc nową dzierżawę i zabierając swoje dane.
• Restrukturyzacja po błędzie architektonicznym — organizacja odkrywa, że jej dzierżawa została zbudowana nieprawidłowo (np. domeny .onmicrosoft.com są mylące, struktura lasu AD nie pasuje) i decyduje się na "zielone pole".
• Zmiana dostawcy licencji CSP — choć rzadko wymaga pełnej migracji, w skrajnych przypadkach zmiana partnera wiąże się z utworzeniem nowej dzierżawy i przeniesieniem jej zawartości.

Należy podkreślić, że Microsoft nie oferuje jednego przycisku "przenieś wszystko". Migracja T2T to złożony projekt wymagający koordynacji wielu usług i interfejsów API, a każdy typ danych wymaga oddzielnego procesu przenoszenia.

Różnica między migracją T2T a zwykłą migracją do chmury

Zespół IT, który przeprowadził już migrację z Exchange on-premises do Exchange Online, może zakładać, że migracja T2T będzie podobna. Nic bardziej mylnego. W klasycznej migracji hybrydowej istnieje pojęcie źródła i celu, a Exchange zarządza synchronizacją skrzynek, przekierowaniami i współistnieniem. W przypadku migracji T2T obie dzierżawy są równorzędnymi środowiskami chmurowymi — nie ma mechanizmu federacyjnego, który automatycznie obsłuży routing wiadomości, dostęp delegowany czy mapowanie uprawnień. Każdy z tych aspektów musi zostać ręcznie zaplanowany i wykonany.

Dodatkowo zwykła migracja z on-premises do chmury opiera się na tożsamościach źródłowych pochodzących z lokalnego Active Directory. W migracji T2T użytkownicy źródłowi są już obiektami w chmurze (w Entra ID), co oznacza, że nie można po prostu podpiąć ich do innego lasu za pomocą Azure AD Connect. Każdy użytkownik w dzierżawie docelowej stanie się nowym obiektem z nową wartością ObjectId — dlatego zarządzanie mapowaniem tożsamości jest kluczowym wyzwaniem.

Kluczowe składniki migracji: co można, a czego nie można przenieść

Przed rozpoczęciem migracji trzeba trzeźwo ocenić, które zasoby Microsoft 365 faktycznie dają się przenieść, a które wymagają ręcznej rekonfiguracji lub zostaną bezpowrotnie utracone.

Składniki możliwe do migracji

Czego nie można przenieść automatycznie

• Przypisań licencji i polityk — każda dzierżawa ma odrębne subskrypcje, a licencje trzeba przypisać ręcznie lub za pomocą group-based licensing po utworzeniu użytkowników.
• Konfiguracji Entra ID — zasady dostępu warunkowego, ustawienia MFA, logowania do aplikacji firmowych, role administracyjne — wszystko to trzeba odtworzyć ręcznie.
• Historii Microsoft Purview — audyty, etykiety poufności, polityki DLP nie migrują się automatycznie między dzierżawami.
• Ustawień Intune i polityk zarządzania urządzeniami — wymagają wdrożenia od nowa, choć konfiguracje można wyeksportować za pomocą skryptów PowerShell.
• Czatów Teams — wiadomości w czatach prywatnych (1:1 i grupowych) są przechowywane w ukrytych skrzynkach Exchange i są praktycznie nie do przeniesienia bez zaawansowanych narzędzi zewnętrznych, które i tak borykają się z ograniczeniami API.

Strategie migracji: Big Bang, fala hybrydowa i migracja stopniowa

Wybór strategii ma fundamentalne znaczenie dla ryzyka projektowego i doświadczenia użytkownika końcowego. W praktyce wyróżnia się trzy główne podejścia.

Big Bang

Wszyscy użytkownicy i wszystkie dane są przenoszone w jednym, intensywnym oknie migracyjnym — zazwyczaj w ciągu jednego weekendu. W piątek użytkownicy kończą pracę w starej dzierżawie, w poniedziałek logują się już do nowej. Zalety: krótki okres przejściowy, jeden moment odcięcia, prostsze zarządzanie współistnieniem (brak konieczności utrzymywania go w ogóle). Wady: ogromne ryzyko — jeśli cokolwiek pójdzie nie tak, wszyscy użytkownicy są dotknięci jednocześnie. Big Bang wymaga wielokrotnych prób generalnych i perfekcyjnego wykonania. Sprawdza się w małych organizacjach (do 500 użytkowników) z relatywnie prostą strukturą danych.

Fala hybrydowa (współistnienie)

W tej strategii obie dzierżawy działają równolegle przez pewien czas, a użytkownicy są przenoszeni falami. Wymaga to skonfigurowania współdzielenia domen (domain sharing) umożliwiającego routing poczty między dzierżawami na czas migracji. Domenę można na krótki czas dodać do obu dzierżaw — co Microsoft wspiera w ramach scenariusza migracji — a odpowiednie reguły transportu kierują wiadomości do właściwej skrzynki. Współistnienie można osiągnąć również przez przekierowania na poziomie skrzynek (mail forwarding) tworzone ręcznie lub skryptowo. Jest to podejście preferowane dla średnich i dużych organizacji (powyżej 1000 użytkowników), ponieważ rozkłada ryzyko i pozwala reagować na problemy w mniejszej skali.

Migracja stopniowa bez współistnienia

Użytkownicy są przenoszeni falami, ale bez utrzymywania współdzielenia domen. Każda fala zmienia domenę, a komunikacja między użytkownikami, którzy już zostali przeniesieni, a tymi, którzy jeszcze pozostają, odbywa się przez zewnętrzne adresy e-mail lub ręczne przekierowania. Metoda prostsza technicznie, ale uciążliwa dla użytkowników, szczególnie w organizacjach intensywnie korzystających z kalendarzy i planowania spotkań międzyzespołowych.

Natywne narzędzia Microsoft — co potrafią, a czego nie

Microsoft w 2026 roku oferuje dwa główne natywne rozwiązania dla migracji T2T, jednak żadne z nich nie pokrywa pełnego spektrum usług.

Cross-tenant mailbox migration (Exchange Online)

Od 2021 roku Microsoft udostępnia natywną możliwość migracji skrzynek między dzierżawami w trybie współistnienia. Jest to ewolucja architektury migracji hybrydowej, która teraz działa w scenariuszu cloud-to-cloud. Proces wymaga:

• Skonfigurowania relacji organizacyjnej między dzierżawami (za pomocą PowerShell — nie ma interfejsu GUI).
• Utworzenia obiektu użytkownika poczty (MailUser) w dzierżawie docelowej przed migracją.
• Wykonania żądania migracji (New-MoveRequest) wskazującego na skrzynkę źródłową.

Natywna migracja skrzynek zachowuje strukturę folderów, kalendarze, kontakty i uprawnienia pełnomocnictwa. Ma jednak ograniczenia: nie przenosi zawartości archiwum w chmurze, nie obsługuje migracji skrzynek z założonym blokowaniem postępowania sądowego (litigation hold) bez uprzedniego zdjęcia blokady i nie przenosi automatycznie ustawień Outlooka na urządzeniach klienckich.

SharePoint cross-tenant migration

W 2024 roku Microsoft udostępnił w publicznej wersji zapoznawczej narzędzie do migracji SharePoint pomiędzy dzierżawami, które w 2026 roku osiągnęło status ogólnej dostępności (GA). Narzędzie opiera się na infrastrukturze SharePoint Migration Tool (SPMT), ale działa na poziomie dzierżawy, umożliwiając przenoszenie witryn wraz z uprawnieniami, metadanymi i historią wersji. Proces jest zarządzany z poziomu SharePoint Admin Center dzierżawy docelowej. Ograniczenia obejmują brak wsparcia dla witryn połączonych z Microsoft 365 Groups (co jest paradoksalne, bo to właśnie SharePoint stanowi backend dla Teams) oraz maksymalny rozmiar migrowanej witryny ograniczony do 25 TB.

Czego brakuje

Kluczowa luka w natywnych narzędziach Microsoft to Teams. Mimo że pliki kanałów Teams są przechowywane w SharePoint i teoretycznie można je przenieść wraz z witryną, to sama struktura zespołów, członkostwo, ustawienia, aplikacje i historia konwersacji nie są obsługiwane natywnie. Podobnie OneDrive — choć technicznie działa na tej samej platformie co SharePoint, natywne narzędzie nie oferuje dedykowanej ścieżki dla kont OneDrive w scenariuszu T2T. Te braki powodują, że większość średnich i dużych migracji korzysta z narzędzi zewnętrznych.

Narzędzia zewnętrzne i ich rola w 2026 roku

Ekosystem ISV (Independent Software Vendors) zareagował na lukę w ofercie Microsoftu tworząc zaawansowane platformy do migracji T2T. Do wiodących rozwiązań w 2026 roku należą:

• Quest On Demand Migration — kompleksowa platforma obsługująca Exchange, SharePoint, Teams, OneDrive i Power Platform. Oferuje automatyczne mapowanie tożsamości, współistnienie poczty i szczegółowe raportowanie. Jako narzędzie dojrzałe rynkowo jest preferowane w dużych środowiskach korporacyjnych.
• BitTitan MigrationWiz — lekkie, oparte na chmurze narzędzie, które nie wymaga instalacji agentów. Doskonałe do migracji skrzynek pocztowych i OneDrive, z prostym modelem licencjonowania per-skrzynka. Wsparcie dla Teams jest bardziej ograniczone niż w Quest.
• AvePoint Fly — mocno zintegrowane z ekosystemem Microsoft, oferuje zaawansowaną migrację SharePoint i Teams. Szczególnie dobrze radzi sobie z przekształcaniem witryn klasycznych w nowoczesne i z migracją Microsoft 365 Groups.
• ShareGate — popularne w mniejszych środowiskach, świetne do migracji zawartości SharePoint, choć nie oferuje pełnego zakresu T2T.

Niezależnie od wybranego narzędzia, kluczowym kryterium wyboru powinna być obsługa tzw. mapowania tożsamości — czyli zdolność do skojarzenia użytkownika źródłowego z nowym obiektem w dzierżawie docelowej, tak aby uprawnienia, delegacje i własność plików zostały zachowane.

Krok po kroku: plan migracji T2T na 2026 rok

Poniżej przedstawiamy sprawdzony plan obejmujący fazy: przygotowawczą, pilotażową, wykonawczą i stabilizacyjną.

Faza 1: Inwentaryzacja i przygotowanie (4–12 tygodni)

1. Audyt dzierżawy źródłowej — skataloguj wszystkie używane usługi M365 (nie tylko Exchange i SharePoint, ale też Power Automate, Power BI, Forms, Stream, Bookings, Viva Engage). Dla każdej usługi określ, czy będzie migrowana, odtwarzana ręcznie, czy porzucona.
2. Mapowanie użytkowników i grup — przygotuj pełną listę UPN (User Principal Name), grup, kontaktów i zasobów. Zdefiniuj docelowy format UPN (najczęściej związany z nową domeną firmową).
3. Weryfikacja domen — dodaj i zweryfikuj domeny w dzierżawie docelowej. Pamiętaj, że domena może być zweryfikowana tylko w jednej dzierżawie naraz w trybie produkcyjnym — przygotuj harmonogram przełączenia.
4. Konfiguracja dzierżawy docelowej — wdróż polityki bezpieczeństwa, zasady dostępu warunkowego, MFA, etykiety poufności, polityki DLP, konfigurację Intune. Użyj podejścia Infrastructure as Code (np. Microsoft365DSC), aby zapewnić spójność i powtarzalność.
5. Przygotowanie komunikacji — przygotuj harmonogram komunikacji z użytkownikami. Każdy etap powinien być poprzedzony jasnym przekazem: co się zmieni, kiedy i co użytkownik musi zrobić (np. ponownie skonfigurować profil Outlooka, zalogować się do Teams, ponownie zsynchronizować OneDrive).

Faza 2: Pilotaż (2–4 tygodnie)

1. Wybierz reprezentatywną grupę 10–50 użytkowników (tzw. early adopters lub championów).
2. Przeprowadź migrację ich skrzynek pocztowych, OneDrive i odpowiednich zasobów SharePoint/Teams.
3. Zbierz szczegółowe informacje zwrotne — nie tylko techniczne (czy dane dotarły), ale też dotyczące doświadczeń użytkownika (czy profil Outlooka skonfigurował się automatycznie, czy udostępnione pliki działają).
4. Na podstawie pilotażu skoryguj parametry migracji, harmonogram i materiały komunikacyjne.

Faza 3: Migracja właściwa (zależna od liczby użytkowników)

1. Wykonuj migrację falami (zalecane) — np. po 100–300 użytkowników na falę, z 3–5-dniową przerwą między falami na stabilizację.
2. Dla każdej fali: przeprowadź pre-stage (wstępną synchronizację danych) na 7–14 dni przed odcięciem, a następnie delta sync (synchronizację przyrostową) w dniu odcięcia.
3. Po migracji każdej fali natychmiast weryfikuj integralność danych i uprawnień. Zastosuj zasadę "migruj, weryfikuj, odblokowuj".
4. Obsługuj współistnienie poczty przez okres migracji — użytkownicy, którzy jeszcze nie zostali przeniesieni, muszą móc wymieniać wiadomości z tymi, którzy już są w nowej dzierżawie.

Faza 4: Stabilizacja i wycofanie starej dzierżawy (2–4 tygodnie)

1. Utrzymuj starą dzierżawę w stanie tylko do odczytu przez 30 dni jako zabezpieczenie.
2. Przekieruj wszystkie przepływy integracyjne: aplikacje zewnętrzne, zapory SMTP, systemy HR, kopie zapasowe.
3. Po okresie stabilizacji i potwierdzeniu, że wszystkie dane zostały pomyślnie przeniesione, usuń domeny ze starej dzierżawy, dezaktywuj subskrypcje i zamknij dzierżawę.

Typowe pułapki i jak ich uniknąć

Nawet najlepiej zaplanowana migracja T2T może napotkać przeszkody. Oto najczęściej spotykane problemy i sposoby ich unikania:

Niedoszacowanie zależności od zewnętrznych integracji. Aplikacje firm trzecich zarejestrowane w starej dzierżawie Entra ID (enterprise applications) nie działają automatycznie w nowej. Każda integracja musi zostać ponownie skonfigurowana — a proces ten często wymaga współpracy z dostawcą aplikacji. Rozwiązanie: przeprowadź audyt integracji przed migracją i uwzględnij czas na ich ponowne wdrożenie w harmonogramie.

Utrata udostępnień zewnętrznych. Linki udostępniania SharePoint i OneDrive wygenerowane w starej dzierżawie stają się martwe po migracji. Zewnętrzni partnerzy, z którymi współpracujesz, stracą dostęp. Rozwiązanie: skomunikuj się z partnerami przed migracją; tam gdzie to możliwe, użyj udostępniania opartego na tożsamościach gości (B2B) zamiast anonimowych linków.

Samooczyszczanie OneDrive. Microsoft usuwa konto OneDrive 30 dni po usunięciu użytkownika. Jeśli proces migracji się wydłuży, dane mogą zostać bezpowrotnie utracone. Rozwiązanie: włącz blokadę przechowywania (retention hold) na kontach OneDrive przed rozpoczęciem migracji.

Niekompatybilność wersji aplikacji klienckich. Użytkownicy pracujący na starszych wersjach pakietu Office mogą mieć problemy z ponowną konfiguracją profili po migracji. Rozwiązanie: uwzględnij w planie aktualizację klientów do wersji wspieranych przez Microsoft (obecnie Microsoft 365 Apps for Enterprise w kanale Current lub Monthly Enterprise).

Niewłaściwe mapowanie grup. Grupy Microsoft 365 w dzierżawie źródłowej mają inny identyfikator niż odpowiadające im grupy w dzierżawie docelowej. Jeśli mapowanie nie zostanie przeprowadzone starannie, własność plików i uprawnienia do zasobów zostaną utracone. Rozwiązanie: użyj narzędzia z zaawansowanym mapowaniem tożsamości lub przygotuj skrypty PowerShell do rekonstrukcji członkostwa grup po migracji.

Częste pytania (FAQ)

Jak długo trwa migracja Microsoft 365 między dzierżawami?

Dla organizacji 500-osobowej przy użyciu narzędzi firm trzecich i strategii falowej — od 6 do 12 tygodni całkowitego czasu projektu, w tym 2–4 tygodnie na właściwą migrację danych. Dla organizacji powyżej 5000 użytkowników — od 3 do 6 miesięcy. Sam transfer danych dla pojedynczej fali 300 użytkowników trwa zazwyczaj 48–72 godziny, z czego większość to synchronizacja wstępna wykonywana w tle przed odcięciem.

Co dzieje się z subskrypcjami i licencjami podczas migracji?

Licencje nie są przenoszone automatycznie. W dzierżawie docelowej musisz mieć aktywne subskrypcje na odpowiednią liczbę użytkowników. Licencje w starej dzierżawie można anulować po zakończeniu migracji, ale należy zachować ostrożność: przedwczesne anulowanie może spowodować utratę dostępu do danych, które jeszcze nie zostały przeniesione. Rekomendowane jest utrzymanie starej dzierżawy przez minimum 30 dni po migracji jako środowiska tylko do odczytu.

Czy użytkownicy stracą historię czatów w Microsoft Teams?

Tak — historia prywatnych czatów Teams (1:1 i grupowych) nie jest przenoszona natywnie i stanowi jeden z największych problemów migracji T2T. Niektóre narzędzia firm trzecich oferują częściowe rozwiązania, ale nawet one nie gwarantują pełnego odwzorowania ze względu na ograniczenia API Microsoft Graph. Konwersacje w kanałach zespołów są technicznie przechowywane w skrzynkach grupowych Exchange i mogą być migrowane razem ze skrzynką, ale tylko jeśli są migrowane jako wiadomości e-mail, co zmienia ich format.

Jak obsłużyć urządzenia mobilne użytkowników po migracji?

Użytkownicy korzystający z Outlooka na iOS lub Androidzie zazwyczaj muszą usunąć konto i dodać je ponownie. Jeśli organizacja korzysta z Microsoft Intune i aplikacji Portal firmy, konieczne jest ponowne zarejestrowanie urządzeń w nowej dzierżawie. Dla organizacji z flotą setek lub tysięcy urządzeń mobilnych ten proces jest wyjątkowo czasochłonny i powinien zostać uwzględniony w planie komunikacji i wsparcia.

Co z danymi w Microsoft Forms, Stream i Planner?

Microsoft Forms umożliwia eksport formularzy do nowego właściciela, ale tylko w ramach tej samej dzierżawy — nie działa to między dzierżawami. Formularze muszą zostać odtworzone ręcznie. Stream Classic został wycofany, a Stream na SharePoint przechowuje wideo w witrynach SharePoint, które można migrować. Planner wymaga ręcznego odtworzenia planów lub użycia narzędzi firm trzecich.

Czy mogę przeprowadzić migrację T2T samodzielnie, bez zewnętrznych narzędzi?

Tak, dla małych organizacji (do 50 użytkowników) z prostą strukturą danych możliwe jest użycie natywnych narzędzi Microsoft — cross-tenant mailbox migration dla Exchange i SharePoint cross-tenant migration dla witryn. Jednak dla organizacji używających Teams, OneDrive na szeroką skalę lub posiadających skomplikowane uprawnienia, narzędzia zewnętrzne są praktycznie niezbędne. Koszt licencji narzędzi firm trzecich należy rozpatrywać w kontekście oszczędności czasu i redukcji ryzyka utraty danych.

Jak przygotować użytkowników na zmianę?

Komunikacja jest kluczowa. Minimum 4 tygodnie przed migracją wyślij pierwszą informację ogólną: co się zmieni, dlaczego i kiedy. Tydzień przed migracją danej grupy — szczegółowe instrukcje: jak ponownie skonfigurować Outlooka, Teams, OneDrive, jak zalogować się do nowej dzierżawy. W dniu migracji zapewnij wsparcie helpdesku w rozszerzonych godzinach. Przygotuj krótkie filmy instruktażowe i FAQ dostępne dla wszystkich pracowników.

Czy mogę zatrzymać starą dzierżawę po migracji?

Tak, ale to kosztuje. Każda aktywna subskrypcja generuje opłaty. Rekomendowaną praktyką jest utrzymanie starej dzierżawy w stanie tylko do odczytu przez 30 dni, a następnie usunięcie domen, anulowanie subskrypcji i zamknięcie dzierżawy. Przed zamknięciem wykonaj pełny backup wszystkich danych w dzierżawie źródłowej — nawet jeśli zostały już przeniesione, backup stanowi ostateczne zabezpieczenie.

Czy migracja T2T wpłynie na zgodność z RODO lub innymi regulacjami?

Tak i to w istotny sposób. Podczas migracji dane opuszczają granice administracyjne jednej dzierżawy i trafiają do drugiej. Jeśli dzierżawa docelowa znajduje się w innym regionie geograficznym (np. źródło w Europie Północnej, cel w Stanach Zjednoczonych), oznacza to transfer danych między regionami, co może wymagać dopełnienia dodatkowych formalności prawnych. Skonsultuj się z inspektorem ochrony danych przed rozpoczęciem migracji. Dobrą praktyką jest wybór tego samego regionu geograficznego dla dzierżawy docelowej, chyba że istnieją istotne powody biznesowe dla zmiany.

Gdzie szukać dodatkowego wsparcia?

Profesjonalnie przygotowana migracja Microsoft 365 to inwestycja, która zwraca się w postaci uporządkowanego środowiska i zadowolonych użytkowników. Jeśli szukasz sprawdzonego partnera, który pomoże Ci w migracji oraz zapewni odpowiednie licencje — od wstępnego audytu po stabilizację po migracji — zapraszamy do zapoznania się z ofertą KluczeSoft.pl, gdzie znajdziesz zarówno niezbędne subskrypcje Microsoft 365, jak i doświadczone wsparcie techniczne przy każdym etapie projektu.