Dlaczego migracja Google Workspace to złożona transformacja IT

Autor artykułu:

Piotr Ziemkiewicz
Cloud Delivery Manager, PwC Polska

Migracja, separacja lub konsolidacja platform współpracy w chmurze stają się jednym z najczęstszych elementów transformacji cyfrowych.

Szczególnie w kontekście fuzji i przejęć, carve‑outów oraz skalowania szybko rosnących organizacji technologicznych.

Na pierwszy rzut oka przeniesienie organizacji do innego tenanta Google Workspace wygląda jak projekt czysto techniczny: zmiana domen, aktualizacja rekordów DNS, odtworzenie użytkowników i grup, skopiowanie danych.

W praktyce – zwłaszcza w globalnych firmach operujących w modelu 24/7 – migracja produkcyjnego Google Workspace okazuje się jedną z najbardziej wymagających transformacji IT. Dotyka bowiem nie tylko poczty i plików, ale kręgosłupa całej organizacji: tożsamości, bezpieczeństwa, procesów operacyjnych, integracji oraz całego doświadczenia użytkownika.

Na podstawie zrealizowanych projektów migracji i separacji tenantów Google Workspace podsumowujemy najważniejsze obserwacje – z perspektywy CIO, CTO, CISO i liderów transformacji.

To nigdy nie jest „tylko projekt techniczny”

Migracja Google Workspace wymaga silnego zespołu technicznego: administratorów Workspace, specjalistów ds. bezpieczeństwa, architektów chmurowych, ekspertów od tożsamości, którzy potrafią wykorzystać API, Google Workspace CLI czy nowoczesne narzędzia automatyzacji i Agentów AI (np. Model Context Protocol Server).

To właśnie zespół techniczny odpowiada za wybór narzędzi migracyjnych (tych oferowanych natywnie przez Google lub zewnętrznych), konfigurację tenanta, domen, aspektów bezpieczeństwa, Gmaila, dysku, kalendarza czy grup.

Jednak technologia to tylko połowa sukcesu.

Druga połowa to… organizacja:

Zarządzanie zmianą

jak zmieni się codzienna praca użytkowników,
co dokładnie wydarzy się w dniu „cutoveru”,
jak ograniczyć chaos operacyjny oraz jak nim zarządzić.

Komunikacja

czy pracownicy rozumieją, dlaczego zmiana jest wprowadzana,
czy wiedzą, co mają zrobić przed i po migracji,
czy otrzymują proste instrukcje zamiast długich, ignorowanych komunikatów.

Procesy biznesowe

jak obsługiwane są skrzynki wspólne,
kto odpowiada za rezerwację sal,
jakie zespoły są ze sobą zależne i kiedy.

Jeśli te aspekty nie zostaną zaplanowane od pierwszego dnia, problemy pojawią się zwykle tuż przed kluczowym przełączeniem – w momencie największego ryzyka i najmniejszej elastyczności.

Google Workspace to nie tylko Gmail i Drive – to „backbone” organizacji

W większości firm Workspace stanowi końcowy element łańcucha tożsamości, obejmującego:

To właśnie tu ostatecznie materializują się:

Migracja oznacza więc nie tylko „przeniesienie danych”, ale również:

HR (źródło danych o pracownikach),
IdP (Okta, Entra ID lub inne),
SCIM (provisioning do aplikacji SaaS),
Workspace (użytkownicy, grupy, jednostki org.).

struktura organizacyjna,
polityki bezpieczeństwa (DLP, hasła, urządzenia),
uprawnienia do plików, kalendarzy, sal i przestrzeni współdzielonych.

przeprojektowanie IdP pod nowe domeny i nowy tenant,
dostosowanie procesów HR (joiner/mover/leaver) do nowego środowiska,
zaplanowanie, kto pracuje w starym, kto w nowym, a kto chwilowo w modelu „dual user”
zdefiniowanie polityk SSO, MFA i kontroli urządzeń od nowa.

Bez szczegółowego, etapowego scenariusza przełączenia tożsamości łatwo doprowadzić do sytuacji, w której jedna zmiana pozbawi użytkowników dostępu nie tylko do Google, ale też do aplikacji biznesowych zależnych od Workspace jako IdP.

Integracje z Google Workspace psują się „po cichu”

Workspace nie działa w izolacji. To element większego ekosystemu chmurowego, a konta Google oraz grupy są wykorzystywane m.in. do:

nadawania uprawnień w Google Cloud,
integracji z narzędziami developerskimi (np. repozytoria kodu),
automatyzacji procesów (np. platformy typu no‑code/low‑code),
integracji z innymi platformami współpracy (np. Slack i inne komunikatory),
dostępu do aplikacji wewnętrznych, które korzystają z uwierzytelniania Google.

