SharePoint 2016/2019 Desteği Bitti: SharePoint Online Geçişi (2026)

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100/MS-102/AZ-104 sertifikalı danışmanlar · Son güncelleme: 25 Ağustos 2026

Özet (TL;DR): SharePoint Server 2016 ve SharePoint Server 2019 için genişletilmiş destek 15 Temmuz 2026 sabahı (Pasifik saatiyle) resmen bitti — Microsoft'un resmi yaşam döngüsü kaydına göre bu tarihten sonra iki üründe de artık güvenlik yaması, hata düzeltmesi veya teknik destek yok. Sunucularınız çalışmaya devam eder ama her geçen gün yamasız kalan, internete açık bir SharePoint çiftliği işletmiş olursunuz. İki gerçek çıkış yolu var: SharePoint Online'a göç (Microsoft'un önerdiği, çoğu kurum için doğru cevap) veya SharePoint Server Subscription Edition'a (SPSE) yerinde yükseltme. Bu yazıda ücretsiz SharePoint Migration Tool (SPMT) ile adım adım göç sürecini, taşınmayan özellikleri ve göçü kıran teknik tuzakları anlatıyoruz.

Türkiye'de hâlâ tek sunuculu ya da iki-üç sunuculu SharePoint 2016/2019 çiftlikleri üzerinde çalışan çok sayıda kurum var ve çoğu bu tarihin farkında değil — çünkü sunucu "çalışmaya devam ediyor". Sorun şu: yamasız bir SharePoint, geçmişte kimlik doğrulanmamış uzaktan kod çalıştırma zafiyetleriyle (ToolShell benzeri saldırı dalgaları) kitlesel olarak hedef alınmış bir üründür. Ücretsiz göç değerlendirmesi ve fiyat teklifi alın — mevcut farminizi inceleyip SharePoint Online mı yoksa SPSE mi sizin için doğru olduğunu birlikte netleştirelim.

Takvim: destek gerçekte ne zaman bitti, ne anlama geliyor

Microsoft'un resmi yaşam döngüsü kaydına göre iki ürün de aynı tarihte kapandı:

• SharePoint Server 2016 — ana akış (mainstream) desteği 14 Temmuz 2021'de, genişletilmiş desteği 15 Temmuz 2026'da (Pasifik saatiyle 06:59) sona erdi. Kaynak: Microsoft Lifecycle — SharePoint Server 2016.
• SharePoint Server 2019 — ana akış desteği 9 Ocak 2024'te, genişletilmiş desteği de aynı gün, 15 Temmuz 2026'da bitti. Microsoft, 2019 sürümünün destek takvimini bilinçli olarak 2016 ile hizaladı. Kaynak: Microsoft Lifecycle — SharePoint Server 2019.

"Destek bitti" ifadesi genelde yanlış anlaşılıyor. Sunucularınız 15 Temmuz'da kapanmadı, çalışmaya devam ediyor. Ancak bu tarihten sonra: yeni keşfedilen güvenlik açıkları için yama gelmiyor, Microsoft destek hattına bilet açamıyorsunuz, hata düzeltmesi yok, saat dilimi/uyumluluk güncellemesi yok. SharePoint 2013 zaten Nisan 2023'te aynı noktaya gelmişti; 2016/2019 ile birlikte artık desteklenen hiçbir "klasik" SharePoint sürümü kalmadı — tek şirket-içi seçenek SharePoint Server Subscription Edition (SPSE).

İki gerçek yol var: SharePoint Online mı, SPSE mi?

Microsoft'un resmi yönlendirmesi iki hedef tanımlıyor. Kararı "hangisi ucuz" değil, "verinin nerede durması gerekiyor" sorusuyla verin.

1. SharePoint Online'a göç — önerilen yol

Microsoft 365 içindeki bulut SharePoint hizmeti "evergreen" çalışır: siz yama takibi, sunucu donanımı, SSL sertifikası yenileme ve kapasite planlaması yapmazsınız, Microsoft yapar. Karşılığında Microsoft Purview ile hassasiyet etiketleme, veri kaybı önleme (DLP — kritik belgelerin izinsiz dışarı çıkmasını engelleyen otomatik kural seti), Teams/OneDrive entegrasyonu ve düzenli güvenlik güncellemesi gelir. Kurumların büyük çoğunluğu için doğru hedef budur.

2. SharePoint Server Subscription Edition'a (SPSE) yükseltme — şirket içi kalmanız gerekiyorsa

Mevzuat gereği verinin yurt içinde kalması zorunluluğu veya buluta taşınamayan özel entegrasyonlarınız varsa hedef SPSE. Microsoft'un resmi SPSE yükseltme rehberine göre SharePoint 2019'dan SPSE'ye yerinde (in-place) yükseltme mümkün — SPSE, 2019'un kümülatif bir devamı sayıldığı için risk düşük. SharePoint 2016'dan ise veritabanı yükseltme adımları üzerinden geçiş gerekiyor. Kritik ayrıntı: SPSE de artık abonelik modeliyle lisanslanıyor — "bir kere satın alıp on yıl kullanma" dönemi bitti, yıllık lisans yenilemesi şart.

Türkiye'deki 50-500 kullanıcılı tipik kurumlarda pratikte kalan seçenek SharePoint Online'dır; içerik Microsoft 365 çözümlerimiz kapsamında Teams ve OneDrive ile birlikte paketleniyor.

Göç öncesi hazırlık: envanter, özelleştirme ve izin denetimi

SPMT'yi açıp "başlat" demeden önce dört şeyi çıkarmadan yola çıkmayın:

1. Site ve içerik envanteri. Kaç site collection, kaç alt site, toplam kaç GB içerik var? Microsoft'un resmi hizmet limitlerine göre SharePoint Online'da tenant başına depolama 1 TB + lisans başına 10 GB olarak hesaplanıyor (örnek: 1 TB temel + 150 lisanslı kullanıcı = yaklaşık 2,5 TB toplam kota); tek site 25 TB'a, tek dosya ise 250 GB'a kadar büyüyebiliyor. Envanteriniz bu kotayı aşıyorsa ek depolama satın alma ihtiyacını göç öncesi bütçeleyin.
2. Özel kod ve full-trust çözümler. Sunucu üzerinde çalışan özel .NET kodu, farm solution veya eski web part'lar varsa bunlar SharePoint Online'a hiç taşınmaz — bulutta sunucu tarafı kod çalıştırma modeli yok. Bu tür özelleştirmeleri SharePoint Framework (SPFx) ile yeniden yazmanız gerekir; göç takvimine ayrı bir iş paketi olarak ekleyin.
3. Workflow envanteri. SharePoint Designer 2010/2013 iş akışlarınız varsa listeleyin — SPMT bunları otomatik olarak Power Automate'e taşıyabiliyor, ama her workflow'un doğru taşındığını tek tek doğrulamanız gerekiyor.
4. İzin haritası. Hangi sitede kimin hangi izinle (okuma/katkı/tam denetim) olduğunu, özellikle devralınan (inherited) değil açıkça (explicit) verilmiş izinleri çıkarın. Göç sonrası izin karmaşası, kullanıcı şikâyetlerinin en sık kaynağıdır.

SharePoint Migration Tool (SPMT) ile göç nasıl yapılır — adım adım

SPMT, Microsoft'un ücretsiz resmi göç aracı; SharePoint Server 2010/2013/2016/2019'dan ve düz dosya sunucularından (fileshare) SharePoint Online, OneDrive ve Teams'e içerik taşıyor.

Ön koşullar

• Kurum genelinde göç için Genel Yönetici (Global Admin) veya SharePoint Yöneticisi olarak Microsoft 365'te oturum açabilmelisiniz; tek bir site collection taşıyacaksanız o site için Site Yöneticisi yetkisi yeterli.
• Kaynak SharePoint sunucusuna ve hedef Microsoft 365 kiracınıza (tenant) ağ erişimi olan bir Windows makinesine ihtiyacınız var — SPMT bu makineden çalışır, sunucuya kurulum gerekmez.
• Not: SPMT, 21Vianet tarafından işletilen Çin Office 365'i için desteklenmiyor; bu bizim için geçerli değil ama uluslararası şubesi olan kurumlar için önemli bir ayrıntı.

Adım 1 — Kurulum

SPMT'yi resmi Microsoft indirme sayfasından edinin ve göçü yönetecek makineye kurun. Araç, PowerShell modülü olarak da mevcut — büyük ölçekli veya tekrarlanan göçlerde script'lenebilir taşıma için PowerShell modülünü tercih edin.

Adım 2 — Kaynağı tarayın ve değerlendirin (yalnızca site göçü)

Site collection taşıyorsanız SPMT'nin tarama (scan) özelliğini çalıştırın; araç desteklenmeyen web part'ları, özel şablonları ve potansiyel sorunları önceden raporlar. Bu raporu göç planınıza girdi olarak kullanın — canlıda sürpriz istemezsiniz.

Adım 3 — Göç görevi (migration task) oluşturun

Kaynak olarak on-prem SharePoint sitesini veya dosya sunucusu yolunu, hedef olarak SharePoint Online site/kütüphane veya OneDrive/Teams konumunu belirleyin. Bir görevde birden çok kaynak-hedef eşleşmesi tanımlayabilirsiniz.

Adım 4 — Ayarları yapılandırın

Sürüm geçmişini (versions) ne kadar taşıyacağınızı, yönetilen meta veri (managed metadata) ve terim deposu eşleşmesini burada belirlersiniz. Genel terim deposu (global term store) göçü, kiracı genel yöneticisi izni gerektirir — bu adımı atlarsanız kategori/etiket alanları hedefte boş kalır.

Adım 5 — Çalıştırın ve izleyin

Görevi başlatın; SPMT ilerlemeyi ve hataları arayüzde canlı gösterir. Büyük hacimli göçlerde görevi kademeli (aşamalı) çalıştırıp her partiden sonra hata raporunu inceleyin — tek seferde her şeyi göndermek, bir hata çıktığında tüm göçü tekrarlamanızı gerektirir.

Adım 6 — Artımlı (incremental) tekrar çalıştırma

SPMT görevleri kaydedilip daha sonra yeniden çalıştırılabilir; bu sırada yalnızca kaynak tarafında değişen veya yeni eklenen dosyalar taşınır. Kesme (cutover) gecesinden önce bir "son fark" göçü çalıştırmak, kesinti süresini dakikalara indirir.

Göçü kıran teknik tuzaklar

SPMT'nin kendisi güvenilir; sorunlar genelde kaynaktaki eski alışkanlıklarla hedefteki katı kurallar çarpıştığında çıkıyor.

• Yasaklı karakterler. Microsoft'un resmi kısıtlama listesine göre OneDrive ve SharePoint Online'da dosya/klasör adlarında şu karakterler kullanılamaz: " * : < > ? / \ |. Ayrıca ad başında veya sonunda boşluk, bazı kiracılarda # ve % da sorun çıkarabiliyor. Yıllarca sorunsuz çalışan bir dosya sunucusunda bu karakterler yaygın olabilir — göç öncesi tarayıp normalleştirin.
• Yasaklı dosya/klasör adları. .lock, CON, PRN, AUX, NUL, COM0-COM9, LPT0-LPT9, _vti_, desktop.ini ve ~$ ile başlayan adlar hedefte kabul edilmiyor.
• 400 karakter yol sınırı. Klasör yolu + dosya adının tamamı, çözümlendikten sonra 400 karakteri geçemez. Derin klasör hiyerarşisi olan eski dosya sunucularında bu sınıra en çok takılan kurumlardansınızdır.
• 250 GB dosya boyutu sınırı. Tek bir dosya için üst sınır 250 GB; CAD/BIM veya video arşivi olan kurumlarda bu nadiren de olsa aşılabiliyor.
• Devralınan izinler taşınmaz. Yalnızca açıkça (explicit) tanımlanmış izinler hedefe taşınıyor; üst klasörden devralınan izinler taşınmıyor. Göç sonrası "bu klasöre neden erişemiyorum" biletlerinin bir numaralı sebebi budur.

Ne taşınmaz: workflow, web part ve özel kod sınırları

SPMT güçlü ama sınırsız değil. SharePoint 2010 out-of-the-box iş akışlarını (Approval, Collect Feedback, Collect Signature, Three-state) ve SharePoint Designer 2010/2013 workflow'larını Power Automate'e taşıyabiliyor — bu, aracın en değerli özelliklerinden biri. Ama şunlar taşınmaz, yeniden inşa edilmesi gerekir:

• Full-trust farm solution'lar (sunucu tarafında çalışan özel .dll kod) — SharePoint Online'da sunucu tarafı kod çalıştırma modeli yok.
• Üçüncü taraf eklentilerle (third-party tools) yapılan özelleştirmeler — hedefte karşılığı varsa SPFx (SharePoint Framework) ile yeniden yazılmalı.
• InfoPath formları — Microsoft InfoPath'i kademeli olarak emekliye ayırıyor; Power Apps'e geçiş planlanmalı.
• Desteklenmeyen özel site şablonları — SPMT taraması bunları önceden raporluyor, göç öncesi listeye alın.

Bu kalemler genelde göç projesinin en çok zaman alan kısmı; içerik taşıma birkaç gün sürerken özel kodun yeniden yazımı haftalar alabilir. Takvimi buna göre kurun.

Göç sonrası doğrulama, yaygın hatalar ve kullanıcı kabulü

İçerik taşındıktan sonra kapanış listesi:

1. Örnek doğrulama. Her site collection'dan rastgele 20-30 dosya/klasör seçip izin, sürüm geçmişi ve meta veri alanlarının doğru geldiğini tek tek kontrol edin.
2. Arama indeksleme. SharePoint Online'ın yeni içeriği indekslemesi saatler sürebilir; kullanıcıları "arama sonucu boş çıkıyor" şikâyeti gelmeden önce bilgilendirin.
3. Eski sunucu erişim loglarını izleyin. Kesmeden önce eski SharePoint sunucusuna hâlâ kimin, hangi uygulamanın bağlandığını (özellikle otomatik entegrasyonlar) loglardan görün — sessizce kapatılan bir sunucu, fark edilmeyen bir entegrasyonu kırabilir.

En sık yapılan hatalar: (1) özel kod envanterini atlayıp "içerik taşındı, iş bitti" sanmak, (2) devralınan izinleri hedefte de otomatik geleceğini varsaymak, (3) 400 karakter yol sınırını göç gecesi keşfetmek, (4) eski sunucuyu hiç erişim logu incelemeden kapatmak, (5) genel terim deposu göçü için kiracı genel yöneticisi izni almayı unutmak.

Türkiye'ye özgü katman: KVKK, VUK ve yerel gerçekler

KVKK ve yamasız sunucu riski

6698 sayılı Kişisel Verilerin Korunması Kanunu'nun (KVKK) 12. maddesi, veri sorumlusuna kişisel verinin güvenliği için "gerekli her türlü teknik ve idari tedbiri alma" yükümlülüğü getiriyor. 15 Temmuz 2026'dan sonra yamalanmayan, internete açık bir SharePoint sunucusu işletmek, bu yükümlülüğün karşısında savunulması zor bir pozisyondur — SharePoint geçmişte kimlik doğrulanmamış uzaktan kod çalıştırma zafiyetleriyle kitlesel saldırı hedefi olmuş bir üründür. SharePoint Online'a taşıyorsanız veri yurt dışına çıkacağından KVKK'nın 9. maddesi kapsamında uygun aktarım mekanizmasını (standart sözleşme dâhil) seçip VERBİS kaydınızı güncellemeniz gerekir. Microsoft Security çözümlerimiz kapsamında bu uyum katmanını göç projesine paralel kuruyoruz.

VUK 253 ve arşiv belgeleri

Vergi Usul Kanunu'nun 253. maddesi kapsamında ticari defter ve belgelerin saklama süresi göz önüne alındığında, SharePoint'te tutulan sözleşme, teklif ve e-fatura ekli yazışma arşivini göç sırasında düzenli bir kütüphane yapısına ve saklama (retention) politikasına bağlamak, sonradan toparlamaktan çok daha ucuzdur.

Yerel gerçekler

• Yerli ERP entegrasyonu. Logo Tiger, Netsis veya Mikro üzerinden SharePoint'e otomatik yüklenen fatura/irsaliye dosyalarınız varsa, dosya adlandırma kuralınızı (genelde tarih + belge no formatı) göç öncesi yasaklı karakter listesiyle karşılaştırın — ERP tarafında değişmeyen bir format, hedefte reddedilme riski taşır.
• UPN ve dosya adında ç/ğ/ı/ö/ş/ü. Şirket içi ortamda Türkçe karakterli dosya adları yıllarca sorunsuz çalışmış olabilir; taşıma sırasında kodlama (encoding) farkları nedeniyle bozulma riski var. Küçük bir örneklem taşıyıp görsel olarak doğrulamadan büyük hacme geçmeyin.
• Bant genişliği. Türkiye'de Azure bölgesi bulunmadığından trafik Batı Avrupa'ya çıkar. 2 TB'lık bir içerik havuzunun taşınma süresini hesaplarken hat hızınızı ve şube bağlantılarınızı dikkate alın.

Saha vakası: 120 kişilik üretim firması, SharePoint 2016'dan SharePoint Online'a

Durum: Tek sunuculu SharePoint Server 2016 çiftliği, 3 site collection, yaklaşık 2,1 TB içerik, kalite/İK süreçlerinde kullanılan 6 adet SharePoint Designer 2013 iş akışı ve düzensiz klasör adlandırması (yıllarca birikmiş dosya sunucusu alışkanlığı). Firma, 15 Temmuz 2026 tarihini SPSE lisans yenileme teklifi gelene kadar fark etmemişti.

Süre: 6 hafta.

Karar noktaları:

• Mevzuata dayalı bir "veri yurt içinde kalsın" zorunluluğu olmadığı için SharePoint Online'a göç kararı hızlı alındı; SPSE'nin yıllık lisans yenileme yükü de bu kararı destekledi.
• SPMT taraması, 3 sitede toplam 14 desteklenmeyen web part ve 2 full-trust çözüm tespit etti; bunlar göç öncesi devre dışı bırakıldı, ikisi SPFx ile yeniden yazıldı.
• 6 iş akışından 5'i SPMT ile otomatik Power Automate'e taşındı; biri (çoklu onay zincirli, karmaşık bir İK süreci) elle yeniden kuruldu.
• Dosya adlandırma taraması, 340 dosyada yasaklı karakter veya 400 karakteri aşan yol tespit etti; bunlar göç öncesi toplu script ile normalleştirildi.

Sonuç: Sıfır içerik kaybı, kademeli (site site) kesme ile toplam kesinti süresi 3 saat, eski sunucu erişim logları bir hafta izlendikten sonra güvenle kapatıldı.

Xen ekibinin rolü: Envanter ve tarama, dosya adı normalizasyonu, SPMT görev yapılandırması, workflow doğrulama ve kesme gecesi nöbeti. Firmanın BT sorumlusu süreç boyunca ekiple birlikte çalıştı ve devri aldı.

Alan deneyimi notu: Bu projede en çok zamanı içerik taşıma değil, 14 desteklenmeyen web part'ın hangilerinin gerçekten kullanıldığını (kullanılmayanı silmek, yeniden yazmaktan ucuzdur) tespit etmek aldı. Kullanım analitiğine göç öncesi bakın.

Kendi ortamınızda kaç desteklenmeyen web part veya özel kod olduğunu bilmiyor musunuz? Uzmanla 15 dk görüş — ücretsiz bir SPMT taramasıyla gerçek tabloyu birlikte çıkaralım. Acil durumlar için WhatsApp'tan yazabilirsiniz.

Sıkça Sorulan Sorular (SSS)

SharePoint Server 2016/2019 desteği tam olarak ne zaman bitti?

Microsoft'un resmi yaşam döngüsü kaydına göre her iki sürümün de genişletilmiş desteği 15 Temmuz 2026 sabahı (Pasifik saatiyle 06:59) sona erdi. Bu tarihten sonra güvenlik yaması, hata düzeltmesi veya teknik destek verilmiyor.

Sunucumuz 15 Temmuz'dan sonra çalışmayı durdurdu mu?

Hayır, sunucunuz çalışmaya devam eder. Ancak yeni keşfedilen güvenlik açıkları için hiçbir yama almazsınız ve Microsoft'a destek bileti açamazsınız. SharePoint, geçmişte kitlesel saldırı hedefi olmuş bir üründür; bu KVKK 12. madde açısından da savunulması zor bir konumdur.

SPMT ücretsiz mi?

Evet. SharePoint Migration Tool, Microsoft'un ücretsiz resmi göç aracıdır; SharePoint Server 2010/2013/2016/2019'dan ve dosya sunucularından SharePoint Online, OneDrive ve Teams'e taşıma yapar. Lisans maliyeti hedefteki Microsoft 365 planınızdan gelir, araçtan değil.

Kaç günde göç tamamlanır?

İçerik hacmi, özel kod miktarı ve internet çıkış hızınız belirler. Basit, tek site collection'lı ve az özelleştirmeli kurumlar 1-2 haftada bitirebilir; birden çok site collection, özel kod ve workflow'u olan kurumlarda 4-8 hafta gerçekçi bir aralıktır. 2 TB üzeri içerik taşıyan kurumlar için kendi hattınıza göre bir plan çıkaralım: Ücretsiz fiyat teklifi alın.

SharePoint Designer workflow'larım göçte kaybolur mu?

Kaybolmaz ama otomatik taşınmaz — dönüştürülür. SPMT, SharePoint 2010 out-of-the-box iş akışlarını ve SharePoint Designer 2010/2013 workflow'larını Power Automate'e taşıyabiliyor. Karmaşık, çok adımlı onay zincirleri genelde elle doğrulama veya yeniden kurulum gerektirir.

SharePoint Online'a geçmek yerine SPSE'ye yükseltmek daha mı kolay?

SharePoint 2019'dan SPSE'ye yerinde yükseltme görece düşük risklidir çünkü SPSE, 2019'un kümülatif bir devamıdır. Ancak SPSE de artık abonelik modeliyle lisanslanıyor ve sunucu işletme yükünüz (donanım, yama, yedek, sertifika) aynen devam eder. Mevzuata dayalı somut bir "veri yurt içinde kalsın" zorunluluğunuz yoksa Microsoft'un da önerdiği yol SharePoint Online'dır.

Göç sırasında dosyalarımız neden reddediliyor?

En sık üç sebep: dosya/klasör adında yasaklı karakter (" * : < > ? / \ |), 400 karakteri aşan dosya yolu ve CON, AUX, _vti_ gibi yasaklı adlar. Göç öncesi bir tarama scriptiyle bunları tespit edip normalleştirmek, göç gecesi sürprizini önler.

Sonuç: 15 Temmuz geride kaldı, ama risk büyümeye devam ediyor

SharePoint Server 2016 ve 2019 için genişletilmiş destek 15 Temmuz 2026'da bitti ve bu, "ilerideki bir tarih" değil, artık geride kalmış bir gerçek. Sunucularınız çalışmaya devam ediyor olabilir ama her geçen hafta, yamalanmayan bir zafiyetin keşfedilme olasılığı artıyor — ve bu yalnızca bir BT riski değil, KVKK 12. madde kapsamında bir uyum riski.

İyi haber: karar aslında sadeleşti. Mevzuata dayalı somut bir zorunluluk yoksa hedef SharePoint Online; varsa hedef SharePoint Server Subscription Edition. SPMT, çoğu kurum için ücretsiz ve yeterli bir araç — asıl emek, içerik taşımaktan çok özel kod envanterini çıkarmak ve dosya adlandırma tuzaklarını göç öncesi temizlemekte.

Planı doğru sırayla kurun: envanter ve özel kod denetimi → dosya adı normalizasyonu → SPMT taraması → kademeli taşıma → doğrulama → eski sunucuyu erişim loglarını izleyerek kapatma. Bu sırayı atlamayan projelerde sıfır veri kaybı gerçekçi bir hedeftir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun SharePoint Server 2016/2019'dan SharePoint Online'a geçiş yolculuğunda envanter çıkarma, özel kod denetimi, SPMT ile kademeli taşıma ve göç sonrası doğrulamaya kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın; göç planınızı birlikte çıkaralım.