SharePoint'ten yeni bir intranete geçiş: neyi taşımalı, neyi bırakmalı?

SharePoint'ten geçiş, intranet projelerinin en sık karşılaşılan senaryolarından biri. Yıllar içinde büyümüş, kimsenin tam olarak bilmediği bir yapıdan yeni bir sisteme taşınmak, teknik olduğu kadar arkeolojik bir çalışma.

Önce envanter, sonra karar

Geçişin ilk adımı taşımak değil, ne olduğunu görmek. Çıkarılması gerekenler: kaç site var, kaç doküman kitaplığı, son 12 ayda hangileri açıldı, her birinin sahibi kim?

Tipik bulgu şu oluyor: içeriğin büyük kısmı yıllardır açılmamış, aktif kullanılan alan sanılandan çok daha küçük ve aynı dokümanın birden fazla sürümü farklı yerlerde duruyor.

Bu envanter, projenin kapsamını da belirliyor: 5.000 dokümanı taşımakla 400 dokümanı taşımak arasında ciddi fark var. Yöntemi intranet yeniden tasarımı yazısında ele aldık.

Dört karar kategorisi

Her içerik için:

Taşı. Güncel, sahipli ve kullanılıyor.

Güncelle ve taşı. Değerli ama eski; taşımadan önce sahibi güncellemeli.

Arşivle. Artık kullanılmıyor ama saklama yükümlülüğü var. Yeni sisteme taşınmıyor; salt okunur bir arşivde kalıyor. Süreleri doküman saklama politikası yazısında ele aldık.

İmha et. Saklama süresi dolmuş ve değeri kalmamış. KVKK açısından da gerekli bir adım; çerçeveyi KVKK veri işleme envanteri yazısında anlattık.

Dördüncü kategori genellikle en büyük olanı ve en çok direnç göreni. "Ne olur ne olmaz" refleksi, yeni sistemi ilk günden eski sistemin kopyası hâline getiriyor.

İzin yapısını yeniden kurmak

SharePoint kurulumlarında izinler genellikle yıllar içinde katmanlanmış durumda: site bazında, klasör bazında, hatta dosya bazında istisnalar.

Bu yapıyı olduğu gibi taşımak bir hata. Geçiş, izin modelini sadeleştirmek için en iyi fırsat: rol bazlı, anlaşılır ve yönetilebilir bir yapı kurmak.

Pratik yaklaşım: mevcut istisnaları tek tek taşımak yerine, sıfırdan bir rol matrisi tasarlayıp içeriği ona göre yerleştirmek. Yapıyı çalışan verisi ve yetki modeli yazısında ele aldık.

Örnek: 12 sitelik bir yapının sadeleşmesi

Bir şirkette SharePoint'te 12 departman sitesi, 40'tan fazla doküman kitaplığı ve iç içe geçmiş bir izin yapısı bulunuyor.

Envanter çıkarıldığında: 12 siteden 4'ü aktif, kitaplıkların çoğu yıllardır dokunulmamış, ve İK politikalarının üç farklı yerde üç farklı sürümü var.

Geçişte 4 aktif site taşınıyor, politikalar tek bir kaynakta birleştiriliyor (en güncel sürüm belirlenip diğerleri arşivleniyor), kalan içerik salt okunur arşive alınıyor.

Yeni sistem 300'den az sayfayla açılıyor. Lansman sonrası en sık gelen geri bildirim: "artık hangisinin güncel olduğunu biliyorum."

Buradaki asıl kazanç teknoloji değişikliği değil, çoklu sürüm kaosunun bitmesi.

Paralel çalışma dönemi

Eski sistemi hemen kapatmamak gerekiyor; ancak paralel dönem uzun sürerse iki yerde birden içerik yaşamaya başlıyor.

İşe yarayan kurgu: yeni sistem yayına alındığı andan itibaren eski sistem salt okunur hâle geliyor. Kimse eskiye yazamıyor, ama okuyabiliyor. Üç ay sonra tamamen kapatılıyor ve arşive alınıyor.

Bu kural, "eskiden devam edelim" alışkanlığını teknik olarak engelliyor.

Bağlantılar ve alışkanlıklar

Yıllar içinde biriken bağlantılar e-postalarda, dokümanlarda ve yer imlerinde duruyor. Kırılan her bağlantı, yeni sisteme duyulan güveni azaltıyor.

Mümkünse yönlendirme kurulmalı; kurulamıyorsa eski adreste "bu içerik taşındı" bilgisi ve yeni bağlantı bulunmalı.

Kimlik ve erişim tarafında yapılacaklar

SharePoint kurulumları genellikle kurumsal dizine (Entra ID / Active Directory) bağlı çalışıyor. Yeni sisteme geçerken bu bağın nasıl kurulacağı, projenin teknik omurgası.

Karar verilmesi gerekenler: kullanıcılar dizinden otomatik mi senkronlanacak, gruplar aktarılacak mı, tek oturum açma kurulacak mı, ve işten ayrılanların erişimi hangi mekanizmayla kapanacak?

Son madde en kritik: dizine bağlı bir yapıda ayrılan çalışanın erişimi merkezî olarak kapanıyor; bağımsız bir kullanıcı veritabanında ise elle kapatılması gerekiyor ve unutuluyor.

Yapıyı kimlik ve dizin entegrasyonu ve SSO nedir yazılarında ele aldık.

Geçiş ekibi ve roller

Geçiş projelerinin aksadığı en yaygın nokta, sahipliğin belirsiz olması. Gerekli roller: proje sahibi (karar verici), içerik koordinatörü (envanter ve taşıma kararları), teknik sorumlu (entegrasyon ve veri aktarımı) ve departman temsilcileri (kendi içeriklerinin kararını veren kişiler).

Son grup olmadan proje ilerlemiyor: merkezî ekip, bir departmanın dokümanının güncel olup olmadığını bilemiyor.

Sık sorulan sorular

İçerik otomatik taşınabilir mi? Kısmen: dokümanlar ve meta veriler aktarılabiliyor. Ancak SharePoint'e özgü yapılar (web parçaları, iş akışları, özel listeler) genellikle birebir taşınmıyor ve yeniden kurgulanması gerekiyor.

Teams ile ilişki ne olacak? Teams dosyaları SharePoint'te duruyor; geçiş kapsamının bu dosyaları içerip içermediği baştan netleştirilmeli. Ayrımı Teams varken intranete gerek var mı yazısında ele aldık.

Geçiş ne kadar sürer? Envanterin büyüklüğüne bağlı; ancak süreyi belirleyen şey teknik taşıma değil, karar verme: içerik sahiplerinin taşı/arşivle kararını vermesi genellikle en uzun adım.

Pilot yapılmalı mı? Evet, bir departmanla. Hem yöntemi test ediyor hem geçişin gerçek süresini gösteriyor; yöntemi intranet pilot projesi yazısında ele aldık.