Przykładowo, w Google Cloud dostęp do projektów i zasobów jest ściśle powiązany z tożsamościami Google w usłudze Cloud Identity. Migracja użytkowników do nowego tenanta Workspace bez równoległego planu dla GCP oznacza, że:

użytkownicy mogą nagle stracić dostęp do projektów, którymi zarządzają,
automatyczne procesy (np. pipeline’y CI/CD) przestaną działać, bo zweryfikowane konta lub grupy nie będą już istnieć w pierwotnej formie.

To samo dotyczy wielu innych integracji – część z nich jest dobrze udokumentowana, część „żyje” jedynie w głowach zespołów, które je kiedyś skonfigurowały.

Dlatego kluczowe przed migracją są:

Audyt integracji – zarówno automatyczny (na ile pozwalają narzędzia i API), jak i oparty na warsztatach z kluczowymi zespołami.
Priorytetyzacja – określenie, które integracje są krytyczne dla działania biznesu, a które mogą zostać na chwilę wyłączone lub odbudowane już po migracji.
Model docelowy – podjęcie decyzji, czy przenosimy integracje „as is”, upraszczamy je, czy przy okazji migracji porządkujemy krajobraz narzędzi.

Im więcej zostanie wykryte przed „dniem zero”, tym mniej gaszenia pożarów po przełączeniu.

Komunikacja i hypercare są tak samo ważne jak skrypty migracyjne

Dla użytkownika najważniejsze jest jedno: Czy jutro mogę normalnie pracować?

Nie interesuje go:
Interesuje go:

Nie interesuje go:

rekordy MX,
przepływy IdP,
konfiguracja domen.

Interesuje go:

czy ma dostęp do swojej skrzynki i wszystkich ważnych aliasów,
czy ważne maile i pliki nie zaginęły w trakcie tej zmiany,
czy widzi kalendarze współdzielone,
czy może rezerwować zasoby,
czy ma dostęp do niezbędnych folderów i dokumentów,
czy narzędzia „działają tak jak wcześniej”.

Z drugiej strony, większość użytkowników:

nie czyta długich komunikatów e‑mail,
nie zapamięta wszystkich szczegółów, nawet jeśli zostały dobrze opisane.

Dlatego skuteczne projekty migracji Google Workspace budują komunikację jako osobny strumień prac, który obejmuje:

jasne, powtarzane komunikaty od sponsorów biznesowych – dlaczego to robimy i czego się spodziewać,
krótkie, konkretne instrukcje dla użytkowników – co się zmieni, kiedy i co mają zrobić przed/po migracji,
materiały dla „kluczowych grup” – zespołów obsługi klienta, sprzedaży, operacji czy zarządu,
dobrze zorganizowany okres hypercare – ze wzmocnionym wsparciem Service Desku, jasno opisanymi ścieżkami eskalacji i szybką możliwością reagowania na problemy.

Brak dobrej komunikacji oraz hypercare’u nie zatrzyma migracji technicznej, ale może sparaliżować pracę organizacji następnego dnia.

Jak przygotować organizację do migracji, separacji lub konsolidacji Workspace

1. Myśl o projekcie jak o transformacji organizacyjnej, nie technicznej.
2. Rozpocznij od tożsamości i HR.
3. Wykonaj audyt integracji i krytycznych zależności.
4. Zaprojektuj model koegzystencji.
5. Zapewnij budżet i czas na hypercare.
6. Korzystaj z doświadczeń partnerów.

1. Myśl o projekcie jak o transformacji organizacyjnej, nie technicznej.

Włącz do planowania nie tylko zespoły techniczne, ale także HR, bezpieczeństwo, właścicieli kluczowych procesów i przedstawicieli biznesu.

2. Rozpocznij od tożsamości i HR.

Zmapuj powiązania między Google Workspace, IdP i systemem HR. Zrozum, które procesy „joiner/mover/leaver” będą musiały się zmienić i kiedy.

3. Wykonaj audyt integracji i krytycznych zależności.

Połącz automatyczne narzędzia z rozmowami z zespołami. Zidentyfikuj, co jest ważne dla działania biznesu, a co można zmigrować lub przebudować później.

4. Zaprojektuj model koegzystencji.

Zdecyduj, czy i przez jak długo środowiska będą funkcjonować równolegle, jakie będą zasady udostępniania danych i obsługi poczty między tenantami.

5. Zapewnij budżet i czas na hypercare.

Załóż, że mimo najlepszego planu część problemów ujawni się dopiero po migracji. Kluczowe jest, aby organizacja była na to gotowa – procesowo i zasobowo.

6. Korzystaj z doświadczeń partnerów.

Organizacje rzadko realizują duże migracje. Z kolei dostawcy rozwiązań i partnerzy, którzy prowadzili wiele takich projektów, pomagają ominąć typowe pułapki już na etapie planowania.