Dosya Sunucudan SharePoint Online'a Taşıma Nasıl Yapılır? (2026)

Xen Bilişim ekibi · Microsoft Bulut Çözüm Ortağı (CSP Direct Partner, 2016'dan beri) · MS-100/MS-102/AZ-104 sertifikalı danışmanlar · 25+ yıl saha deneyimi

Özet (TL;DR): Dosya sunucunuzdaki (file server / "Z: sürücüsü") klasörleri SharePoint Online'a taşımak için Microsoft'un iki resmi aracı var: küçük ve tek seferlik taşımalarda ücretsiz SharePoint Migration Tool (SPMT), büyük ve sürekli senkronize göçlerde sunucuya kurulan ajan tabanlı Migration Manager. Migration Manager artık dosya başına 250 GB'a kadar taşımayı destekliyor, Windows dosya izinlerini SharePoint rollerine otomatik eşliyor ve pilot grup → dalgalar halinde taşıma → tek seferlik kesim (cutover) yöntemiyle veri kaybı riskini en aza indiriyor. Bu rehberde adım adım kurulumu, Türkçe karakter/dosya adı tuzaklarını ve VUK + TTK saklama süresi uyumunu somut biçimde anlatıyoruz. Kendi başınıza mı yapacaksınız yoksa desteğe mi ihtiyacınız var — ölçmek için ücretsiz geçiş fizibilite analizi alın.

Neden bu geçiş 2026'da öncelikli?

Türkiye'deki çoğu KOBİ ve orta ölçekli kurumun hâlâ bir "Z: sürücüsü" vardır — ofis ağındaki bir Windows sunucusunda barınan, yıllar içinde büyümüş, kimin hangi klasöre erişebildiği artık net olmayan bir dosya yığını. Bu sunucuların büyük kısmı Windows Server 2016 üzerinde çalışıyor ve Microsoft'un resmi duyurusuna göre Windows Server 2016'nın genişletilmiş desteği 12 Ocak 2027'de sona eriyor — yani bu yazının yayınlandığı tarihte geriye 5 aydan az bir süre kalmış durumda. Destek bittiğinde güvenlik yamaları da (Azure Arc üzerinden satın alınan ücretli ESU — genişletilmiş güvenlik güncellemesi — paketi dışında) kesiliyor; dosya sunucusu gibi kritik bir bileşeni yamasız bırakmak ciddi bir risk.

Aynı zamanda donanım yenileme (yeni sunucu, yeni yedekleme sistemi, yeni RAID diski) maliyeti ile SharePoint Online'a taşınıp donanımı tamamen ortadan kaldırmanın maliyeti karşılaştırıldığında, çoğu kurumda ikincisi hem daha ucuz hem daha az operasyonel yük çıkarıyor — sunucu bakımı, yedekleme, güvenlik yaması, elektrik/soğutma gibi kalemler tamamen ortadan kalkıyor. Bu yazı bir "neden geçmeli" tartışması değil; geçiş kararı verilmiş bir ekip için Microsoft'un resmi dokümantasyonuna dayanan, adım adım uygulanabilir bir metodoloji. Kaynak: Microsoft'un resmi "Migrate file shares to SharePoint and OneDrive" rehberi (son güncelleme: 30 Nisan 2026). Benzer bir metodolojiyi bulut tabanlı kaynaklar için uyguladığımız Google Workspace'ten Microsoft 365'e geçiş yazımızda da anlattık.

Ön gereksinimler: başlamadan önce netleştirin

Taşımaya başlamadan önce dört konuyu netleştirmeniz gerekir:

• Yetki: Hedef tarafta SharePoint yönetici (admin) yetkisi; kaynak tarafta taşınacak tüm dosya paylaşımlarına okuma (Read) erişimi olan bir Windows hesabı gerekir.
• Hedef mimari: Hangi klasör nereye gidecek? Tek kişiye ait dosyalar OneDrive'a, ekip/proje klasörleri paylaşımlı bir SharePoint kütüphanesine (veya Teams sitesine) taşınmalı. Bu haritalamayı taşımadan önce Excel'e dökün.
• Envanter: Toplam veri boyutu, dosya sayısı, en derin klasör yolu uzunluğu ve kaç ayrı paylaşım (share) olduğu — bunlar hem süre tahminini hem araç seçimini belirler.
• Depolama kotası: Kiracınızın (tenant) toplam SharePoint depolama alanı taşınacak veriyi karşılıyor mu, kontrol edin; gerekiyorsa ek depolama satın alın.

Bu envanteri çıkarmak sandığınızdan uzun sürer — kimin hangi klasörde "sahibi" olduğu, hangi klasörlerin yıllardır açılmadığı genelde belgeli değildir. Microsoft 365 danışmanlığı hizmetimiz kapsamında bu envanter çıkarma adımını genelde ilk günde tamamlıyoruz.

Hangi aracı kullanmalısınız? SPMT mi Migration Manager mı?

Microsoft iki ayrı ücretsiz araç sunuyor; hangisini seçeceğiniz taşımanın büyüklüğüne bağlı. (Not: Microsoft'un eski bulut taşıma aracı Mover 31 Ekim 2024'te tamamen emekliye ayrıldı ve yerini Migration Manager aldı — hâlâ Mover öneren eski rehberlere veya tekliflere dikkat edin.)

Kriter	SharePoint Migration Tool (SPMT)	Migration Manager
Kurulum yeri	Kendi bilgisayarınıza (masaüstü uygulaması)	Sunucu/VM üzerine "ajan" olarak
Dosya başına boyut limiti	15 GB'a kadar	250 GB'a kadar
Ölçek	Küçük/orta, tek seferlik taşıma	Çok sayıda paylaşım, büyük veri, sürekli senkron
İlerleme takibi	Yerel uygulama ekranı	SharePoint yönetim merkezi (merkezi, çoklu ajan)
Otomasyon	Sınırlı (PowerShell modülü var)	PowerShell cmdlet + toplu (bulk) görev + delta senkron

Pratik kural: tek bir paylaşım, birkaç yüz GB altındaysa SPMT yeterli ve daha hızlı kurulur. Birden fazla şube/departmanın paylaşımı, 1 TB üstü veri veya haftalar süren bir proje söz konusuysa Migration Manager'ın ajan mimarisi ve merkezi izleme paneli işi çok daha sağlam yönetir. Bu yazının geri kalanı Migration Manager'a odaklanıyor çünkü orta-büyük ölçekli kurumsal taşımaların çoğunda tercih edilen bu.

Büyük ölçekli projelerde bir ayrıntı daha var: Migration Manager varsayılan olarak taşıma sırasında içeriği Microsoft'un kendi geçici Azure depolama alanında tutar, ama isterseniz kendi Azure depolama hesabınızı ajan yapılandırma dosyasında tanımlayıp geçici depolamayı kendi kiracınızda tutabilirsiniz — özellikle veri egemenliği/uyum gereksinimi sıkı kurumlarda tercih edilen bir seçenek.

Adım adım: Migration Manager ile taşıma

Kaynak: Microsoft'un resmi "Setup Migration Manager agents" ve "How to use Migration Manager" dokümantasyonu.

1. Ajanı kuracağınız sunucu/VM'i seçin. Bu makine dosya paylaşımlarına ve internete erişebilmeli; çalışma klasörü için (raporlar, geçici dosyalar) en az 150 GB boş disk alanı ayırın.
2. SharePoint yönetim merkezinde "Migration center"a girin ve "Dosya paylaşımları için" bölümünden ajan kurulum dosyasını indirin.
3. Kurulum sırasında iki ayrı kimlik bilgisi girilir: hedef için SharePoint yönetici hesabı, kaynak için tüm paylaşımlara okuma erişimi olan bir Windows hesabı. (Not: üçüncü taraf çok adımlı kimlik doğrulama — MFA — şu an ajan kurulumunda desteklenmiyor, bu yüzden ayrı bir hizmet hesabı kullanmanız önerilir.)
4. Küçük bir test göçüyle hızınızı ölçün. Microsoft'un tavsiyesi: 1 ajanla 20-30 görevlik bir test çalıştırıp geçen süreyi kaydedin, sonra toplam veri hacminize göre kaç ajana ihtiyacınız olduğunu hesaplayın. Gereğinden fazla ajan kullanmak, API isteklerini artırıp kısıtlamaya (throttling) yol açabilir.
5. Migration center'da "Görev ekle" (Add task) ile bir taşıma görevi oluşturun. Kaynak alanına paylaşım yolunu \\sunucuadi\paylasim\ biçiminde girin, hedefte SharePoint sitesi/kütüphanesi, OneDrive veya Teams kanalı seçin.
6. Ayarları gözden geçirin ("Tüm ayarlar" bölümü) — geçersiz karakter değiştirme kuralı, tarih/dosya türü filtreleri, izin ayarları burada yapılandırılır.
7. "Şimdi çalıştır" ile görevi kuyruğa alın. Her ajan kuyruğunda aynı anda en fazla 10 görev taşıyabilir; görevler otomatik olarak uygun ajanlara dağıtılır, manuel atama yapılmaz.
8. İlerlemeyi ve raporları Migration center'dan izleyin. Tarama (scan) raporu, taşımadan önce hangi dosyaların sorunlu olduğunu (geçersiz karakter, aşırı uzun yol, kilitli dosya) gösterir — taşımadan önce mutlaka inceleyin.

2026'da eklenen iki pratik yenilik göç sürecini hızlandırıyor: gecikmeli senkron (delta sync) artık artımlı (incremental) taşımaları çok daha hızlı yapıyor, ve dosya paylaşımı görevlerini yönetmek için artık PowerShell cmdlet desteği var — büyük ölçekli, otomasyona dayalı projelerde elle tıklama yerine script ile toplu görev oluşturabilirsiniz.

İzin (permission) eşleştirmesi: Windows'tan SharePoint'e

Dosya sunucusundaki erişim izinleri (kimin okuyabildiği, kimin düzenleyebildiği) otomatik olarak SharePoint rollerine eşlenir, ama birebir aynı kalmaz — aşağıdaki tabloyu göçten önce ekibinizle paylaşın:

Windows dosya paylaşımı izni	SharePoint'te karşılığı
Tam denetim (Full control)	Tam denetim
Değiştir (Modify) / Yaz (Write)	Katkıda bulun (Contribute)
Okuma ve yürütme / Klasör içeriğini listeleme / Okuma	Oku (Read)

Dikkat edilmesi gereken üç nokta var: (1) Taşıma sonrası, birden fazla iznin çakıştığı yerlerde en kısıtlayıcı izin geçerli olur. (2) Açık reddetme (explicit deny) kuralları taşınmaz — dosya sunucusunda birine özellikle erişim reddettiyseniz, bu kural SharePoint'te kaybolur ve içerik yanlışlıkla erişilebilir hale gelebilir; taşımadan önce bu kuralları ayrıca listeleyip yeniden uygulamanız gerekir. (3) Gelişmiş NTFS (Windows'un dosya sistemi izin modeli) ayarlarının tamamı kaldırılır, sade bir SharePoint rolüne indirgenir. Bu üç noktayı atlayan ekipler, göçten haftalar sonra "bu klasörü kim görebiliyor?" sorusuyla karşılaşıyor — göç sonrası ortaya çıkan erişim sorunlarının somut örnekleri için SharePoint dış paylaşımda erişim reddedildi hatası yazımıza da göz atabilirsiniz.

