Decyzja o zmianie pakietu biurowego rzadko zapada w próżni. W firmach, które trafiają do nas z takim projektem, kierunek Google → Microsoft ma zwykle jeden z kilku konkretnych powodów: nowy właściciel standaryzuje grupę kapitałową na M365, kluczowy klient wymaga Exchange i Teams, rosną potrzeby w obszarze zarządzania urządzeniami, albo Google Workspace po prostu przestaje pokrywać realne zastosowania.

Rzadziej migracja zaczyna się od porównania cen. Oba pakiety są porównywalne kosztowo, a różnice widać dopiero po głębszym zanurzeniu: w integracji z Active Directory, w narzędziach do zarządzania laptopami (Intune), w pracy z dokumentami offline, w codziennej administracji.

Ten artykuł nie jest porównaniem obu platform. Tych w sieci są setki. Opisuje, jak wygląda sama migracja, gdzie są pułapki i co musisz zdecydować, zanim zaczniesz.

Co się właściwie migruje

Migracja z Google Workspace do Microsoft 365 to w praktyce kilka odrębnych procesów, każdy z własnym planem:

• Tożsamości użytkowników - konta stają się kontami Entra ID (dawne Azure AD). Jeśli firma ma lokalny Active Directory, dochodzi decyzja o synchronizacji przez Entra Connect.

• Poczta - skrzynki Gmail migrują do Exchange Online razem z folderami, etykietami i załącznikami.

• Pliki - Google Drive trafia do OneDrive (prywatne) i SharePoint (dyski zespołów). Dokumenty Google konwertują się do formatów Microsoftu.

• Kalendarze i kontakty - migrowane równolegle ze skrzynkami.

• Urządzenia mobilne i komputery - przepinane do Intune, niezależnie od migracji danych.

Każdy z tych elementów ma własne tempo, własne ograniczenia API po stronie Google i własne ryzyka.

Orientacyjne mapowanie usług wygląda następująco:

Kiedy nie migrować

Migracja z Google Workspace do Microsoft 365 nie zawsze jest dobrym pomysłem. W zapytaniach, które do nas trafiały, kilkakrotnie rekomendowaliśmy klientowi, żeby tego nie robił albo żeby odsunął projekt w czasie. Sytuacje, które każą się zatrzymać:

• Firma jest świeżo po dużej zmianie organizacyjnej - fuzja, wdrożenie nowego ERP, zmiana lokalizacji biura. Migracja pakietu biurowego zabiera znaczącą część uwagi zespołu przez kilka tygodni. Dokładanie tego do już zmęczonej organizacji kończy się opóźnieniami i frustracją.

• Kluczowe procesy są zbudowane na integracjach Google - Apps Script obsługuje workflow sprzedażowy, Google Sites jest wewnętrznym intranetem, Forms zbiera dane od klientów. Koszt odtworzenia tego po stronie Microsoftu potrafi przekroczyć oszczędności z migracji.

• Większość pracowników mocno preferuje Google Workspace - bez wsparcia zarządu i dobrej komunikacji nawet technicznie udana migracja kończy się rozproszonym powrotem do Google. Shadow IT, prywatne konta Gmaila używane służbowo, pliki wracające na Drive "bo tak wygodniej".

• Koszt licencji byłby znacząco wyższy - dla firm, które korzystają z Google Workspace Business Starter (6 USD za użytkownika miesięcznie), przejście na Microsoft 365 Business Standard oznacza około dwukrotnie wyższy koszt miesięczny przy porównywalnym zakresie.

Świadomie pomijam tu też temat migracji między tenantami Microsoft 365 (np. przy fuzji dwóch firm już korzystających z M365) - to zupełnie inna operacja, z własnymi wyzwaniami i narzędziami.

Decyzje do podjęcia przed rozpoczęciem migracji

Migracja jednoetapowa czy etapowa

W migracji jednoetapowej (tak zwany cut-over) wszystkich użytkowników przełącza się do nowego środowiska jednego dnia. Prostsze w realizacji, ale wymaga więcej planowania i dobrze działa głównie przy mniejszych organizacjach. W etapowej migruje się grupami - działami, lokalizacjami - z okresem koegzystencji obu systemów. Dla firm powyżej 30-40 osób jednoetapowa to zły pomysł.

Co z domeną podczas migracji

