Dosya Sunucusundan SharePoint ve OneDrive’a Göç Planı

Dosya sunucusunu SharePoint’e “kopyalayıp geçmek” isteyen projeler genellikle kesimden iki hafta sonra geri döner: yol uzunluğu hataları, açılmayan Access veritabanları, kırılan Excel bağlantıları ve kimin neyi gördüğünü kimsenin bilmediği izinler. \\FS01\Ortak gibi yıllar içinde şişmiş bir paylaşım; ekip dokümanını, kişisel klasörleri, uygulama verisini ve arşivi aynı ağaçta tutar. Bu yüzden iş bir kopyalama değil, verinin yeniden sınıflandırılmasıdır. Aşağıda hangi verinin SharePoint’e, hangisinin OneDrive’a gideceğini, hangisinin şirket içinde kalacağını ve taşımanın sahada nasıl yürütüldüğünü sırasıyla anlatıyoruz.

Önce envanter, sonra plan

Göç planı paylaşım listesiyle değil, veri envanteriyle başlar. Her paylaşım için şunları çıkarın: toplam boyut, dosya ve klasör sayısı, son değişiklik tarihine göre dağılım, en derin klasör seviyesi, en uzun yol, dosya türleri, NTFS devralmasının kırıldığı noktalar ve paylaşımın sahibi olan iş birimi. Sahibi olmayan paylaşım göç edilmez; önce sahibi bulunur.

Son değişiklik tarihi kararın ana girdisidir. Yıllardır dokunulmamış veriyi aktif çalışma alanına taşımak aramayı kirletir, senkron yükünü artırır. Bu veri için ayrı bir arşiv sitesi ya da şirket içinde salt okunur bir arşiv çoğu zaman daha doğru adres olur.

Migration Manager ve SharePoint Migration Tool (SPMT) tarama (scan) raporu üretir; ama ilk fotoğrafı PowerShell ile çekmek, araç kurulmadan önce konuşulacak rakamları verir:

$kok = "\\FS01\Ortak"
Get-ChildItem -Path $kok -Recurse -File -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime, Extension |
  Export-Csv C:\Gocu\ortak-envanter.csv -NoTypeInformation -Encoding UTF8

# Uzantıya göre özet
Import-Csv C:\Gocu\ortak-envanter.csv |
  Group-Object Extension |
  Sort-Object Count -Descending |
  Select-Object -First 20 Name, Count

Büyük paylaşımlarda bu betik saatler sürer ve erişim reddedilen klasörleri sessizce atlar. Sahada en sık gördüğümüz hata, envanterin yetkisi eksik bir hesapla alınması ve “eksik” klasörlerin kesim gecesi ortaya çıkmasıdır. Çalıştıran hesabın tüm ağaca okuma yetkisi olduğunu önceden doğrulayın.

Hangi veri nereye: SharePoint, OneDrive, Teams veya şirket içi

Kural basit: ekibe ait olan ve ekip üyesi ayrıldığında kalması gereken veri SharePoint’e (çoğunlukla bir Teams ekibinin bağlı sitesine), tek kişinin çalışma dosyaları OneDrive’a gider. Kullanıcı ev klasörleri (home drive) doğal olarak OneDrive’a eşlenir.

Taşınmaması gereken veriler

• Çok kullanıcılı Access veritabanları (.accdb, .mdb): Dosya kilitleme ve eşzamanlı yazma SMB üzerinde çalışır. Senkronize bir kütüphane üzerinden çok kullanıcılı kullanım dosyayı bozabilir.
• Dış başvurulu CAD projeleri: AutoCAD xref’leri ve montaj dosyaları mutlak veya göreli yola bağlıdır. Yol değişince başvurular kırılır. Bu veri için SMB’yi koruyan Azure Files gibi bir çözüm daha uygundur.
• PST dosyaları: Microsoft ağ paylaşımı üzerinden PST kullanımını desteklemez; senkron istemcisi açık PST’yi eşitleyemez. PST’ler Exchange Online arşivine aktarılır.
• Uygulama veri klasörleri: ERP, muhasebe ve lisans sunucularının paylaşımda tuttuğu veri taşınamaz, çünkü uygulama UNC yolu bekler.

Uygulama klasörü SharePoint’e girmez. Nokta.

SMB’yi koruması gereken veriler için seçenekleri Azure Files ve Azure File Sync ile hibrit dosya sunucusu rehberinde ayrıca ele aldık.

Teknik sınırlar: yol uzunluğu, karakterler, dosya türleri

SharePoint ve OneDrive’da en sık takılınan sınır yol uzunluğudur. Çözümlenmiş toplam yol (site adresi, kütüphane, klasörler ve dosya adı dahil) 400 karakteri aşamaz. Dosya sunucusundaki \\FS01\Ortak\... önekinin yerine https://tenant.sharepoint.com/sites/Muhasebe/Shared Documents/... geldiği için şirket içinde sorunsuz görünen yol hedefte sınırı aşabilir. Senkron istemcisi dosyaları kullanıcının diskinde C:\Users\kullanici\Sirket Adi\Site - Kutuphane\... altında tutar; Windows tarafındaki eski uygulamaların uzun yol desteği burada ayrıca sorun çıkarır.