Dosya adı, boyut ve yol uzunluğu tuzakları

SharePoint, Windows dosya sunucusundan daha kısıtlayıcı bir dosya adlandırma kuralına sahip. Taşımadan önce şu listeyle kaynağınızı tarayın:

• Yasak karakterler: " * : < > ? / \ | — ayrıca dosya/klasör adının başında veya sonunda boşluk olamaz.
• Yasak dosya/klasör adları: CON, PRN, AUX, NUL, COM0-COM9, LPT0-LPT9, adının herhangi bir yerinde _vti_ geçen dosyalar, desktop.ini, ~$ ile başlayan dosyalar.
• Dosya yolu (path) uzunluğu: Site adresi + kütüphane + klasör + dosya adı toplamda 400 karakteri geçemez. Derin iç içe klasör yapılarında (örn. "Projeler\2024\Firma Adı\Teklif Dosyaları\Revizyon 3\...") bu limit sık aşılır.
• Dosya boyutu: Tek dosya yükleme/senkron limiti 250 GB.

Türkçe karaktere dair iyi haber: ç, ğ, ı, İ, ö, ş, ü harfleri Microsoft'un yasaklı karakter listesinde yer almıyor — dosya/klasör adında Türkçe kullanmak başlı başına bir engel değil. Pratikte gördüğümüz asıl risk farklı: (1) Türkçe klasör isimleri genelde daha uzun olduğu için 400 karakter yol limitine daha hızlı çarpıyorsunuz ("Muhasebe\Faturalar\2024\Ocak-Şubat-Mart Dönemi Kesilen Faturalar\..." gibi yapılar kolayca 300+ karaktere ulaşır); (2) bazı eski NAS/dosya sunucusu yazılımları büyük/küçük harfe duyarlıyken (case-sensitive) SharePoint duyarlı değildir — "İstanbul Şube" ve "istanbul şube" adlı iki ayrı klasörünüz varsa taşımada çakışma yaşarsınız. Taramayı (scan) mutlaka çalıştırıp raporu okuyun; Migration Manager, geçersiz karakterleri önceden tanımladığınız bir karakterle otomatik değiştirme ayarı da sunuyor.