Domena główna (firma.pl) może być w danym momencie podpięta tylko do jednego systemu poczty. W okresie przejściowym używa się subdomeny tranzytowej (np. m365.firma.pl), żeby migrujący użytkownicy mogli pracować w nowym środowisku, zanim rekordy MX przełączą się ostatecznie.

Format dokumentów

Pliki Google Docs, Sheets i Slides konwertują się do Worda, Excela i PowerPointa - ale konwersja nigdy nie jest stuprocentowa. Formatowanie, funkcje niestandardowe i skrypty Apps Script potrafią się rozjechać. Proste dokumenty przechodzą bez problemu. Skomplikowane szablony ofertowe czy arkusze z formułami - przejrzyjcie i poprawcie ręcznie.

Dwa elementy Google Workspace wymagają osobnej decyzji. Google Drawings w trakcie migracji do OneDrive są konwertowane do plików .jpg i tracą edytowalność - jeśli firma ma w nich schematy czy diagramy organizacyjne, odtworzenie czeka w Visio albo PowerPoincie. Google Forms nie migrują się w ogóle, bo nie mają odpowiednika w ekosystemie Microsoftu. Dostępne wcześniej formularze odtworzycie w Microsoft Forms (dla prostych) albo w Power Apps (dla bardziej zaawansowanych).

Historia wersji i komentarze

Standardowe narzędzia migracyjne nie przenoszą historii wersji dokumentów ani komentarzy. Data utworzenia pliku zmienia się na datę migracji. Dla firm, które polegają na historii wersji w celach audytowych albo prawnych, to istotna informacja. Rozwiązanie: archiwizacja oryginałów w osobnej lokalizacji, przed migracją.

Uprawnienia do plików

Udostępnienia w Google Drive działają inaczej niż w SharePoint. W Drive panuje model udostępnień per plik lub per folder, często robiony ad hoc przez użytkowników ("udostępnij link każdemu, kto ma link") i rozchodzący się latami bez kontroli. SharePoint domyślnie dziedziczy uprawnienia z witryny lub biblioteki, a wyjątki konfiguruje się świadomie. Po migracji trzeba zweryfikować, kto do czego ma dostęp - zwłaszcza jeśli w Drive panował organiczny chaos z latami udostępnień "komu popadnie". Moim zdaniem to najlepszy moment na posprzątanie: nowy SharePoint z czystymi uprawnieniami jest łatwiejszy w zarządzaniu niż mechanicznie przepisany bałagan z Drive.

Licencje

Microsoft 365 Business dzieli się na trzy podstawowe plany dla firm do 300 użytkowników: Basic (tylko aplikacje webowe i mobilne, bez desktopowych Worda i Excela), Standard (pełne aplikacje desktopowe) i Premium (dodatkowo Intune do zarządzania urządzeniami, Defender, zaawansowana ochrona przed phishingiem, Azure Information Protection). Dla większych organizacji dostępne są plany Enterprise (E3, E5) z dodatkowymi funkcjami compliance i analitycznymi. Decyzja, kto dostaje który plan, wpływa nie tylko na budżet, ale też na to, co będzie dostępne po migracji. W praktyce większość firm potrzebuje mieszanki: Premium dla działów pracujących z danymi wrażliwymi i zarządu, Standard dla reszty, czasem Basic dla pracowników produkcyjnych czy magazynowych korzystających tylko z poczty. Zaplanujcie to przed migracją - zmiana planu w trakcie generuje dodatkową pracę administracyjną.

Co się nie zmigruje - lista elementów do osobnego planu

Standardowe narzędzia migracyjne nie przeniosą kilku elementów ekosystemu Google Workspace. Każdy z nich wymaga osobnej decyzji - odtworzyć w Microsoft 365, zarchiwizować po stronie źródła albo porzucić:

• Google Forms - brak odpowiednika po stronie migracji, odtworzenie ręczne w Microsoft Forms lub Power Apps

• Google Apps Script - brak migracji, przepisanie do Power Automate lub Office Scripts

• Google Drawings - konwertowane do .jpg, tracą edytowalność, rekonstrukcja w Visio lub PowerPoincie

• Historia wersji dokumentów - nie migruje się, oryginały archiwizujemy osobno

• Komentarze w dokumentach - nie migrują się

• Metadane plików - daty utworzenia zmieniają się na datę migracji, etykiety Gmaila mogą nie mapować się 1:1 na foldery Outlooka

• Uprawnienia do udostępnień zewnętrznych - linki typu "każdy z linkiem" nie przenoszą się, odtwarzamy ręcznie dla istotnych udostępnień

