SQL Server 2025 Upgrade Rehberi: Geçiş Yolları, Kırıcı Değişiklikler ve Adım Adım Plan

SQL Server upgrade projelerini zorlaştıran şey nadiren kurulum sihirbazıdır. Asıl zorluk veritabanı motorunun çevresindedir: motora bağlanan uygulamalar ve sürücüler, kullanıcı veritabanlarının dışında yaşayan sunucu düzeyindeki nesneler, yeni sorgu optimizer’ıyla değişen çalışma planları, yüksek erişilebilirlik topolojisi ve hepsinden önemlisi, yükseltilmiş bir veritabanının eski sürüme geri alınamaması. Başarısız upgrade’lerin çoğu kurulumun kendisinde değil, bu noktalardan birinde başarısız olur.

Bu rehberde hangi sürümlerin SQL Server 2025’e nasıl geçebileceğini, SQL Server 2025’te mevcut ortamları en sık bozan değişiklikleri, in-place upgrade ile side-by-side migration arasındaki seçimi ve değerlendirmeden upgrade sonrası performans iyileştirmesine kadar adım adım bir planı ele alıyoruz.

Hızlı Karar Tablosu: Hangi Upgrade Yolu Uygun?

Test Edilen Sürüm Notları

Son doğrulama: 19 Ekim 2026. Aşağıdaki her iddia bu tarihte Microsoft Learn üzerinden okundu. T-SQL örnekleri SQL Server 2025 (build 17.0.4055.5) üzerinde test edilmiştir.

Sürümünüz Destek Döngüsünün Neresinde?

Bir upgrade’in aciliyeti büyük ölçüde mevcut sürümün Microsoft destek döngüsündeki yerine bağlıdır. Extended support sona erdiğinde, Extended Security Updates (ESU) satın alınmadıkça sürüm artık güvenlik düzeltmesi almaz. ESU da yalnızca kritik güvenlik güncellemelerini, en fazla üç yıl boyunca kapsar.

Microsoft, SQL Server 2025’e in-place upgrade’i SQL Server 2014 SP3 ve sonrası, 2016 SP3 ve sonrası, 2017, 2019 ve 2022 için destekler. Daha eski sürümler yerinde yükseltilemez, ancak veritabanları taşınabilir: Compatibility level’ı 90 veya üzerinde olan her veritabanı SQL Server 2025’e restore ya da attach edilebilir; 90 seviyesindeki veritabanları otomatik olarak 100’e yükseltilir.

Tam olarak neyi çalıştırdığınızı görmek için her instance’ta sürüm, edition ve build bilgisini kontrol edin:

SELECT
    SERVERPROPERTY('ServerName')     AS sunucu,
    SERVERPROPERTY('ProductVersion') AS build,
    SERVERPROPERTY('ProductLevel')   AS service_pack,
    SERVERPROPERTY('ProductUpdateLevel') AS cumulative_update,
    SERVERPROPERTY('Edition')        AS edition;

SELECT name, compatibility_level, recovery_model_desc, state_desc
FROM sys.databases
ORDER BY name;

SQL Server 2025’te Upgrade’i Bozabilecek Değişiklikler

Her sürümün kaldırılan özellikler ve değişen varsayılanlardan oluşan kendi listesi vardır. SQL Server 2025’te upgrade sırasında ekipleri en sık şaşırtanlar şunlardır:

Bunların ötesinde, uygulamalarınızın hâlâ ne kadar kullanımdan kaldırılacak (deprecated) özellik kullandığını kontrol edin. SQL Server, instance başladığından bu yana her kullanımı sayar:

SELECT instance_name AS deprecated_ozellik, cntr_value AS kullanim_sayisi
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Deprecated Features%'
  AND cntr_value > 0
ORDER BY cntr_value DESC;

Uyumsuzlukların, davranış değişikliklerinin ve kullanımdan kalkan özelliklerin kapsamlı bir değerlendirmesi için Microsoft artık SQL Server Management Studio içindeki SQL Server migration bileşenini sunuyor.

In-Place Upgrade mı, Side-by-Side Migration mı?