Pilot göç → tam göç → tek kesim (cutover) stratejisi

Microsoft'un resmi tavsiyesi, tüm kurumu tek seferde taşımak değil, kademeli bir yaklaşım:

1. Pilot grup seçin — küçük bir ekip (10-20 kişi), tercihen teknolojiye yatkın ve geri bildirim verecek kişilerden.
2. Pilot göçü artımlı (incremental) yöntemle çalıştırın — arka planda, kullanıcıyı etkilemeden. Bu aşamada dosya sunucusu hâlâ ana kaynak, SharePoint'e sadece kopyalama yapılıyor.
3. Pilottan öğrenin — performans, kullanıcı geri bildirimi, izin sorunları burada ortaya çıkar; iletişim şablonunuzu (kullanıcıya gönderilecek e-posta/duyuru) buna göre güncelleyin.
4. Kalan kullanıcıları dalgalar halinde taşıyın — departman veya şube bazında, yine artımlı yöntemle.
5. Tek bir "kesim" (cutover) günü belirleyin. Bu günde eski dosya sunucusu salt-okunur yapılır veya tamamen kapatılır, herkes SharePoint/OneDrive'a yönlendirilir. Microsoft, tüm kullanıcılar için tek bir kesim olayı önerir — aksi halde kullanıcılar aynı dosyanın hem eski hem yeni kopyasını güncellemeye devam eder ve hangisi doğru bilinmez.

