
ESU może dać dodatkowy czas firmom na opracowanie planu wyjścia z nie wspieranych systemów, ale nie jest to rozwiązanie docelowe. Poza ESU, Microsoft nie będzie już zapewnił standardowego wsparcia technicznego, dostarczania poprawek ani aktualizacji bezpieczeństwa dla Exchange 2016 i 2019.
Dla wielu firm naturalnym kierunkiem jest migracja Exchange do Microsoft 365. Sama decyzja o przeniesieniu poczty do chmury nie rozwiązuje jednak najważniejszego problemu: jak przeprowadzić migrację tak, żeby nie zakłócić pracy użytkowników, nie zakłócić pracy zależnych od poczty aplikacji, ale też nie utrzymywać starego środowiska dłużej, niż to konieczne.
W materiałach o migracji najczęściej pojawiają się trzy podejścia: cutover, staged i hybrid. Nie są to jednak trzy równorzędne warianty. Staged ma dziś głównie znaczenie historyczne, cutover sprawdza się w określonych małych środowiskach, a hybrid obejmuje kilka scenariuszy – od uproszczonej migracji Express po rozbudowany okres współistnienia.
Koniec wsparcia Exchange 2016 i 2019: migracja nie jest jedyną opcją
Nie oznacza to jednak, że Microsoft 365 będzie automatycznie najtańszym wyborem w każdym przypadku. Decyzja powinna uwzględniać obecne koszty infrastruktury i administracji, liczbę oraz rodzaj użytkowników, wymagania dotyczące retencji i archiwizacji, integracje aplikacji korzystających z lokalnego Exchange, wymagania regulacyjne, model zarządzania tożsamościami oraz usługi zawarte w obecnych lub planowanych licencjach.
Alternatywą pozostaje Exchange Server Subscription Edition. Dla organizacji, które z powodów technicznych, regulacyjnych lub biznesowych muszą utrzymywać część poczty lokalnie, może to być model docelowy albo element architektury hybrydowej.
Dlatego właściwe pytanie nie brzmi wyłącznie: „chmura czy własna infrastruktura?”. Najpierw trzeba ustalić, jaki model poczty i zarządzania tożsamością ma działać po zakończeniu projektu.
Cutover, staged i hybrid - czym różnią się w praktyce?
Cutover: cała organizacja w jednym przełączeniu
Zwykle limit techniczny dla przełączenia cutover to jest około 2000 skrzynek na raz, ale jednocześnie rozsądny limit na pojedynczy zespół IT wpierający użytkowników to maksymalnie około 150. Ta różnica nie jest drobnym zastrzeżeniem. Limit techniczny mówi, ile skrzynek obsłuży mechanizm i skrypty przełączające. Nie odpowiada na pytanie, czy zespół IT poradzi sobie jednocześnie z ponownym logowaniem użytkowników na nowe konta, konfiguracją Outlooka i urządzeń mobilnych, problemami z Autodiscover, zmianami w aplikacjach wysyłających pocztę oraz zgłoszeniami po przełączeniu.
Cutover jest dobrym wyborem dla małej, stosunkowo prostej organizacji, która chce przenieść całe środowisko w krótkim czasie i nie potrzebuje dłuższego okresu współistnienia. Nie należy jednak sięgać po tę metodę tylko dlatego, że liczba skrzynek mieści się w technicznym limicie.
Staged: dawniej standardowa ścieżka
Dziś jej znaczenie jest jeszcze mniejsze. Microsoft wycofał onboarding Staged OutlookAnywhere 8 maja 2025 roku. Organizacje, które nie zakończyły procesu przed tą datą, muszą użyć innej metody, na przykład hybrid remote onboarding.
To istotne, bo wiele starszych porównań nadal przedstawia staged jako pełnoprawną alternatywę. W nowym projekcie nie należy zakładać jej dostępności tylko dlatego, że pojawia się w archiwalnej dokumentacji. Jeśli organizacja nadal korzysta z Exchange 2003 lub 2007, pierwszym krokiem powinno być ustalenie wspieranej ścieżki przejścia, a nie automatyczne planowanie staged.
Hybrid: migracja etapami i kontrolowany okres współistnienia
To pozwala rozłożyć migrację na działy, lokalizacje lub grupy. Problemy wykryte w pierwszych partiach nie dotykają od razu całej firmy, a zespół może poprawić konfigurację przed kolejnym etapem.
Hybrid daje największe możliwości, ale wymaga też najwięcej przygotowania. Organizacja musi zadbać między innymi o odpowiednią wersję i poziom aktualizacji Exchange, konfigurację Hybrid Configuration Wizard, prawidłowe działanie Autodiscover, publiczne certyfikaty, dostępność wymaganych usług i endpointów, synchronizację tożsamości z Microsoft Entra ID oraz poprawny przepływ poczty między środowiskami. Microsoft wskazuje przy tym wymóg aktualnego albo bezpośrednio poprzedniego CU lub RU właściwego dla używanej wersji Exchange.
Hybrid nie oznacza automatycznie „migracji bez ryzyka” ani gwarantowanego braku przerw. Pozwala jednak lepiej kontrolować kolejność przenoszenia użytkowników i ograniczyć wpływ pojedynczego problemu na całą organizację.
A co z Express (Minimal Hybrid)?
W praktyce wybór nie zawsze sprowadza się więc do „cutover albo pełny hybrid”. Dla mniejszego, ale nowocześniejszego środowiska Express bywa rozsądniejszą ścieżką niż klasyczny cutover. Jego dostępność i zasadność trzeba jednak ocenić na podstawie wersji Exchange, modelu tożsamości i stanu środowiska źródłowego.
Porównanie metod migracji Exchange
| Kryterium | Cutover | Staged | Hybrid |
|---|---|---|---|
| Główne zastosowanie | Przeniesienie całej małej organizacji | Starsze środowiska Exchange 2003/2007 | Migracja etapowa i okres współistnienia |
| Skala | Technicznie do 2000, praktycznie zwykle do ok. 150 skrzynek na raz dla jednego zespołu wsparcia IT | Metoda legacy | Średnie, duże i złożone środowiska |
| Sposób migracji | Cała organizacja w jednym projekcie | Partie użytkowników | Partie użytkowników z integracją środowisk |
| Współistnienie | Ograniczone | Ograniczone | Rozbudowane |
| Synchronizacja katalogu | Zależna od docelowego modelu tożsamości | Wymagana w klasycznym scenariuszu | Zwykle wymagana |
| Wpływ na użytkowników | Skoncentrowany wokół przełączenia | Rozłożony etapami | Rozłożony na kolejne grupy |
| Złożoność techniczna | Najniższa | Nieadekwatna dla nowych projektów | Najwyższa |
| Status w nowych projektach | Możliwy w określonych środowiskach | Nie powinien być domyślnie planowany | Najczęstszy wariant dla złożonych organizacji |
Czas projektu nie wynika z samej nazwy metody. O harmonogramie częściej decydują wolumen danych, przepustowość łącza, liczba integracji, kondycja Active Directory, foldery publiczne, archiwa oraz sposób zarządzania urządzeniami użytkowników.
Kiedy cutover, a kiedy hybrid
Cutover warto rozważyć, gdy organizacja ma stosunkowo mało skrzynek, chce przenieść całość w jednym terminie i nie potrzebuje dłuższego współistnienia z lokalnym Exchange. Środowisko powinno być przy tym możliwie proste.
Im więcej folderów publicznych, aplikacji biznesowych, nietypowych konektorów, archiwów i urządzeń wysyłających pocztę, tym mniejsze znaczenie ma sama liczba użytkowników. Firma z 80 skrzynkami i kilkudziesięcioma integracjami może mieć trudniejszy projekt niż organizacja z 250 użytkownikami korzystająca niemal wyłącznie ze standardowych funkcji Exchange.
W cutover ryzyko skupia się wokół jednego punktu. Ewentualne błędy dotykają od razu większej części organizacji, dlatego przed właściwym przełączeniem tak ważne są testy DNS, Autodiscover, licencji, klientów i przepływu wiadomości.
Hybrid jest naturalnym wyborem, gdy migracja ma iść etapami albo trzeba przez pewien czas utrzymywać skrzynki lokalnie i w chmurze jednocześnie. Najczęstsze argumenty za hybrydą to kilkaset lub więcej skrzynek, wiele oddziałów i zespołów, migracja działami, rozbudowane Active Directory, foldery publiczne i archiwa, duża liczba aplikacji zintegrowanych z pocztą, potrzeba pilotażu oraz wymagania regulacyjne.
Zamiast przenosić wszystkich naraz, można zacząć od zespołu IT, przejść do grupy pilotażowej i dopiero po potwierdzeniu poprawności migrować kolejne działy.
Nie wiesz, czy Twoje środowisko kwalifikuje się do cutover, Express czy pełnej hybrydy?
Co trzeba sprawdzić przed wyborem metody
Stan Exchange i Active Directory. Sprawdzamy dokładne wersje, zainstalowane aktualizacje, topologię organizacji, liczbę domen i lasów oraz kondycję replikacji AD. Środowisko dawno nieaktualizowane może wymagać przygotowania jeszcze przed właściwą migracją.
Tożsamości i synchronizacja katalogu. Trzeba zdecydować, czy użytkownicy po migracji pozostaną synchronizowani z lokalnego AD, czy docelowo będą zarządzani wyłącznie w chmurze. Ta decyzja wpływa na Entra Connect lub Cloud Sync, zarządzanie odbiorcami i możliwość późniejszego usunięcia ostatniego serwera Exchange.
Integracje i SMTP. Pocztę wysyłają nie tylko Outlooki, ale też systemy ERP, aplikacje księgowe, monitoring, skanery, drukarki wielofunkcyjne, formularze internetowe i helpdesk. Każde takie połączenie trzeba zinwentaryzować i przypisać do docelowej metody uwierzytelniania lub relayu.
Foldery publiczne, archiwa i skrzynki współdzielone. Mają własne wymagania migracyjne i często zawierają znacznie więcej danych niż standardowe skrzynki. Pominięcie ich w estymacji zmienia zarówno harmonogram, jak i wybór metody.
DNS, certyfikaty i przepływ poczty. Przed przełączeniem sprawdza się m.in. MX, Autodiscover, SPF, DKIM, DMARC, konektory i reguły transportowe. Sama zmiana MX nie kończy projektu.
Wolumen danych i przepustowość. Dwie organizacje z tą samą liczbą skrzynek mogą potrzebować zupełnie różnych harmonogramów. Znaczenie ma średni rozmiar skrzynki, liczba dużych archiwów, wydajność środowiska źródłowego i realna szybkość przesyłania danych.
Modern Auth i SMTP AUTH: termin nie kończy się na „marcu 2026”
Pierwotny termin był kilkukrotnie zmieniany. Według aktualnego harmonogramu zachowanie SMTP AUTH Basic Authentication pozostaje bez zmian do końca grudnia 2026 roku. Następnie zostanie domyślnie wyłączone dla istniejących tenantów, przy czym administrator nadal będzie mógł je włączyć. Datę ostatecznego usunięcia Microsoft ma ogłosić w drugiej połowie 2027 roku.
To nie powód, żeby odkładać modernizację integracji. To raczej argument, żeby nie wpisywać do planu nieaktualnego założenia, że wszystkie połączenia oparte na Basic Auth przestały działać w marcu 2026.
W assessmencie warto osobno zidentyfikować klientów pocztowych, aplikacje korzystające z EWS/POP/IMAP, systemy używające SMTP AUTH, urządzenia wysyłające pocztę oraz aplikacje korzystające z lokalnego relayu Exchange.
Migracja ostatniej skrzynki nie zawsze kończy projekt
Po właściwym transferze Source of Authority lokalny Exchange nie musi być już utrzymywany wyłącznie po to, żeby zarządzać odbiorcami. Docelowy model administracyjny trzeba zaplanować przed migracją. Inaczej projekt kończy się sytuacją, w której wszystkie skrzynki są w chmurze, ale organizacja utrzymuje lokalny serwer bez jasno określonej roli.
Od czego zależy koszt migracji Exchange
Koszt migracji Exchange składa się z kilku warstw.
Licencje Microsoft 365 lub Exchange Online – ich poziom zależy nie tylko od pojemności skrzynek, ale też od wymagań bezpieczeństwa, archiwizacji, retencji, audytu i zgodności.
Przygotowanie środowiska – aktualizacja Exchange, uporządkowanie AD, naprawa synchronizacji czy wymiana certyfikatów potrafią być istotną częścią projektu, mimo że nie przenoszą jeszcze żadnej skrzynki.
Realizacja migracji – konfiguracja tenantu, domen, polityk, tożsamości, konektorów, partii i pilotażu. Przy złożonych środowiskach dochodzą narzędzia firm trzecich oraz prace nad folderami publicznymi, archiwami i aplikacjami.
Stabilizacja po przełączeniu – wsparcie użytkowników, usuwanie błędów, kontrola przepływu poczty i wyłączenie zbędnych elementów infrastruktury.
Dlatego wycena oparta wyłącznie na liczbie skrzynek bywa myląca. Liczba użytkowników jest ważna, ale nie pokazuje stanu Active Directory, liczby integracji ani poziomu skomplikowania architektury.
Jak może wyglądać projekt migracji z ISCG
Projekt powinien zaczynać się od assessmentu, a nie od utworzenia pierwszej partii migracyjnej.
- Inwentaryzacja środowiska – wersje Exchange, aktualizacje, liczba i rodzaje skrzynek, archiwa, foldery publiczne, domeny, certyfikaty oraz integracje.
- Projekt architektury docelowej – metoda migracji, model tożsamości, sposób zarządzania odbiorcami, przepływ poczty i plan wycofania środowiska lokalnego.
- Przygotowanie i pilotaż – konfiguracja tenantu, synchronizacji, domen, polityk i konektorów. Pierwsza migracja obejmuje kontrolowaną grupę testową, najlepiej użytkowników z IT i reprezentantów kilku profili pracy.
- Migracja produkcyjna – jedno przełączenie albo kolejne partie, z weryfikacją poczty przychodzącej i wychodzącej, klientów, kalendarzy, delegacji i aplikacji na każdym etapie.
- Stabilizacja i zamknięcie – monitorowanie środowiska, rozwiązywanie zgłoszeń, porządkowanie DNS i bezpieczne wycofanie lokalnych elementów Exchange.
Na start potrzebujemy informacji o wersji Exchange, liczbie skrzynek, modelu Active Directory, folderach publicznych, archiwach oraz systemach korzystających z poczty. To wystarczy, żeby przygotować pierwszą rekomendację metody i zakres dalszej analizy.
Migracja Exchange powinna kończyć się docelowym modelem zarządzania, a nie tylko przeniesieniem danych.
Najczęstsze pytania (FAQ)
Techniczny limit to około 2000 skrzynek, ale Microsoft rekomenduje liczbę nieprzekraczającą około 150 – ze względu na możliwości pojedynczego zespołu wsparcia IT, czas tworzenia użytkowników i migracji danych. O wyborze metody powinny decydować również integracje, wolumen danych i możliwość obsługi użytkowników po przełączeniu.
Klasyczna metoda staged była przeznaczona dla Exchange 2003 i 2007. Microsoft wycofał onboarding Staged OutlookAnywhere w maju 2025 roku, dlatego w nowym projekcie trzeba potwierdzić inną wspieraną ścieżkę, najczęściej opartą na mechanizmach hybrydowych.
Hybrid pozwala migrować użytkowników etapami i zwykle ogranicza wpływ projektu na całą organizację, ale nie jest gwarancją braku problemów. Użytkownik może zostać poproszony o ponowne uruchomienie Outlooka, zalogowanie się lub odświeżenie konfiguracji po finalizacji przenoszenia skrzynki.
Nie. Mała liczba skrzynek nie oznacza automatycznie prostego środowiska. Przy wielu integracjach, dużych archiwach, rozbudowanym Active Directory albo potrzebie migracji etapowej wariant Express lub hybrid bywa bezpieczniejszy.
Nie zawsze. Najpierw trzeba ustalić, gdzie po migracji będzie źródło atrybutów Exchange i jak będą zarządzani użytkownicy synchronizowani z lokalnego AD. Microsoft udostępnia wspierane warianty zarządzania bez aktywnego serwera Exchange, ale wymagają one odpowiedniego przygotowania.
Podsumowanie
Wspólny mianownik jest jeden: migracja zaczyna się od assessmentu, nie od pierwszej partii. Wersja Exchange, model tożsamości, foldery publiczne, archiwa, integracje SMTP i plan wycofania lokalnego serwera – to elementy, które kształtują harmonogram i koszt bardziej niż sama liczba skrzynek. Projekt, który pomija te zależności na starcie, zwykle nadrabia je w trakcie – kosztem czasu, budżetu i cierpliwości użytkowników.
Planujesz migrację Exchange? Chętnie zaczniemy od przeglądu Twojego środowiska – wersji, skali, integracji i modelu tożsamości – żeby wskazać konkretną ścieżkę, a nie kolejną listę metod.
Chcesz najpierw zrozumieć swoje opcje po końcu wsparcia Exchange?
Napisz do nas – odpiszemy w ciągu dnia roboczego z pierwszą diagnozą i propozycją kolejnego kroku.
Poznaj nasze pozostałe usługi

Aplikacje biznesowe
Usługi dla aplikacji oraz gotowe rozwiązania w obszarze cyfryzacji procesów i nowoczesnego środowiska pracy.

Nowoczesne i kompleksowe wsparcie w obszarze cyberbezpieczeństwa dla Twojej firmy.
Cyberbezpieczeństwo

Pełne wsparcie i optymalizacja infrastruktury IT, zapewniające stabilny rozwój Twojego biznesu.
Infrastruktura IT

Bezpieczeństwo wdrożenia i utrzymania usług Microsoft 365 oraz Azure, które umożliwiają elastyczne zarządzanie i optymalizację kosztów.


