SQL Server 2016 Desteği Bitti: Seçenekler ve Güvenli Yükseltme Rehberi

SQL Server 2016’nın uzatılmış desteği 14 Temmuz 2026’da sona erdi. Sunucular o gün durmadı; asıl sorun da bu. Hiçbir şey bozulmadığı için karar sürekli erteleniyor. Bu sırada yeni açıklar için güvenlik yaması çıkmıyor, Microsoft destek kaydı açmıyor ve ertelenen her ay, sonunda yapılacak yükseltmeyi daha büyük bir sıçramaya dönüştürüyor.

Bu yazıda elinizdeki gerçek seçenekleri, bunlar arasında nasıl karar vereceğinizi ve SQL Server 2016’dan çıkarken sahada en sık gördüğümüz hataları anlatıyoruz.

Destek Sonu Gerçekte Ne Anlama Geliyor?

14 Temmuz 2026’dan sonra Microsoft, ücretli Extended Security Updates (ESU) kapsamında olmayan SQL Server 2016 kurulumları için güvenlik güncellemesi yayımlamıyor. Pratikte bunun anlamı:

• Güvenlik yaması yok. Yeni bulunan açıklar, korumasız her instance’ta açık kalıyor.
• Destek kaydı yok. Destek anlaşmanız olsa bile Microsoft, ESU kapsamında olmayan bir SQL Server 2016 için destek kaydı açmıyor.
• Denetim bulguları. İç ve dış denetimler, KVKK değerlendirmeleri ve sektör düzenleyicileri desteklenmeyen yazılımı bulgu olarak yazıyor. “Hâlâ çalışıyor” bir denetim raporunda kabul edilen bir cevap değil.
• Ekosistemden kopma. Yeni sürücüler, araçlar ve uygulama sürümleri güncel sürümlerle test ediliyor. Eski istemci kütüphaneleri ve işletim sistemleri de veritabanı motoruyla birlikte eskiyor.

Seçenekleriniz

ESU bir köprüdür, varış noktası değil. Yükseltmeyi doğru yapmak için zaman kazandırır, ama platformla birlikte eskiyen diğer hiçbir şeyi çözmez. ESU alıyorsanız, gerçek yükseltmenin hedef tarihini aynı gün belirleyin.

SQL Server 2022 ile 2025 arasında ve edition’lar arasında seçim için sürüm karşılaştırma yazımıza bakabilirsiniz. Lisans da kararın parçasıysa lisanslama rehberimiz core ve CAL modellerini ve güncel fiyatları anlatıyor.

Yerinde Upgrade mı, Yeni Sunucuya Geçiş mi?

SQL Server 2025, SQL Server 2016 SP3 ve üzerinden yerinde upgrade’i destekliyor. Bu, doğru seçimin bu olduğu anlamına gelmiyor. Kararı genellikle iki gerçek belirliyor:

• İşletim sistemi. Pek çok SQL Server 2016 hâlâ Windows Server 2012 R2 ya da 2016 üzerinde çalışıyor. SQL Server 2025 daha yeni bir Windows Server gerektirdiği için sunucunun zaten değişmesi gerekiyor.
• Geri dönüş yolu. Yerinde upgrade, binary’leri değiştirir ve instance’taki tüm veritabanlarını yükseltir. Sonrasında uygulama sorun çıkarırsa bir “eski sürüme dön” düğmesi yoktur.

Yan yana geçişte yeni sürüm yeni bir sunucuya kurulur, veritabanları backup/restore ile (kesintinin kısa tutulması gerekiyorsa log shipping ile) taşınır ve yeni sunucu kendini kanıtlayana kadar eski sunucuya dokunulmaz. Birkaç haftalık ikinci bir sunucu maliyeti karşılığında, yerinde upgrade’in veremeyeceği tek şeyi kazanırsınız: geri dönülebilecek çalışan bir sistem. Ayrıntılı adımlar, geçiş yolları ve kırıcı değişiklikler SQL Server 2025 upgrade rehberimizde.

Sahada En Sık Gördüğümüz Hatalar