Metody migracji - jakim narzędziem przeprowadzić projekt

Wybór narzędzia zależy od skali i złożoności migracji. W praktyce rynek dzieli się na trzy kategorie:

• Natywny Microsoft Migration Manager - bezpłatne narzędzie w centrum administracyjnym M365. Radzi sobie z prostymi migracjami poczty i plików dla mniejszych zespołów, nie obsługuje bardziej zaawansowanego mapowania uprawnień ani migracji przyrostowych.

• Rozwiązania klasy enterprise - Quest On Demand Migration i AvePoint FLY to narzędzia profesjonalne, używane w projektach, gdzie wchodzą w grę: mapowanie struktur organizacyjnych, zachowanie zaawansowanych uprawnień, migracja etapowa z synchronizacją delta, przeniesienie Google Sites do SharePointa. W tej klasie kupuje się nie tyle narzędzie, co możliwość powtarzania migracji przyrostowo do momentu finalnego przełączenia.

• Migracja ręczna per użytkownik - każdy pracownik samodzielnie przenosi swoje dane: pocztę przez konfigurację obu kont w Outlooku lub Thunderbirdzie i przeciąganie folderów między skrzynkami IMAP, pliki przez pobranie lokalnie z Google Drive i wgranie do OneDrive, kalendarze przez eksport .ics, kontakty przez eksport CSV. Metoda bez kosztów licencyjnych, ale z realnym kosztem czasu pracowników - godziny, które każdy spędzi na przerzucaniu danych, zamiast na swojej pracy. Do tego wolna, wymaga zaangażowania każdego użytkownika, nie zachowuje metadanych (etykiet Gmaila, uprawnień do plików, dokładnych dat) ani współdzielonych zasobów. Przy większych skrzynkach wchodzą też limity IMAP po stronie Google.

Porównanie w skrócie:

Niezależnie od wybranej metody, przed właściwą migracją zróbcie pełne archiwum kont przez Google Takeout - jako zabezpieczenie oryginalnych danych na wypadek problemów w trakcie migracji albo sporów co do tego, co tam wcześniej było. To nie jest metoda migracji, ale dobra praktyka towarzysząca.

Dla większości firm z segmentu SMB sensownym wyborem są Quest albo AvePoint - ich koszt licencyjny w skali całego projektu jest niewielki w porównaniu z ryzykiem nieudanej migracji metodami darmowymi. Metoda ręczna ma sens tylko w mikrofirmach, gdzie każdy użytkownik i tak bezpośrednio zarządza swoimi danymi.

Etapy migracji krok po kroku

Ogólny szkielet projektu jest podobny niezależnie od wybranego narzędzia:

1. Inwentaryzacja - liczba użytkowników, rozmiary skrzynek, ilość danych w Drive, lista wykorzystywanych aplikacji (Meet, Groups, shared calendars), integracje z zewnętrznymi systemami korzystającymi z Google SSO.

2. Przygotowanie tenanta M365 - weryfikacja domeny, wstępna konfiguracja Entra ID, polityki haseł, MFA, podstawy DLP.

3. Migracja testowa - jedna lub kilka skrzynek pilotażowych. Ujawnia większość problemów, zanim dotkną cały zespół.

4. Komunikacja z użytkownikami - harmonogram, instrukcje, co się zmieni w codziennej pracy. Ten punkt w planach IT często ląduje na końcu listy, a w rzeczywistości decyduje o tym, czy migracja zostanie odebrana jako sukces.

5. Migracja właściwa - maile, pliki, kalendarze przenoszone wybranym narzędziem (patrz sekcja wyżej).

6. Przełączenie MX - moment, w którym nowa poczta zaczyna przychodzić do Exchange Online. Stare wiadomości doczytują się w tle.

7. Okres stabilizacji - 2-4 tygodnie, w których użytkownicy zgłaszają drobiazgi (zagubione udostępnienia, problemy z podpisami, konfiguracja w telefonach).

W jednym z naszych projektów - migracji z Dropboxa do SharePointa i OneDrive dla międzynarodowej organizacji zatrudniającej kilkadziesiąt osób, z biurami w kilku krajach europejskich - podzieliliśmy całość na pięć etapów, każdy startujący w piątek rano. Wybór piątku nie był przypadkowy: weekend dawał margines na reakcję, gdyby coś poszło nie tak. Po każdym etapie dostęp do Dropboxa w danym obszarze był odcinany dopiero po akceptacji grupy około 20 opiekunów migracji - osób z poszczególnych działów, które najlepiej znały zawartość swoich folderów. Wszystkie materiały komunikacyjne - instrukcje, ogłoszenia, tutoriale - przygotowaliśmy równolegle po polsku i angielsku. Osobnym, końcowym etapem było przeniesienie prywatnych zasobów pracowników z Dropboxa do ich indywidualnych OneDrive - na zgłoszenie chętnych.