Üretim sistemleri için genellikle side-by-side migration’ı öneriyoruz. Proje süresince ikinci bir sunucuya mal olur, ancak geri dönüşü bir yeniden kurulum işi olmaktan çıkarıp bir karara dönüştürür ve aynı anda işletim sistemini yenilemenize ve donanımı doğru boyutlandırmanıza imkân verir.

Veriyi En Az Kesintiyle Taşımak

• Backup ve restore: En basit yöntemdir; kesinti süresi, son yedeğin alınıp dönülmesi kadardır. Küçük veritabanları ya da geniş bakım pencereleri için uygundur.
• Log shipping: Full yedek önceden dönülür, log yedekleri düzenli olarak uygulanır ve geçiş anında yalnızca sonuncusu uygulanır. Kaynak olarak SQL Server 2008 SP3 ve 2008 R2 SP2’den itibaren desteklenir. Kesintiyi dakikalara indirir ve Standard sürümde çalışır.
• Availability group: Zaten availability group kullanan ortamlarda SQL Server 2025 replikası eklenir, senkronize olması beklenir ve failover yapılır. Yeni sürüm primary olduktan sonra eski sürümdeki replikalar yeniden primary olamaz; bu adım geri dönüşü olmayan noktadır.

Kullanıcı Veritabanlarının Dışında Kalan Nesneler

Side-by-side migration’da kullanıcı veritabanlarını taşımak işin kolay kısmıdır. Bir instance’ı çalışır kılan şeylerin şaşırtıcı bir kısmı master, msdb ve sunucunun kendisinde durur ve bunların hiçbiri veritabanı yedeğiyle birlikte taşınmaz. Migration’dan önce aşağıdakilerin envanterini çıkarıp script’leyin ve yeni sunucuda tek tek işaretleyin:

Bu nesnelerin çoğu SSMS ya da T-SQL ile script’lenebilir; dbatools gibi açık kaynak PowerShell araçları da birçoğunu tek seferde kopyalayabilir. Hangi yöntemi kullanırsanız kullanın, kopyanın eksiksiz olduğunu varsaymak yerine geçişten sonra iki sunucudaki nesne sayılarını karşılaştırın.

Yeni Sunucu Kuruyorsanız: Altyapı Kontrolleri

Side-by-side migration yeni bir makine demektir; yeni bir makine de SQL Server’la hiç ilgisi olmayan nedenlerle sorun çıkarabilir. Bunları geçiş haftasonundan önce kontrol edin, geçiş sırasında değil.

Active Directory, OU ve Group Policy

• Yeni computer nesnesini eski veritabanı sunucularıyla aynı OU’da ya da veritabanı sunucularının olması gereken OU’da oluşturun; böylece aynı Group Policy’ler uygulanır.
• Politikaların yeni makineye gerçekten uygulandığını doğrulayın (gpresult /r veya gpresult /h rapor.html): güvenlik baseline’ı, firewall kuralları, yerel yöneticiler, audit politikası, güncelleme politikası.
• SQL Server servis hesabının ihtiyaç duyduğu ve çoğu zaman GPO ile verilen kullanıcı haklarını kontrol edin: instant file initialization için Perform volume maintenance tasks, kullanılıyorsa Lock pages in memory. Eski OU’ya uygulanıp yenisine uygulanmayan bir GPO bu hakları sessizce kaldırır.
• Kerberos’un çalışmaya devam etmesi için yeni sunucu adı ve servis hesabı için SPN’leri kaydedin; linked server’ların ya da raporlamanın dayandığı delegation ayarlarını yeniden oluşturun.

Network yetkileri

• Tüm uygulama sunucularından, raporlama araçlarından ve ETL sunucularından yeni sunucuya firewall kuralları: SQL portu, listener portu ve availability group’lar için endpoint portu (varsayılan 5022).
• Yeni sunucudan çağırdığı her yere erişim: yedek paylaşımları (servis hesabı için yazma yetkisiyle), linked server hedefleri, SMTP relay, job’ların ve SSIS’in kullandığı dosya paylaşımları, izleme ve yedekleme yazılımları.
• DNS: uygulamaların kullandığı alias’lar ya da CNAME’ler ve TTL değerleri; böylece geçiş, her uygulamada ayar değişikliği değil, bir DNS değişikliği olur.
• Eski sunucuyla aynı network segmentasyonu ve VLAN üyeliği; veritabanı sunucusunu internetten uzak tutan kurallar dahil.