50-150 kullanıcılık orta ölçekli bir kurumda bu süreç gerçekçi olarak 3-5 hafta sürer; süreyi belirleyen en büyük değişken toplam veri boyutu ve paylaşım sayısıdır, kullanıcı sayısı değil.

Doğrulama ve yaygın hatalar

Taşıma tamamlandıktan sonra atlanmaması gereken kontroller:

• Dosya sayısı ve toplam boyut karşılaştırması — kaynak ile hedefteki rakamlar tutmalı; Migration Manager'ın özet raporu (summary report) bunu otomatik gösterir.
• Örnek kullanıcı testi — pilot grubun her biri kendi eski dosyalarını yeni konumda bulup açabildiğini doğrulamalı.
• İzin örnekleme testi — hassas bir klasörü (örn. İK, muhasebe) seçip beklenmeyen kişilerin erişimi olup olmadığını kontrol edin (açık reddetme kurallarının taşınmadığını hatırlayın).

En sık görülen üç hata: (1) SharePoint/OneDrive hesaplarını önceden sağlamadan (pre-provision) göçe başlamak — hedef mevcut değilse görev başarısız olur; (2) çok fazla ajan kullanıp gereksiz API kısıtlamasına (throttling) takılmak; (3) kesim gününü kullanıcılara önceden duyurmadan dosya sunucusunu kapatmak — bu, yardım masasını (helpdesk) o gün "dosyalarım kayboldu" talepleriyle doldurur, oysa dosyalar sadece yeni bir adreste duruyordur.

