W co drugiej firmie, do której wchodzimy, w jakiejś szafie stoi serwer plików — najczęściej z mapą dysków „Z:\\\\firma" i historią folderową, którą pamiętają wyłącznie dwie osoby. Decyzja o przeniesieniu tego do SharePointa i OneDrive zwykle nie jest pytaniem „czy", tylko „jak to zrobić bez przestoju i bez utraty uprawnień, które się tam narastały przez dziesięć lat".
W tym roku robiliśmy taką migrację u 24-osobowej firmy konsultingowej z branży audytorskiej. Stary serwer plików (Windows Server 2019, dwa dyski RAID 1, 920 GB danych) stał w serwerowni razem z UPS-em, którego baterie skończyły żywot dwa lata temu. Backup był robiony „na drugi dysk w tym samym pudle". Mieli 12 800 folderów, 412 000 plików, średnio 6 lat dane, w tym sporo PDF-ów ze skanów po 15 MB każdy. Po migracji do SharePoint Online (na licencjach Microsoft 365 Business Standard, które już mieli) i OneDrive zostali z trzema bibliotekami zespołowymi, jasnym podziałem na „moje" i „nasze", a roczne koszty utrzymania spadły o około 11 tys. zł (prąd, serwis, licencja Windows Server, backup off-site). Cała migracja: 5 tygodni kalendarzowych, z czego sam cutover „od dziś pracujemy z SharePointa" trwał jeden weekend. Liczba utraconych plików: zero. Liczba osób, które w pierwszym tygodniu nie mogły otworzyć jakiegoś folderu: cztery — i każde z tych zgłoszeń rozwiązaliśmy w ciągu godziny.
Poniżej szkielet, jak się to robi.
Co naprawdę jest na Twoim dysku sieciowym
Pierwsza prawda: nikt w firmie nie wie. Drugi tydzień projektu to wyłącznie inwentaryzacja, bez tknięcia jednego pliku. Bez tego dalej idziesz w ciemno.
- Rozmiar i typy plików. Posortuj foldery po rozmiarze. U naszego klienta z 920 GB całości, 320 GB to były archiwa zip starszych projektów, do których nikt nie zaglądał od 2019 roku. Te trafiły do archiwum offline, nie na SharePointa. Płaci się za megabajt razy lata.
- Pliki większe niż 250 MB. SharePoint sobie z nimi radzi, ale klient synchronizacyjny zaczyna kichać przy katalogach pełnych takich plików. Wideo, duże CAD-y, obrazy ISO, dumpy baz — to nie jest miejsce dla SharePointa, tylko dla Azure Files albo wciąż lokalnego storage.
- Pliki otwierane częściej niż raz w miesiącu. Najprostszy sposób: skrypt w PowerShellu, który listuje
LastAccessTime. U naszego klienta okazało się, że aktywnie używanych jest 18% danych. Reszta to historia, która nie potrzebuje synchronizacji do każdego laptopa. - Ścieżki dłuższe niż 400 znaków. SharePoint ma twardy limit 400 znaków na pełną ścieżkę URL. Foldery typu
Klienci\\2018\\ABC sp. z o.o.\\dokumentacja techniczna\\rewizja_3_po_uwagach_klienta\\...to jest dokładnie ta sytuacja, w której Migration Tool pokazuje czerwone okienko o czwartej rano. - Uprawnienia NTFS na serwerze. To jest osobny smutek. Wyciągnij raport (
icacls, AccessEnum albo skrypt PowerShellowy), zanim cokolwiek tkniesz. W praktyce u 25-osobowej firmy wychodzi 80–200 unikalnych konfiguracji uprawnień. Wiele z nich da się skonsolidować — i to jest dobry moment, żeby to zrobić, bo SharePoint i tak nie lubi modeli „uprawnienie per plik".
Ten etap nie jest spektakularny, ale właśnie tu odsiewasz 60% problemów.
SharePoint, OneDrive czy Teams — co gdzie ląduje
Najczęstszy błąd: wszystko wrzucić w jedną wielką bibliotekę SharePointa i mieć z głowy. Po pół roku okazuje się, że nikt nic nie znajduje, bo struktura folderowa z 2010 roku nie pasuje do współpracy w 2026.
Zasada, która się sprawdza w MŚP:
- OneDrive — to są moje robocze pliki. Wersje drafty, notatki, materiały, których nie muszę z nikim współdzielić. Każdy pracownik z M365 Business dostaje 1 TB, w praktyce wystarczy na lata.
- SharePoint (biblioteki w site'ach zespołowych) — to są pliki działu albo projektu. „Wszyscy z księgowości", „zespół projektu X", „dokumenty zarządcze". Tu się dzieje współpraca.
- Teams files — to nie jest osobne miejsce. Teams pod spodem trzyma pliki w SharePoincie. Jeśli ktoś Ci sprzedaje „migrację do Teamsa" jako alternatywę do SharePointa — to jest sprzedawca, nie architekt.
W praktyce dla 24-osobowej firmy wyszło nam: jedna główna witryna firmowa, cztery witryny działowe (księgowość, sprzedaż, projekty, HR), w każdej 2–4 biblioteki. Razem ~16 bibliotek zamiast 12 800 folderów na jednym dysku. To jest moment „upraszczamy", a nie „kopiujemy 1:1".
Plan migracji bez tygodnia przestoju
Microsoft daje Ci SharePoint Migration Tool (SPMT) i Migration Manager w Admin Center. Oba są darmowe, oba działają. Dla typowej 25-osobowej firmy SPMT wystarczy.
Schemat, który zawsze proponujemy:
- Migracja na sucho (dry run) na podzbiorze 50–100 GB. Sprawdzasz, co Migration Tool oflaguje czerwono: za długie ścieżki, niedozwolone znaki w nazwach (
#,%,*w starszych nazwach plików), pliki zerobajtowe, czy puste foldery. Poprawiasz na źródle (zmiana nazw, skrócenie ścieżek), bo SharePoint po prostu pominie je w finale. - Migracja danych historycznych w tle, przez 5–10 dni. Ludzie cały czas pracują na starym serwerze. Migration Tool kopiuje to, co się nie zmienia (archiwa, projekty zamknięte). To 80% objętości i 20% ryzyka.
- Cutover weekend. W piątek o 18:00 zamykasz zapis na starym serwerze (read-only przez NTFS). Sobota — delta sync, czyli dosłanie wszystkiego, co się zmieniło w ostatnim tygodniu. Niedziela — testy, weryfikacja kilkudziesięciu losowych folderów, mapowanie nowych skrótów na pulpitach.
- Poniedziałek rano — wszyscy mają na pulpicie skrót do SharePointa zamiast „Z:\\\\firma". Stary serwer zostaje włączony jeszcze przez 30 dni w trybie read-only, jako koło ratunkowe. Nikt tam nic nowego nie napisze, ale jak ktoś szuka „tej wersji z lutego", to jest gdzie sięgnąć.
Najczęstszy błąd na tym etapie: ktoś próbuje robić cutover w środku tygodnia roboczego, „bo szef nie chce płacić nadgodzin za sobotę". Po jednym takim podejściu już się tego nie powtarza.
Czego NIE przenosić do SharePointa
SharePoint jest świetny do plików biurowych. Jest zły do kilku konkretnych rzeczy i lepiej powiedzieć to wprost.
- Bazy danych aplikacji. Microsoft Access
.mdb, SQLite, jakiekolwiek pliki, które aplikacja trzyma otwarte cały czas. Klient synchronizacyjny OneDrive ich nie ogarnia, robi konflikty co 5 minut. To trzyma się w SQL Serverze albo w Azure Files. - Foldery z setkami tysięcy małych plików. Cache aplikacji, eksporty logów, pliki tymczasowe. SharePoint ma limit 30 milionów elementów w bibliotece, ale klient synchronizacyjny zaczyna padać znacznie wcześniej. Te trzymaj lokalnie albo w storage object.
- Pliki CAD i wideo powyżej 1 GB. Technicznie się zmieszczą, ale realnie — biuro projektowe pracujące na DWG-ach 500 MB każdy będzie mieć synchronizację stojącą cały dzień. Dla takich rzeczy istnieje Azure Files z mapowaniem dysku albo dedykowany NAS w biurze.
- Pliki, które muszą być open 24/7 przez wielu użytkowników jednocześnie. Excel jako system — to jest osobny temat (mamy o tym osobny post), ale jeśli macie taki plik, na SharePoincie zacznie się rzeźnia konfliktów wersji. Najpierw rozwiążcie problem aplikacyjny, potem migrujcie.
To jest jedna z trzech rozmów, które warto przeprowadzić zanim się ruszy migrację. Drugą jest model uprawnień. Trzecią — kto kasuje plik, kiedy ktoś odchodzi z firmy.
Co dalej
Migracja dysku sieciowego do SharePointa w 25-osobowej firmie to projekt na 4–6 tygodni, nie na weekend. Większość tego czasu to nudna robota: inwentaryzacja, czyszczenie nazw plików, konsolidacja uprawnień, dogadanie się, gdzie kończy się „moje" a zaczyna „nasze". Sama migracja techniczna to ostatnie 20%.
Wartością nie jest „mamy w chmurze". Wartością jest to, że po migracji nikt już nie pyta „gdzie jest plik X" — bo struktura jest płaska, wyszukiwanie działa, a dostęp z telefonu nie wymaga VPN-a. Plus odpada serwer w piwnicy z baterią UPS-a, której nikt nie wymienia.
Jeśli masz w firmie stary serwer plików, a licencje Microsoft 365 już płacisz — pogadajmy, zanim ktoś sprzeda Ci „migrację w weekend". Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Migracja do SharePointa to nie jest kopiowanie folderu 1:1. To jest moment, w którym uczciwie się przyznajesz, że 60% tego, co masz na dysku, nie powinno tam być już od pięciu lat.