Aynı güçte bir makine

• Yeni sunucunun eski sunucuyla aynı güçte bir makine olduğundan emin olun: çekirdek sayısı, çekirdek başına saat hızı, bellek ve depolama gecikmesi. Daha çok çekirdekli ama daha düşük saat hızlı bir sunucu, birçok OLTP sorgusu ve seri batch job’lar gibi tek thread’li işleri yavaşlatabilir.
• SQL Server’ın verdiğiniz her çekirdeği kullanabilmesi için sürümün çekirdek sınırını ve VM’in soket düzenini kontrol edin; ayrıntılar SQL Server kaç CPU çekirdeği kullanabilir yazımızda.
• Windows güç planını High performance yapın, BIOS ya da hypervisor güç profilini kontrol edin.
• Eski sunucudan aldığınız baseline’ı (CPU, bekleme istatistikleri, dosya bazında I/O gecikmesi, önemli job ve raporların süreleri) geçişten önce aynı iş yüküyle yeni sunucuda karşılaştırın.

Compatibility Level ve Sorgu Performansı

Motoru yükseltmek ile bir veritabanının compatibility level’ını yükseltmek iki ayrı karardır. Restore edilen ya da yükseltilen bir veritabanı mevcut compatibility level’ını korur ve yeni motorda bile eski sorgu optimizer davranışının büyük kısmını sürdürür. Bu bilinçli bir tasarımdır: upgrade riskini çalışma planı değişikliği riskinden ayırmanızı sağlar.

Kontrollü bir sıralama şöyledir:

1. Upgrade’den önce bir performans baseline’ı alın: CPU, bekleme türleri ve en önemli sorguların süre ve okuma değerleri.
2. Mevcut compatibility level ile yükseltin ve uygulamaların çalıştığını doğrulayın.
3. Query Store’un açık olduğundan emin olun ve temsil edici bir dönem boyunca iş yükünü toplayın.
4. Compatibility level’ı, tercihen veritabanı veritabanı yükseltin.
5. Query Store ile planları karşılaştırın, geriye giden sorgular için önceki planı zorlayın ve ardından asıl nedeni giderin.

ALTER DATABASE [SatisDB] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);

-- Eski compatibility level ile baseline toplandıktan sonra:
ALTER DATABASE [SatisDB] SET COMPATIBILITY_LEVEL = 170;  -- SQL Server 2025

Compatibility level’ın optimizer’ı nasıl etkilediğini compatibility level yazımızda anlattık.

Always On ve Failover Cluster Ortamlarında Upgrade

Availability group ve failover cluster instance ortamlarında işlemlerin sırası kurulumun kendisinden daha önemlidir. Availability group’ta önce secondary replikalar yükseltilir, ardından yükseltilmiş senkron bir secondary’ye failover yapılır ve son olarak eski primary yükseltilir. Replikalar farklı sürümlerde çalışırken otomatik failover kaldırılmalı ve her failover’dan önce senkronizasyon doğrulanmalıdır. Adım adım prosedür, Always On güncelleme rehberimizde anlattığımız rolling yaklaşımla aynıdır.

Resmi Davranış, Aryasoft Saha Notu ve Bizim Önerimiz

Adım Adım Upgrade Planı