Türkiye'ye özgü noktalar: VUK + TTK saklama süreleri, KVKK ve saha vakası

Genel Microsoft rehberleri Türkiye'ye özgü iki noktayı hiç ele almaz, ama yerel mevzuatı olan bir kurum için bunlar taşıma planının parçası olmalı:

• Saklama süresi ikilemi: Vergi Usul Kanunu'nun (VUK) 253. maddesi, defter tutmakla yükümlü olanların düzenledikleri/aldıkları belgeleri ilgili yılı takip eden takvim yılından itibaren 5 yıl saklamasını zorunlu kılar. Türk Ticaret Kanunu'nun (TTK) 82. maddesi ise ticari defter ve belgeler için 10 yıl saklama öngörür — ticari uyuşmazlıklarda delil niteliği taşıdıkları için süre daha uzun. Pratikte çoğu kurum daha uzun olan TTK süresini (10 yıl) esas alır. SharePoint'te bu, ilgili kütüphaneye 10 yıllık bir saklama etiketi (retention label) uygulayarak — belgeyi bu süre boyunca silinemez/değiştirilemez hale getirerek — karşılanır. Etiketleme adımları için hassasiyet etiketi rehberimize bakabilirsiniz.
• KVKK veri konumu: Kişisel veri içeren klasörleri taşırken (İK, müşteri dosyaları) kiracınızın veri bölgesini (data region) ve Microsoft'un Avrupa Birliği Veri Sınırı (EU Data Boundary) kapsamını teyit edin — göç projesine başlamadan önce netleştirilmesi gereken bir konu, sonradan değiştirilmesi zor.

Saha vakası: 45 kişilik bir mali müşavirlik ofisinin dosya sunucusu göçü

Firma X — 45 kişilik bir mali müşavirlik/muhasebe ofisi — 12 yıllık bir Windows dosya sunucusunda müşteri dosyalarını, faturaları ve Logo Tiger muhasebe yazılımından dışa aktarılan raporları saklıyordu. Karar noktaları şunlardı: (1) sunucu Windows Server 2012 R2 üzerindeydi ve desteği çoktan bitmişti, (2) TTK gereği 10 yıllık saklama zorunluluğu vardı ama dosya sunucusunda otomatik bir saklama/silme politikası yoktu — hangi dosyanın ne zaman silinebileceği hiç belli değildi, (3) Logo Tiger'dan alınan aylık raporlar manuel olarak paylaşılan klasöre kopyalanıyordu.

Süre: 4 hafta. İlk hafta envanter (2,1 TB, ~380.000 dosya) ve klasör haritalama; ikinci ve üçüncü hafta 3 dalga halinde pilot + tam göç; dördüncü hafta kesim günü ve 10 yıllık saklama etiketinin müşteri klasörlerine uygulanması. Sonuç: göç sonrası dosya kaybı bildirilmedi; en büyük sürtünme noktası 380 bin dosyanın taranması sırasında bulunan ~4.200 adet geçersiz karakterli/aşırı uzun yollu dosyaydı — bunlar Migration Manager'ın otomatik karakter değiştirme ayarıyla çözüldü.

Xen ekibinin rolü: envanter ve klasör haritalama, ajan kurulumu, saklama etiketi tasarımı ve Logo Tiger rapor klasörünün SharePoint'e otomatik senkron edilmesi. Uyarı: 300.000+ dosyalı taşımalarda tarama (scan) aşaması tek başına birkaç gün sürebilir — bunu takvime baştan koyun, son haftaya sıkıştırmayın.

Sıkça Sorulan Sorular (SSS)

Dosya sunucusundan SharePoint Online'a taşıma ne kadar sürer?

Birkaç yüz GB'lık tek bir paylaşım SPMT ile birkaç günde taşınabilir. 1-3 TB arası, çok departmanlı bir kurumda Migration Manager ile gerçekçi süre 3-5 haftadır. Süreyi belirleyen en büyük değişken toplam veri boyutu ve dosya sayısıdır, kullanıcı sayısı değil.

Migration Manager ücretsiz mi?