Çağrıldığımız yükseltme sorunlarının çoğunun SQL Server’ın kendisiyle ilgisi yok. “Sadece bir sürüm yükseltmesi” diye atlanan adımlardan kaynaklanıyorlar.

1. Uygulamanın yeni motorla uyumu kontrol edilmiyor

Veritabanı yükseltmesi test ediliyor, uygulama test edilmiyor. Sonra pazartesi sabahı bir rapor zaman aşımına düşüyor, bir ERP modülü hata veriyor ya da eski bir sürücü bağlanmayı reddediyor. Hedef sürümü seçmeden önce:

• Uygulama üreticisinden desteklenen sürüm listesini yazılı olarak alın. Pek çok ERP ve paket uygulama yalnızca belirli SQL Server sürümlerini onaylıyor.
• Uygulamanın gerçekten kullandığı, kullanımdan kaldırılmış ve tamamen kaldırılmış özellikleri bulun. Kullanımdaki kaldırılan özellikleri bulma rehberimiz, bunları çalışan bir instance’tan nasıl yakalayacağınızı gösteriyor.
• İstemci sürücülerini kontrol edin. Yeni sürücüler bağlantıları varsayılan olarak şifreliyor; eski sertifikaları ya da eski sürücüleri olan bir uygulama sunucusu yükseltmeden sonra bağlanamayabilir. Linked server’lar da etkileniyor; SQL Server 2025 değişikliği için linked server rehberimize bakın.
• Yükseltme sırasında veritabanlarını mevcut compatibility level’larında bırakın ve sonra, bilinçli olarak yükseltin. Compatibility level rehberimiz neyin değiştiğini ve nasıl güvenle yükseltileceğini anlatıyor.

2. Gerçek geçişten önce dry run yapılmıyor

Dry run, üretimin bir kopyası üzerinde yapılan tam bir provadır: dün geceki yedekleri hedef sürümün kurulu olduğu bir test sunucusuna geri yükler, uygulamanın test kopyasını bu sunucuya bağlar ve gerçek iş yükünü çalıştırırsınız. Hiçbir kontrol listesinin cevaplayamayacağı soruları cevaplar:

• Kritik ekranlar, raporlar ve batch işler çalışıyor mu, makul sürede bitiyor mu?
• Hangi sorgular yavaşladı? Test kopyasında Query Store‘u açın ve planları ve süreleri eski sunucuyla karşılaştırın.
• Geçiş gerçekte ne kadar sürüyor? Gerçek veri boyutlarında backup, kopyalama, restore ve doğrulama süresi, iş birimine söz vereceğiniz kesinti süresini belirler.
• Agent job’ları, SSIS paketleri, linked server’lar, login’ler ve SQL Server dışındaki zamanlanmış görevler hâlâ çalışıyor mu?

Dry run’ı adım adım yazın. Gerçek geçiş, doğaçlama değil, bir kez çalıştığı görülmüş bir prosedürün tekrarı olmalı.

3. Geri dönüş bileti düşünülmüyor

Kötü bir geceyi kayıp bir haftaya çeviren hata bu. SQL Server 2025’te alınan bir yedek SQL Server 2016’ya geri yüklenemez; yükseltilmiş bir veritabanı da eski sürüme indirilemez. Kullanıcılar yeni sürüme veri yazmaya başladıktan sonra eski sürüm öylece yeniden devreye alınamaz.

Gerçekçi bir geri dönüş planının üç parçası var:

• Eski sistem olduğu gibi kalır. Yan yana geçişte eski sunucuya, yeni sunucu en az bir tam iş döngüsünü (örneğin bir ay sonu kapanışını) geçirene kadar dokunmayın; veritabanları da geri yüklenebilir durumda kalsın.
• Bir devam/vazgeç (go/no-go) noktası. Kullanıcılar üretim verisi yazmaya başlamadan önceki bir an üzerinde anlaşın, örneğin doğrulama süresinin sonu. O ana kadar geri dönmek, uygulamayı eski sunucuya yeniden yönlendirmek demektir. Sonrasında geri dönmek; veri kaybı, verinin yeniden girilmesi ya da ayrı bir veri senkronizasyon planı demektir.
• Test edilmiş bir prosedür. Geri dönüş, dry run’ın bir parçasıdır. Bağlantı ayarlarını hiç geri çevirip denemediyseniz, bir geri dönüş planınız yok demektir.