1. Envanter: Instance’lar, sürüm ve build’ler, veritabanları ve compatibility level’ları, sunucu düzeyindeki nesneler, uygulamalar ve kullandıkları sürücüler.
2. Değerlendirme: Desteklenen upgrade yolu, işletim sistemi, kaldırılan ve kullanımdan kalkan özellikler, üçüncü taraf uygulamaların destek beyanları.
3. Yöntem ve hedef: In-place ya da side-by-side, hedef edition ve boyutlandırma, veri taşıma yöntemi.
4. Test ortamı: Üretim veritabanlarının hedef sürümde dönülmesi; uygulama, entegrasyon ve performans testleri.
5. Geçiş ve geri dönüş planı: Zamanlanmış bir runbook, bir devam/vazgeç karar noktası ve geri dönüşü tetikleyecek koşullar.
6. Runbook’a göre upgrade ya da migration.
7. Doğrulama: Uygulamalar, Agent job’ları, entegrasyonlar, güvenlik, yedekler ve HA/DR.
8. Stabilizasyon: Baseline’a göre izleme, compatibility level’ların kontrollü yükseltilmesi ve geriye giden sorguların iyileştirilmesi.

Sık Yapılan Hatalar

• Eski sürüme yedek dönerek geri dönüş yapılabileceğini varsaymak.
• Kullanıcı veritabanlarını taşıyıp login’leri, job’ları, linked server’ları veya sertifikaları unutmak.
• İşletim sistemi ve sürücü değişikliklerini kontrol etmeden yükseltmek.
• Compatibility level’ı baseline almadan, upgrade ile aynı gece yükseltmek.
• Availability group ve failover cluster ortamlarını tek başına çalışan instance’lar gibi ele almak.
• Projeye destek bitiminden aylar önce değil, haftalar önce başlamak.
• Hedef sunucuda oturmuş bir cumulative update yerine ciddi sorunları bilinen bir build seçmek.

SQL Server Upgrade Kontrol Listesi

• Her instance’ın sürüm, edition ve build bilgisi belirlendi mi?
• Kaynak sürüm desteklenen bir upgrade yolunda mı, yoksa migration mı gerekiyor?
• İşletim sistemi SQL Server 2025 gereksinimlerini karşılıyor mu?
• DQS, MDS, Synapse Link, Purview politikaları ya da Web sürümü kullanılıyor mu?
• Yeni sürücü şifreleme varsayılanlarının linked server’lara etkisi test edildi mi?
• Üçüncü taraf uygulama üreticileri SQL Server 2025’i destekliyor mu?
• Tüm sunucu düzeyindeki nesnelerin envanteri çıkarıldı ve script’lendi mi?
• Yeni computer nesnesi doğru OU’da mı, Group Policy’ler ve kullanıcı hakları uygulandı mı?
• Yeni sunucu için firewall kuralları, paylaşım yetkileri, SMTP relay, SPN’ler ve DNS alias’ları hazır mı?
• Yeni sunucu, çekirdek başına saat hızı ve depolama gecikmesi dahil eski sunucuyla aynı güçte bir makine mi?
• TDE ve yedek şifreleme sertifikaları yedeklendi ve hedefte test edildi mi?
• Performans baseline’ı alındı ve Query Store açık mı?
• Net bir devam/vazgeç noktası olan zamanlanmış bir geçiş runbook’u var mı?
• Geri dönüş planı eski ortamı bozulmadan koruyor mu?
• HA/DR topolojisi upgrade sonrasında test edildi mi?

Kaynaklar (Microsoft Learn)

Bu rehberdeki teknik iddialar 19 Ekim 2026 tarihinde aşağıdaki birincil kaynaklara karşı kontrol edildi. Microsoft dokümantasyonu her an değişebilir; üretimde değişiklik yapmadan önce sürüme özel ayrıntıları yeniden doğrulayın.

• Desteklenen sürüm ve edition yükseltmeleri (SQL Server 2025)
• Database Engine upgrade yöntemini seçme
• Database Engine upgrade planını hazırlama ve test etme
• SQL Server 2025 donanım ve yazılım gereksinimleri
• SQL Server 2025’te yenilikler
• SQL Server 2025’te Database Engine uyumsuz değişiklikleri
• Availability group replika instance’larını yükseltme
• ALTER DATABASE compatibility level
• RESTORE deyimleri (Transact-SQL)
• SQL Server destek sonu seçenekleri
• SQL Server için Extended Security Updates
• Microsoft Lifecycle: SQL Server 2016 (2014, 2017, 2019, 2022 ve 2025 için de aynı yapı)