Evet, Migration Manager Microsoft 365 aboneliğinize dahildir, ek lisans gerektirmez. Maliyet çıkan kalem genelde ajan kurulacak sunucu/VM kaynağı ve projeyi yönetecek zaman/uzmanlıktır.

Taşıma sırasında dosya kaybı yaşanır mı?

Doğru planlanmış bir göçte (tarama raporu önceden incelenmiş, izinler test edilmiş, tek kesim günü belirlenmiş) veri kaybı beklenmez. "Kayıp" olarak bildirilen vakaların büyük kısmı, dosyanın aslında farklı bir SharePoint kütüphanesine/klasöre taşınmış olması ya da geçersiz karakter nedeniyle dosya adının otomatik değiştirilmiş olmasıdır.

Eski dosya sunucusunu ne zaman kapatmalıyım?

Tüm dosyalar taşınıp doğrulandıktan, izinler test edildikten ve en az 1-2 hafta sorunsuz kullanım gözlemlendikten sonra. Ara adım olarak sunucuyu tamamen kapatmadan önce salt-okunur (read-only) yapmak, olası bir sorun çıkarsa eski veriye hâlâ erişim sağlar.

Türkçe karakterli dosya adları sorun çıkarır mı?

Karakterlerin kendisi (ç, ğ, ı, ö, ş, ü) sorun değil — SharePoint'in yasaklı karakter listesinde yer almazlar. Asıl risk, Türkçe klasör adlarının genelde daha uzun olması nedeniyle 400 karakterlik yol uzunluğu limitine daha çabuk ulaşmaktır. Taramayı (scan) çalıştırıp raporu kontrol etmek bu riski taşımadan önce ortaya çıkarır.

VUK ve TTK'ya göre kaç yıl saklama yapmalıyım?

VUK 253. madde 5 yıl, TTK 82. madde 10 yıl öngörür. Ticari belgeleriniz her iki kapsama da girdiğinden pratikte daha uzun olan 10 yıllık süreyi esas almak, her iki mevzuata karşı da güvenli taraftır. SharePoint'te bu bir saklama etiketiyle otomatikleştirilebilir.

Kendi ekibimizle mi yapmalıyız yoksa uzman desteği mi almalıyız?

Tek bir paylaşım, birkaç yüz GB altında bir taşımayı teknik bilgisi olan bir yönetici SPMT ile kendi başına yürütebilir. Çok departmanlı, 1 TB üstü, saklama etiketi ve yerli yazılım (Logo Tiger, Netsis, Mikro Fly) entegrasyonu gerektiren projelerde uzman desteği hem süreyi kısaltır hem izin/veri kaybı riskini azaltır. WhatsApp'tan yazarak ortamınıza göre ön değerlendirme alabilirsiniz.

Sonuç: Doğru planlanan bir dosya sunucusu göçü sorunsuz geçer

Dosya sunucusundan SharePoint Online'a taşıma, Microsoft'un resmi araçlarıyla (SPMT veya Migration Manager) ve pilot → dalgalar → tek kesim metodolojisiyle izlendiğinde, teknik olarak zorlu değil planlama açısından titizlik isteyen bir projedir. Asıl risk araçtan değil, atlanan adımlardan doğar: tarama raporunu okumadan taşımaya başlamak, açık reddetme izinlerinin taşınmadığını unutmak, veya kesim gününü duyurmadan sunucuyu kapatmak.

Türkiye'de faaliyet gösteren bir kurum için bu listeye iki madde daha eklenir: VUK/TTK saklama süresi uyumu ve KVKK veri konumu teyidi. Windows Server 2016'nın desteğinin Ocak 2027'de bitmesiyle birlikte, hâlâ eski bir dosya sunucusunda çalışan kurumlar için bu planlamayı şimdi başlatmak, son ana bırakmaktan çok daha ucuza geliyor.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun dosya sunucusundan SharePoint Online'a taşıma yolculuğunda envanter çıkarmadan saklama etiketi tasarımına, izin testinden kesim günü planlamasına kadar uçtan uca destek sağlıyoruz. Microsoft 365 çözümlerimizi inceleyin veya iletişim sayfamızdan bize ulaşın; TL faturayla CSP paketimizi görün, kur farkını biz üstlenelim.