4. Snapshot ve sistem veritabanı yedeği olmadan yerinde upgrade

Yerinde upgrade’i seçen ekipler çoğu zaman bunu hiçbir güvenlik ağı olmadan doğrudan üretim makinesinde deniyor. Kurulum yarıda kalınca ya da yükseltilen instance farklı davranınca dönülecek bir yer kalmıyor. Yerinde upgrade’den önce:

• Tüm kullanıcı veritabanlarının tam yedeğini alın ve doğrulayın. Doğrulama ve restore testleri için backup planı rehberimize bakın.
• Sistem veritabanlarını yedekleyin: master, msdb ve model. Login’ler, Agent job’ları, linked server’lar ve sunucu yapılandırması burada durur. Sistem veritabanı yedekleri yalnızca aynı sürüm ve build’e geri yüklenebilir; yani bunlar eski instance’a dönüş yolunuzdur, yeni sürüme taşıma aracı değil.
• SQL Server servisleri durdurulmuşken VM snapshot’ı alın, böylece snapshot tutarlı olur. Çalışan bir veritabanı sunucusunun snapshot’ı en iyi ihtimalle “çökme anı” tutarlılığındadır.
• Yapılandırmayı kayıt altına alın: sp_configure değerleri, trace flag’ler, başlangıç parametreleri, servis hesapları, dosya konumları ve tam build numarası.
• Kurulum ön koşullarını kontrol edin, bekleyen yeniden başlatmalar dahil. Microsoft, SQL Server 2016’dan yükseltmenin Visual C++ Redistributable nedeniyle başarısız olabildiği bilinen bir sorun yayımlıyor; bileşeni onarıp kurulumu yeniden çalıştırmak sorunu çözüyor.

-- Yerinde upgrade öncesi: sistem veritabanlarını yedekleyin ve build'i kaydedin
BACKUP DATABASE master TO DISK = N'D:\PreUpgrade\master.bak' WITH CHECKSUM, INIT;
BACKUP DATABASE msdb   TO DISK = N'D:\PreUpgrade\msdb.bak'   WITH CHECKSUM, INIT;
BACKUP DATABASE model  TO DISK = N'D:\PreUpgrade\model.bak'  WITH CHECKSUM, INIT;

SELECT SERVERPROPERTY('ProductVersion') AS build,
       SERVERPROPERTY('ProductLevel')   AS service_pack,
       SERVERPROPERTY('Edition')        AS edition;

Pratik Bir İş Sırası

1. Envanter: her 2016 instance’ı, edition’ı, işletim sistemi sürümü, veritabanları, boyutları, uygulamaları ve sahipleri.
2. Her instance için karar: köprü olarak ESU, yan yana geçiş ya da yerinde upgrade ve hedef sürüm.
3. Uygulama uyumluluğu: üretici desteği, kaldırılan özellikler, sürücüler, linked server’lar.
4. Hedef sunucuyu kurulum varsayılanlarıyla değil, bir kurulum kontrol listesiyle kurun.
5. Dry run: gerçek veriyle, performans karşılaştırmasıyla ve süresi ölçülmüş bir geçişle.
6. Geri dönüş planını yazın ve devam/vazgeç noktasında anlaşın.
7. Geçiş: prova edilmiş prosedürle.
8. Stabilizasyon: bir tam iş döngüsü boyunca performansı ve hataları izleyin, sonra compatibility level’ları veritabanı veritabanı yükseltin.
9. Eski sunucuyu ancak bundan sonra kapatın.

Aryasoft Bunu Nasıl Yapıyor?

Aryasoft’un kıdemli DBA ekibi her SQL Server 2016 projesine bir envanter ve uygulama uyumluluk incelemesiyle başlar, hiçbir şeye dokunmadan önce taşımayı üretimin bir kopyası üzerinde prova eder. Her geçişin yazılı bir geri dönüş planı ve üzerinde anlaşılmış bir devam/vazgeç noktası vardır; eski sistem, yeni sistem günlük kullanımda kendini kanıtlayana kadar devrede kalır.