# Hedef önekini hesaba katarak uzun yolları bulma
$onek = "https://tenant.sharepoint.com/sites/Muhasebe/Shared Documents/"
Import-Csv C:\Gocu\ortak-envanter.csv | ForEach-Object {
  $goreli = $_.FullName.Substring("\\FS01\Ortak\".Length)
  [pscustomobject]@{ Yol = $_.FullName; HedefUzunluk = ($onek + $goreli).Length }
} | Where-Object HedefUzunluk -gt 350 |
  Export-Csv C:\Gocu\uzun-yollar.csv -NoTypeInformation -Encoding UTF8

Eşiği 400 yerine 350 seçmek, site veya kütüphane adı sonradan uzarsa pay bırakır. Diğer sınırlar:

• Dosya ve klasör adlarında " * : < > ? / \ | karakterleri kullanılamaz; baştaki ve sondaki boşluklar kabul edilmez.
• .lock, CON, PRN, AUX, NUL, COM0–COM9, LPT0–LPT9, _vti_, desktop.ini gibi adlar ve ~$ ile başlayan dosya adları engellidir.
• Tek dosya için üst sınır 250 GB’tır.
• Kütüphanede 5.000 öğelik liste görünümü eşiği vardır; çok dosya tek klasörde toplanacaksa görünümleri ve indeksli sütunları önceden planlayın.

Sınırlar zamanla güncellenir. Proje başında Microsoft’un “Restrictions and limitations in OneDrive and SharePoint” sayfasını yeniden kontrol edin.

NTFS izinlerinden SharePoint izinlerine eşleme

NTFS, klasör ağacının her seviyesinde devralmayı kırmaya izin verir; yıllar içinde dosya sunucularında yüzlerce istisna birikir. SharePoint’te izin site düzeyinde verilir: Sahipler, Üyeler ve Ziyaretçiler. Kütüphane düzeyinde istisna yönetilebilir. Klasör ve dosya düzeyinde kırılmış (unique) izinler ise hem yönetimi zorlaştırır hem de Microsoft’un bir kütüphane için önerdiği kırılmış izin sayısı sınırına yaklaştırır.

Sahada işleyen eşleme sırası:

1. Envanterde devralmanın kırıldığı tüm klasörleri listeleyin (Get-Acl çıktısında AreAccessRulesProtected değeri True olanlar).
2. Farklı erişim grubuna sahip her alt klasör için ayrı kütüphane veya ayrı site gerekip gerekmediğine iş birimiyle karar verin. Muhasebe paylaşımındaki “Bordro” klasörü ayrı bir kütüphane ya da ayrı bir site olmalıdır.
3. NTFS’te kullanıcıya doğrudan verilmiş izinleri gruplara dönüştürün. Hedefte Entra ID güvenlik grupları veya Microsoft 365 grupları kullanılır; senkronize edilen şirket içi AD grupları doğrudan kullanılabilir.
4. “Herkes” ve “Domain Users” gibi geniş izinleri hedefe kopyalamayın; site üyeliğiyle yeniden tanımlayın.

Migration Manager ve SPMT’de dosya paylaşımı izinlerini koruma seçeneği vardır. Bu seçenek ACL’leri yalnız hedefte karşılığı olan kimliklere eşler; eşleme dosyası (user mapping) olmadan yerel hesaplar ve silinmiş SID’ler taşınmaz. Site, kütüphane ve öğe düzeyindeki modelin nasıl kurulacağını SharePoint izin modeli tasarımı rehberi ayrıntılı anlatır.

Migration Manager ve SharePoint Migration Tool ile taşıma

Microsoft’un dosya paylaşımı için iki ücretsiz aracı var. Seçimi ölçek belirler:

Migration Manager’da agent’lar, şirket içi sunucu altyapısında dosya sunucusuna ağ erişimi olan Windows makinelere kurulur; görevler yönetim merkezinden dağıtılır. Agent’ı dosya sunucusunun üstüne değil, aynı ağdaki ayrı bir sunucuya kurun. Kopyalama yükü kullanıcıların açtığı dosyalarla yarışmaz.

Önerilen akış

1. Tarama: Tüm kaynakları yalnız tarama modunda çalıştırın. Rapor uzun yolları, geçersiz karakterleri ve erişilemeyen dosyaları gösterir.
2. Düzeltme: Yolları kısaltın, adları düzeltin, gereksiz veriyi silin veya arşive ayırın.
3. İlk kopya: Kullanıcılar dosya sunucusunda çalışırken tam kopyayı alın.
4. Artımlı geçişler: Aynı görevi yeniden çalıştırmak yalnız yeni veya değişmiş dosyaları taşır.
5. Kesim: Paylaşım salt okunur yapılır, son artımlı geçiş çalışır, kullanıcılar yeni konuma yönlendirilir.

Görev raporlarındaki başarısız öğe listesi kesimden önce sıfırlanmalı ya da her kalem bilinçli olarak dışarıda bırakılmalıdır. Taşıma süresi dosya sayısına, ortalama dosya boyutuna ve tenant tarafındaki kısıtlamaya (throttling) bağlıdır. Süreyi tahminle değil, pilot bir paylaşımda ölçüp kalan veriye oranlayarak verin. Küçük dosyalar yavaş taşınır.

OneDrive senkron istemcisi ve kullanıcı geçişi

Kullanıcının alıştığı sürücü harfi deneyimini OneDrive senkron istemcisi verir; fakat istemci sınırsız ölçeklenmez. Microsoft, senkronize edilen tüm kütüphanelerde toplam 300.000 dosyayı aşmamayı önerir. Departman sitelerinin tamamını herkese senkronize ettirmek bu sınırı hızla aşar; oturum açılışında yüksek CPU ve disk kullanımı şikâyeti destek hattına ilk hafta düşer.

• Files On-Demand açık olmalı; dosya yalnız açıldığında indirilir.
• Kütüphanenin tamamını senkronize ettirmek yerine “OneDrive’a kısayol ekle” ile yalnız gereken klasörleri kullanıcının OneDrive’ına ekletin.
• Known Folder Move ile Masaüstü, Belgeler ve Resimler klasörlerini Intune veya Group Policy üzerinden OneDrive’a yönlendirin. Ev klasörü göçüyle aynı döneme koymak kullanıcıya tek bir değişiklik yaşatır.
• Eski sürücü eşlemelerini kaldıran Group Policy tercihlerini ve oturum açma betiklerini kesim gününden önce hazırlayın.

Göç sonrası yedekleme ayrı bir karardır. SharePoint’in sürüm geçmişi ve geri dönüşüm kutusu yedeğin yerini tutmaz; bu konuyu Microsoft 365 yedekleme rehberinde ayrıntılı bulabilirsiniz.

Kesim günü kontrol listesi

• Tüm paylaşımlar için tarama raporu temiz; başarısız öğeler sıfır veya bilinçli olarak dışarıda bırakılmış.
• Hedef sitelerin sahipleri, üyeleri ve ziyaretçileri iş birimiyle doğrulanmış.
• Kaynak paylaşımlar NTFS düzeyinde salt okunur (yalnız paylaşım izni değil, NTFS yazma izni de kaldırılmış). Sadece paylaşım iznini kapatmak, sunucuya RDP ile bağlanan birinin yazmasını engellemez.
• Son artımlı geçiş tamamlanmış, kaynak ve hedef dosya sayıları karşılaştırılmış.
• Sürücü eşlemeleri kaldırılmış; OneDrive kısayolları ve Teams kanalları kullanıcılara duyurulmuş.
• Uygulama içi UNC bağlantıları (bağlantılı Excel çalışma kitapları, makrolar, kısayollar) için destek ekibine bilgi notu verilmiş.
• Eski sunucunun salt okunur kalacağı süre ve kapatma tarihi belirlenmiş; kapatmadan önce son tam yedek alınmış.

DFS Namespace kullanan ortamlarda kesim daha rahat yönetilir: namespace hedefleri değiştirilip kullanıcı yönlendirilebilir. Mevcut yapıyı DFS Namespace ve DFS Replication tasarımı yazısındaki kriterlerle değerlendirin. Veri sınıflandırması ve izin tasarımı adımlarında destek isterseniz Microsoft 365 ve bulut hizmetleri sayfamıza bakabilirsiniz. Araçların güncel özellikleri için Microsoft’un SharePoint Migration Tool dokümantasyonu esas alınmalıdır.

Sık sorulan sorular

Tüm dosya sunucusunu tek bir SharePoint sitesine taşımak doğru mu?

Hayır. Tek site ve tek kütüphane; kırık izinlere, aşırı yüklenen senkron istemcisine ve görünüm eşiklerine takılmaya yol açar. Paylaşımları sahiplik ve erişim grubuna göre ayrı sitelere ve kütüphanelere bölmek yönetimi kolaylaştırır.

Taşıma sırasında kullanıcılar dosya sunucusunu kullanmaya devam edebilir mi?

Evet. İlk tam kopya kullanıcılar çalışırken alınabilir. Kesimden önceki artımlı geçişler yalnız değişen dosyaları taşır; kesim gecesi paylaşım salt okunur yapılır ve son artımlı geçiş çalıştırılır.

NTFS izinleri SharePoint’e birebir taşınmalı mı?

Araçlar izinleri koruma seçeneği sunar, ama derin ve öğe düzeyinde kırılmış izinleri aynen taşımak SharePoint’te yönetilemez bir yapı bırakır. İzinleri site ve kütüphane düzeyinde, grup tabanlı yeniden tasarlamak ve istisnaları ayrı kütüphanelere almak daha sürdürülebilirdir.

Göçten sonra eski dosya sunucusu ne zaman kapatılmalı?

Paylaşımlar salt okunur yapıldıktan sonra bir süre erişilebilir kalmalı; açılış istekleri ve uygulama bağımlılıkları izlenmeli, ardından son yedek alınıp sunucu kapatılmalıdır. Bu süreyi iş birimleriyle önceden kararlaştırmak sürprizleri azaltır.