Nie wszystko szło gładko. Pierwsze dwa etapy były trudniejsze niż zakładaliśmy - niedoszacowaliśmy czasu, którego opiekunowie migracji potrzebowali na weryfikację przeniesionych danych. Kilka razy ostatnia akceptacja przychodziła w niedzielę wieczorem, godzinę przed planowanym startem kolejnego etapu. Od trzeciego etapu wydłużyliśmy okno weryfikacji o dodatkowe 24 godziny - i reszta projektu przebiegła płynnie. Całość przesunęła harmonogram o kilka tygodni względem wersji "wszystko w weekend", ale zredukowała liczbę poważnych incydentów po migracji praktycznie do zera.

Ile trwa migracja Google Workspace do Microsoft 365

Orientacyjne ramy czasowe dla projektów, które prowadziliśmy:

• 20-30 użytkowników - 1-2 tygodnie od przygotowania tenanta do zamknięcia projektu, przy standardowych ilościach danych (kilkaset GB w Drive łącznie)

• 50-80 użytkowników - 2-4 tygodnie, z podziałem na 2-3 etapy migracji

• 100+ użytkowników - 4-8 tygodni, z migracją etapową podzieloną po działach lub lokalizacjach

Rzeczywisty czas zależy od ilości danych (terabajty w Drive znacząco wydłużają proces przez limity API Google), wybranego narzędzia (Migration Manager jest wolniejszy niż Quest czy AvePoint), złożoności integracji zewnętrznych (SSO, aplikacje branżowe) i dostępności osób po stronie klienta do weryfikacji etapów. W planowaniu budżetu zakładajcie górną granicę - nadmiar czasu można wykorzystać na konfigurację polityk Microsoft 365, niedomiar generuje stres i pośpieszne decyzje.

Pułapki, które trafiają się regularnie

Ta sekcja to destylacja kilku lat projektów. Lista nie jest kompletna - pomijam tu pułapki specyficzne dla konkretnych narzędzi migracyjnych albo konkretnych wersji Google Workspace. Zostawiam to, co w różnych projektach wracało najczęściej.

Limity API po stronie Google

Google nakłada ograniczenia na to, jak szybko można pobrać dane ze Workspace'a przez API. Dotyczy to zarówno liczby zapytań na sekundę, jak i dziennego limitu transferu per konto. Przy większych zasobach migracja nie jest kwestią "przeciągnięcia wszystkiego jednym kliknięciem" - to proces rozłożony na dni, czasem tygodnie. Narzędzia enterprise (Quest, AvePoint) radzą sobie z tym lepiej niż natywne - mają wbudowane mechanizmy retry, throttling i wznawiania migracji od momentu przerwania, więc nawet przy napotkaniu limitu Google proces ostatecznie się kończy. Przy planowaniu harmonogramu zakładajcie, że inicjalna migracja skrzynek 100+ osób z wieloletnią historią zajmie minimum 3-5 dni, plus kolejne dni na migracje delta synchronizujące zmiany z okresu przejściowego.

Wielkość załączników

Gmail domyślnie akceptuje załączniki do 25 MB, Exchange Online do 35 MB (administrator może podnieść do 150 MB). W większości przypadków nie ma problemu, ale przy nietypowych konfiguracjach limitów po stronie Gmaila pojedyncze wiadomości z dużymi plikami mogą się nie zmigrować. Narzędzia migracyjne raportują takie błędy - monitorujcie logi i przenoście brakujące maile ręcznie.

Skrzynki współdzielone i aliasy

Konto "biuro@" albo "sekretariat@", z którego korzysta kilka osób, odtwarza się jako shared mailbox w Exchange. Nie jest to trudne, ale łatwo pominąć przy inwentaryzacji. Pomijane zresztą bywa notorycznie. W Microsoft 365 skrzynki współdzielone do 50 GB nie wymagają osobnej licencji - wystarczy przypisać uprawnienia konkretnym użytkownikom. To znaczna przewaga nad Google Workspace, gdzie analogiczne konto konsumuje pełną licencję. Aliasy e-mail (dodatkowe adresy wskazujące na tę samą skrzynkę) przenosi się ręcznie - narzędzia migracyjne migrują same skrzynki, ale pomijają konfigurację aliasów i reguł przekierowań.

