Migracja lokalnego SQL Servera do Azure SQL Database to proces przeniesienia baz danych, schematów i obciążeń z własnej infrastruktury (on-premise) do w pełni zarządzanej platformy PaaS w chmurze Microsoft Azure. Jeśli planujesz taką migrację, ten artykuł dostarczy Ci aktualną wiedzę na 2026 rok — od oceny gotowości, przez wybór narzędzi, aż po samą realizację i optymalizację po migracji.
W skrócie
- Główne narzędzia Microsoftu w 2026 r.: Azure Migrate (ocena), Azure Database Migration Service (DMS — migracja online/offline), Azure Data Studio + rozszerzenie migracyjne, SQLPackage (BACPAC), replikacja transakcyjna.
- Migrację można przeprowadzić offline (baza niedostępna podczas kopiowania) lub online (minimalny przestój — dane synchronizują się na bieżąco z azurem).
- Azure Hybrid Benefit pozwala wykorzystać istniejące licencje SQL Server z Software Assurance i obniżyć koszt vCore w Azure SQL nawet o 30–50%.
- Azure SQL Database nie obsługuje m.in. Windows Authentication (trzeba przejść na Microsoft Entra ID), SQL Agent Jobs (zastępują je Elastic Jobs), FileStream, cross-instance transactions.
- Dla najbardziej wymagających scenariuszy, gdzie potrzeba dostępu do systemu operacyjnego lub funkcji na poziomie instancji, Microsoft rekomenduje Azure SQL Managed Instance lub SQL Server na maszynie wirtualnej Azure.
Dlaczego warto migrować SQL Server do Azure SQL Database
Azure SQL Database eliminuje konieczność zarządzania sprzętem, łatek, backupów i wysokiej dostępności — wszystko to zapewnia platforma. Wbudowana architektura high availability (SLA 99,995% w warstwie Business Critical), automatyczne aktualizacje, skalowalność w górę i w dół bez przestoju oraz natywna integracja z ekosystemem Azure (Power BI, Microsoft Entra ID, Azure Monitor) to główne argumenty za migracją.
Dodatkowo Microsoft od 2025 roku systematycznie wygasza wsparcie dla narzędzi legacy — Data Migration Assistant (DMA) został wycofany z głównego nurtu, a jego funkcje przejęły Azure Migrate oraz rozszerzenie migracyjne do Azure Data Studio. DMS w wersji "classic" wciąż działa, ale Microsoft promuje nowe wdrożenie Azure Database Migration Service dostępne z poziomu Azure Portal, które jest szybsze i lepiej zintegrowane z chmurą.
Wybór celu migracji — które Azure SQL wybrać
Wybór odpowiedniego środowiska docelowego to pierwszy krytyczny krok:
| Środowisko docelowe | Kiedy wybrać | Przykładowy scenariusz |
|---|---|---|
| Azure SQL Database (pojedyncza baza) | Nowoczesne aplikacje chmurowe, mikroserwisy, aplikacje webowe bez zależności na poziomie instancji SQL Server | Aplikacja e-commerce, SaaS |
| Azure SQL Database (elastyczna pula) | Wiele mniejszych baz danych o zmiennym obciążeniu, które mogą współdzielić zasoby | Aplikacja wielodzierżawcza z osobnymi bazami na klienta |
| Azure SQL Managed Instance | Potrzebujesz funkcji na poziomie instancji (SQL Agent, Service Broker, CLR, cross-database queries) | Migracja rozbudowanego ERP/CRM z minimalnymi zmianami |
| SQL Server na maszynie wirtualnej Azure (IaaS) | Pełna kontrola nad OS, potrzeba instalacji niestandardowych agentów, specyficzne wymagania compliance | Legacy aplikacja z zależnościami od systemu plików (FileTable, PolyBase) |
Modele zakupowe i warstwy usług w pigułce
Azure SQL Database oferuje trzy modele zakupowe:
- vCore — wybierasz liczbę rdzeni i pamięć. Jedyna opcja kompatybilna z Azure Hybrid Benefit (przeniesienie licencji on-premise). Najłatwiejsze mapowanie z fizycznego/wirtualnego SQL Servera.
- DTU — predefiniowane pakiety mocy obliczeniowej, pamięci i I/O. Prostszy model, ale mniej elastyczny przy dużych obciążeniach.
- Serverless (bezserwerowy) — automatyczne skalowanie, baza wstrzymywana przy braku ruchu. Idealny dla obciążeń o zmiennym natężeniu i deweloperskich środowisk testowych.
Do wyboru masz trzy warstwy usług:
| Warstwa | Przeznaczenie | Log rate (max) |
|---|---|---|
| General Purpose | Większość obciążeń produkcyjnych, aplikacje biznesowe | ~50 MB/s |
| Business Critical | Aplikacje o wysokiej liczbie transakcji i niskim opóźnieniu I/O, read scale-out | 96 MB/s |
| Hyperscale | Bardzo duże bazy danych (do 100 TB), szybkie backup/restore, log rate niezależny od warstwy | 100 MB/s |
⚠ Podczas migracji zwiększ warstwę/docelowy rozmiar bazy (scale-up), aby zmaksymalizować szybkość transferu logów (do 96–100 MB/s). Po migracji możesz skalować w dół, oszczędzając koszty.
Narzędzia migracji — co działa w 2026 roku
Microsoft oferuje kilka sprawdzonych ścieżek migracji. Oto zestawienie:
1. Azure Migrate — ocena i planowanie
Zanim cokolwiek przeniesiesz, uruchom Azure Migrate — odkrywa instancje SQL Server w Twoim środowisku, analizuje wydajność i generuje:
- raport gotowości do migracji (które bazy są kompatybilne),
- rekomendowany rozmiar docelowy (SKU — liczba vCore, warstwa),
- szacunkowy miesięczny koszt w Azure.
Azure Migrate działa na dużą skalę — obsługuje setki serwerów jednocześnie na VMware, Hyper-V i bare-metal.
2. Azure Database Migration Service (DMS) — migracja właściwa
To w pełni zarządzana usługa Azure. W 2026 roku nowa wersja DMS (dostępna przez Azure Portal) obsługuje migracje:
- Offline — prostsza: zatrzymujesz ruch na źródle, DMS kopiuje dane, po zakończeniu przełączasz aplikację na nowy endpoint.
- Online — dla krytycznych systemów: DMS replikuje zmiany na bieżąco z SQL Servera do Azure SQL, a na koniec wykonujesz cutover z minimalnym przestojem (często kilkuminutowym).
DMS automatyzuje migrację schematów, ale loginy musisz odtworzyć ręcznie lub za pomocą dedykowanego skryptu PowerShell.
3. Azure Data Studio + rozszerzenie migracyjne
Lekkie IDE do pracy z SQL — po zainstalowaniu rozszerzenia Azure SQL Migration dostajesz kreator krok po kroku do przenoszenia baz. Dobry wybór dla mniejszych migracji (1–5 baz), gdy nie potrzebujesz ciężkiej infrastruktury DMS.
4. Metody alternatywne (sprawdzone dla mniejszych baz)
| Metoda | Dla kogo | Uwagi |
|---|---|---|
| BACPAC (Export/Import, SqlPackage.exe) | Pojedyncze bazy do ~50 GB | Wymaga przestoju na czas eksportu i importu |
| bcp (Bulk Copy Program) | Częściowa migracja wybranych tabel | Drobiazgowa kontrola, ale ręczna konfiguracja |
| Replikacja transakcyjna | Migracja online z SQL Server 2016+ | Złożona konfiguracja, ale praktycznie zerowy przestój |
| Azure Data Factory | Migracje + transformacje ETL, obciążenia BI | Dedykowane do hurtowni danych i integracji |
Krok po kroku: jak bezpiecznie przeprowadzić migrację
Krok 1 — Ocena gotowości i rozpoznanie problemów
Zainstaluj i uruchom narzędzie Azure Migrate w subskrypcji Azure. Skonfiguruj appliance (urządzenie) do odkrywania serwerów, a następnie uruchom ocenę (assessment). Raport wskaże:
- Funkcje niekompatybilne z Azure SQL Database: np. użycie
OPENROWSET,xp_cmdshell, widoków systemowychsys.servers, własnych typów CLR. - Zależności na poziomie instancji: SQL Agent Jobs, linked servers, Service Broker, filtry replikacji.
- Wymagane zmiany: np. zastąpienie Windows Auth przez Microsoft Entra ID, migracja SSIS do Azure Data Factory SSIS IR, konwersja SSRS do Power BI Paginated Reports.
Jeśli raport pokazuje dużo problemów na poziomie instancji, rozważ Azure SQL Managed Instance zamiast Database — oferuje niemal 100% zgodności z SQL Server on-premise.
Krok 2 — Przygotowanie środowiska źródłowego i docelowego
Po stronie źródłowej:
- Wykonaj pełny backup i
DBCC CHECKDB— upewnij się, że bazy nie są uszkodzone. - Zaktualizuj statystyki (
UPDATE STATISTICS ... WITH FULLSCAN). - Ujednolić collations między źródłem a celem (Azure SQL domyślnie używa
SQL_Latin1_General_CP1_CI_AS).
Po stronie Azure:
- Utwórz logical server (serwer logiczny) w odpowiednim regionie (najbliżej Twoich użytkowników — w przypadku Polski będzie to najczęściej region West Europe lub Germany West Central).
- Załóż docelową bazę danych z tymczasowo zawyżoną warstwą usług (Business Critical, min. 8 vCore) — przyspieszy to transfer.
- Skonfiguruj Microsoft Entra ID i utwórz konta administratorów.
- Skonfiguruj reguły firewalla, aby zezwolić na ruch z adresów IP sieci on-premise.
Krok 3 — Migracja schematu i danych (z użyciem Azure DMS)
- W Azure Portal wejdź do Azure Database Migration Service → "New migration project".
- Wybierz źródło (SQL Server on-premise) i cel (Azure SQL Database).
- Wybierz tryb: offline (prostszy) lub online (dla systemów produkcyjnych 24/7).
- DMS skopiuje schemat i rozpocznie transfer danych. W trybie online dodatkowo podłącza replikację ciągłą — wszystkie nowe transakcje na źródle są natychmiast odzwierciedlane w Azure SQL.
- Monitoruj postęp w Azure Portal — zobaczysz liczbę skopiowanych tabel, wierszy i ewentualne błędy.
Krok 4 — Cutover (przełączenie)
- Gdy dane zostaną w pełni zsynchronizowane i różnica opóźnień spadnie do zera (w trybie online), zaplanuj okno serwisowe (zwykle 15–30 minut).
- Zatrzymaj ruch aplikacji.
- W DMS wykonaj cutover — kończy to replikację, a baza w Azure SQL przechodzi w tryb read-write.
- Zmień connection string w aplikacjach na endpoint Azure SQL.
Krok 5 — Optymalizacja po migracji
- Zaktualizuj statystyki pełnym skanem (
EXEC sp_updatestats). - Uruchom testy wydajnościowe i porównaj z wynikami on-premise.
- Skaluj bazę w dół do właściwej warstwy oszczędzając koszty (np. z Business Critical do General Purpose, jeśli aplikacja nie wymaga ultra-niskich opóźnień).
- Skonfiguruj Azure Monitor i Query Performance Insight do długoterminowego monitorowania.
Typowe pułapki i jak ich uniknąć
1. Nieobsługiwane funkcje — błąd na starcie
Azure SQL Database to platforma na poziomie bazy danych, nie instancji SQL Servera. Brakuje: SQL Server Agent (→ Elastic Jobs), Windows Authentication (→ Microsoft Entra ID), Service Broker, CLR (w większości przypadków), OPENROWSET/OPENDATASOURCE. Rozwiązanie: Uruchom Azure Migrate przed rozpoczęciem prac — raport zgodności pokaże wszystko.
2. Zbyt wolny transfer danych
Jeśli masz dużą bazę i domyślną warstwę General Purpose, transfer może trwać wiele godzin. Rozwiązanie: na czas migracji podbij warstwę do Business Critical z 8 vCore (log rate 96 MB/s) i upewnij się, że łącze sieciowe (najlepiej ExpressRoute) ma przepustowość min. 768 Mb/s.
3. Collation mismatch
Azure SQL Database używa domyślnie SQL_Latin1_General_CP1_CI_AS. Jeśli Twoja baza on-premise ma polskie sortowanie (Polish_CI_AS), funkcje porównujące stringi mogą działać inaczej. Rozwiązanie: Utwórz bazę Azure SQL z identycznym collation jak źródło — sprawdzisz to poleceniem: SELECT name, collation_name FROM sys.databases.
4. Loginy i użytkownicy nie działają po migracji
DMS kopiuje schemat i dane, ale nie loginy SQL ani Windows. Rozwiązanie: Użyj skryptu PowerShell Move-SqlLoginsToAzureSql.ps1 (dostępny na GitHub Microsoft), który generuje T-SQL do odtworzenia loginów i mapowania użytkowników.
Częste pytania
Czy mogę migrować SQL Server 2012 lub starszy do Azure SQL Database?
Tak, ale tylko przez metody pośrednie, takie jak BACPAC (export/import) lub bcp. Azure SQL Database natywnie wspiera bazy o zgodności od SQL Server 2005, jednak im starsza wersja, tym więcej problemów z kompatybilnością (brak wsparcia dla datetimeoffset, funkcji okienkowych itp.). Przed migracją warto podnieść compatibility level źródłowej bazy do minimum 130 (SQL Server 2016).
Czy migracja do Azure SQL Database oznacza utratę kontroli nad backupami?
Azure SQL Database automatycznie wykonuje pełne, różnicowe i log backupów — Microsoft zarządza nimi w pełni. Ty natomiast zyskujesz Point-in-Time Restore (domyślnie 7 dni, do 35 dni w wyższych konfiguracjach) oraz Long-Term Retention (do 10 lat na Azure Blob Storage). Nie tracisz kontroli — po prostu nie musisz już ręcznie konfigurować maintenance planów.
Ile kosztuje migracja — czy są darmowe narzędzia?
Samo narzędzie Azure Database Migration Service jest bezpłatne — płacisz wyłącznie za zasoby Azure zużyte podczas migracji (docelowa baza, transfer danych wychodzący z Azure). Azure Migrate jest również całkowicie darmowy. Koszt samej migracji jest więc marginalny — głównym wydatkiem będzie docelowa subskrypcja Azure SQL Database.
Co zrobić z pakietami SSIS i raportami SSRS?
Pakiety SSIS migrujesz do Azure Data Factory SSIS Integration Runtime — środowiska uruchomieniowego SSIS w chmurze. Alternatywnie możesz przepisać logikę ETL bezpośrednio na Azure Data Factory Data Flows. Raporty SSRS migrujesz do Power BI Paginated Reports za pomocą bezpłatnego narzędzia RDL Migration Tool, dostępnego na GitHubie Microsoftu.
Czy mogę migrować bazę produkcyjną bez żadnego przestoju?
Całkowicie bezprzestojowa migracja nie istnieje — zawsze jest moment przełączenia (cutover). Jednak tryb online w Azure DMS lub replikacja transakcyjna redukują przestój do kilku minut — tyle, ile trwa ostatnia synchronizacja i zmiana connection stringa w aplikacjach. Dla systemów klasy enterprise to akceptowalne okno serwisowe.
Czy po migracji mogę wrócić do SQL Server on-premise?
Azure SQL Database nie oferuje natywnego "reverse migration". Dane możesz wyeksportować do pliku BACPAC przez SqlPackage i zaimportować do SQL Server on-premise. Jednak niektóre funkcje dostępne tylko w Azure SQL (np. Hyperscale) nie zostaną odwzorowane — powrót nie jest bezstratny. Dlatego tak ważne jest dokładne testowanie przed ostatecznym cutoverem.
Jakie łącze sieciowe jest optymalne przy migracji do Azure z Polski?
Dla pojedynczej, średniej wielkości bazy (do 100 GB) wystarczy stabilne łącze internetowe o przepustowości min. 100 Mb/s. Przy większych wolumenach danych lub migracji wielu baz jednocześnie zdecydowanie zaleca się Azure ExpressRoute — dedykowane prywatne łącze do Azure o przepustowości od 50 Mb/s do 10 Gb/s, które omija publiczny internet i skraca czas transferu nawet o połowę.
Jeśli Twoja organizacja stawia pierwsze kroki w chmurze Microsoft i potrzebujesz legalnych, przystępnych cenowo licencji na Windows Server lub SQL Server dla środowiska hybrydowego, odwiedź nasz sklep — oferujemy licencje serwerowe zgodne z prawem unijnym, które możesz wykorzystać również w ramach programu Azure Hybrid Benefit: Licencje serwerowe Windows Server i SQL Server →