Delegacje kalendarzy i skrzynek

W Google Workspace asystentka często ma bezpośredni dostęp do kalendarza i skrzynki szefa przez natywne delegacje Google. W Microsoft 365 to działa inaczej - uprawnienia do kalendarza konfiguruje się przez role (Reviewer, Editor, Delegate), a do skrzynki przez Full Access z opcją Automapping. Po migracji sprawdźcie, czy wszystkie takie relacje zostały odtworzone - standardowo narzędzia migracyjne tego nie robią.

Zduplikowane nazwy plików

Google Drive identyfikuje pliki po wewnętrznym ID, więc w jednym folderze może być pięć plików o nazwie umowa.docx. SharePoint wymaga unikalnych nazw w obrębie folderu - migrator dokleja sufiksy typu (1), (2). Efekt: po migracji pojawiają się pliki o dziwnych końcówkach, a użytkownicy nie wiedzą, który jest właściwy. Przejrzyjcie Drive przed migracją i posprzątajcie duplikaty po stronie źródła - oszczędzicie sobie tłumaczenia tego pracownikom.

Limit 100 000 elementów w bibliotece SharePoint

SharePoint ma twardy limit dla pojedynczej biblioteki dokumentów - 5 000 elementów na widok i 100 000 elementów w całej bibliotece bez utraty wydajności. Duże foldery projektowe z Google Drive (archiwa projektów, stare zasoby marketingowe, skany dokumentów) potrafią ten limit przekraczać. Rozwiązanie: zamiast przenosić wszystko do jednej biblioteki, tworzy się kilka osobnych bibliotek w ramach jednej witryny SharePoint. Przewidzieć to trzeba na etapie planowania - narzędzia migracyjne same tego nie zrobią.

Limit przestrzeni dyskowej w tenancie

Przestrzeń SharePoint/OneDrive w Microsoft 365 naliczana jest globalnie na tenant, z bazowym 1 TB plus 10 GB na każdą płatną licencję. W migracjach większych zbiorów (kilka TB) zdarza się, że ta pula się kończy w połowie procesu. Dokupienie dodatkowych pakietów przestrzeni jest natychmiastowe, ale lepiej oszacować potrzebę wcześniej, niż reagować w trybie ratunkowym.

Automatyzacje w Google Apps Script

Nie ma tu dobrej drogi. Każda z opcji coś kosztuje - albo czas przepisania, albo ciągły maintenance dwóch światów. Skrypty na Drive, w arkuszach, w formularzach nie przeniosą się - Apps Script jest platformą natywną dla Google Workspace i nie ma bezpośredniego odpowiednika w ekosystemie Microsoftu. Dla każdego skryptu cztery opcje: przepisać do Power Automate (wizualny odpowiednik z ponad 500 gotowymi łącznikami, często wystarczający dla typowych automatyzacji w rodzaju "wyślij maila gdy pojawi się nowy wiersz"), przepisać do Office Scripts (TypeScript działający w Excelu, najbliższy Apps Script funkcjonalnie), zostawić w Google i utrzymywać dwa światy (dla skryptów o krytycznym znaczeniu biznesowym, których przepisanie jest ryzykowne), albo zrezygnować (dla skryptów, które powstały ad hoc, a nikt już nie pamięta po co). Przy okazji migracji zrób inwentaryzację - często okazuje się, że 80% skryptów można wyłączyć bez żalu.

Integracje SSO z zewnętrznymi aplikacjami

Jeśli firma używa Google jako dostawcy tożsamości dla innych systemów (CRM, narzędzia HR, Slack, narzędzia projektowe, aplikacje księgowe), każdy z tych systemów wymaga osobnego przepięcia na Entra ID. Większość popularnych aplikacji SaaS wspiera oba standardy (SAML 2.0 i OIDC), więc od strony technicznej to podmiana jednej konfiguracji. W praktyce trzeba to skoordynować z dostawcami poszczególnych systemów, zaplanować okno przełączenia i przetestować logowanie użytkowników. Dla 5-10 aplikacji SaaS to kilka dni pracy rozłożonej w czasie. Zinwentaryzujcie integracje przed migracją - nagłe utracenie dostępu do kluczowego systemu biznesowego robi większy szum niż problemy z pocztą.

Backup po obu stronach

W Google Workspace i Microsoft 365 obowiązuje ten sam model - producent odpowiada za dostępność usługi, nie za przywracanie Twoich danych po przypadkowym skasowaniu czy ataku ransomware. Migracja to dobry moment, żeby poukładać to od razu w nowym środowisku.

Co po migracji

Kończy się migracja - zaczyna się administracja. Microsoft 365 daje dużo więcej narzędzi niż Google Workspace, ale to oznacza też więcej decyzji do podjęcia: polityki w Intune, reguły warunkowego dostępu, Defender, etykiety wrażliwości, polityki retencji. Firma, która przez lata korzystała z prostego Workspace'a, nie skonfiguruje tego w dwa popołudnia.

W projektach, które prowadzimy, sama migracja to 30-40% pracy. Reszta to uporządkowanie środowiska po stronie Microsoftu tak, żeby firma faktycznie korzystała z tego, za co płaci. Inaczej to tylko "Gmail, który teraz nazywa się Outlook".

Najczęściej zadawane pytania

Czy Google Forms migrują się automatycznie?

Nie. Google Forms nie mają odpowiednika po stronie narzędzi migracyjnych - żadne z nich ich nie przenosi. Aktywne formularze odtwarza się ręcznie w Microsoft Forms (dla prostych ankiet i zgłoszeń) lub w Power Apps (dla formularzy z logiką warunkową i integracjami). Wcześniej zinwentaryzujcie, które formularze są rzeczywiście w użyciu - część okazuje się zapomniana i można je po prostu wyłączyć.

Czy użytkownicy mogą pracować w trakcie migracji?

Tak. W migracji etapowej każda grupa pracowników pracuje normalnie w Google Workspace do dnia, w którym ich dane zostaną przełączone. W migracji jednoetapowej przełączenie odbywa się w weekend, więc poniedziałek zaczyna się już w Microsoft 365. Typowa strata produktywności to kilka godzin w dniu przełączenia - konfiguracja skrzynki w Outlooku, zapoznanie z nowym interfejsem.

Czy potrzebny jest przestój w pracy firmy?

Przy dobrze zaplanowanej migracji - nie. Dane migrują się w tle przed przełączeniem, rekordy MX (poczta) przepinają się w weekend lub poza godzinami pracy. Użytkownicy zauważają zmianę dopiero po rozpoczęciu pracy w nowym środowisku.

Ile kosztuje migracja Google Workspace do Microsoft 365?

Koszt ma trzy składowe. Licencje Microsoft 365 - zaczynają się od około 25 zł za użytkownika miesięcznie (Business Basic) do kilkuset złotych za Enterprise E5. Narzędzie migracyjne - Microsoft Migration Manager jest bezpłatny, Quest On Demand Migration i AvePoint FLY to licencje projektowe od kilkuset do kilku tysięcy euro w zależności od skali. Praca wykonawcza - kilkadziesiąt do kilkuset roboczogodzin w zależności od rozmiaru organizacji. W modelu Helpwise IT sama migracja jest wliczona w umowę stałej współpracy.

Czy można wrócić do Google Workspace po migracji?

Technicznie tak, ale praktycznie jest to trudniejsze niż migracja w drugą stronę i wymaga drugiego takiego samego projektu. Upewnijcie się przed migracją, czy to właściwy kierunek, a oryginalne dane z Google Workspace zarchiwizujcie przez Takeout i trzymajcie co najmniej kilka miesięcy po zakończeniu migracji.

Czy historia wersji dokumentów Google zostanie zachowana?

Nie - standardowe narzędzia migracyjne nie przenoszą historii wersji ani komentarzy. Data utworzenia pliku zmienia się na datę migracji. Dla firm, które polegają na historii wersji w celach audytowych lub prawnych, rozwiązaniem jest zarchiwizowanie oryginalnych dokumentów przed migracją w osobnej lokalizacji. W Microsoft 365 historia wersji zaczyna budować się od nowa od momentu migracji.

Prowadzimy migracje Google Workspace → Microsoft 365 w ramach stałej współpracy z firmami w Warszawie i okolicach. Samo wdrożenie jest wliczone w umowę - płacisz za licencje, nie za roboczogodziny naszego zespołu. Jeśli rozważasz taki projekt u siebie, odezwij się - zaczniemy od rozmowy o tym, czy migracja faktycznie ma sens.