ManageEngine Service Desk Plus'tan geçiş — saha rehberi

Her ITSM geçişi küçük bir arkeoloji projesidir. On yıllık talep geçmişi, üç-dört nesil özel alan, yalnızca mali yılsonu dondurma döneminde geçerli olan yarı unutulmuş bir SLA kuralı — tümünün taşınması gerekir; aksi hâlde operasyon ekibi kurumsal hafızasını kaybeder. Bu rehber, elindeki ManageEngine Service Desk Plus (SDP) kurulumunu bir sonraki yenileme döngüsünden önce LinaDesk'e taşıması istenen mühendis veya BT yöneticisi için yazılmıştır.

Şu varsayımlarla ilerliyoruz: SDP on-premise (Build 14xxx veya 15xxx), 5.000 ile 200.000 arasında geçmiş talep, Active Directory destekli kullanıcı deposu ve birkaç e-posta/LDAP entegrasyonu. SDP MSP sürümünüz varsa veya CMDB modülünün yoğun kullanıldığı Enterprise sürümü çalıştırıyorsanız aşağıdaki eşleme genişletilmelidir; ancak işin şekli aynı kalır.

Kurumların SDP'den neden ayrıldığı

Mekaniklerden önce gerekçeler — çünkü eşleme kararlarını bunlar belirler. Pratikte, SDP'den LinaDesk'e geçişi başlatan ekipler şunlardan bir veya birkaçında birleşir:

• KVKK ve veri ikametgahı. SDP'nin bulut sürümü Türkiye dışındaki Zoho altyapısında yer alır. On-premise sürüm bu açıdan sorunsuz, ancak lisans modeli müşterileri yenilemede buluta yönlendirir. KVKK 9. madde (yurt dışına aktarma) kapsamındaki Türk kurumları, zorlanmış bulut geçişine karşı sigorta olarak Türkiye kontrolünde bir on-premise tedarikçi tercih eder.
• Teknisyen başına maliyet eğilimi. SDP'nin teknisyen başına fiyatı 2022'den bu yana istikrarlı biçimde arttı ve modüler fiyatlandırma (değişiklik, proje, CMDB için eklentiler) birikir. Sabit lisanslı bir alternatif, yenileme dönemi sürprizlerini ortadan kaldırır.
• Arayüz ve klavye kısayolu ergonomisi. SDP'nin arayüzü Linear döneminin tasarım normlarından önceye tarihlenir. Kuyrukta gün boyu yaşayan L1 teknisyeni olan ekipler bunu her gün hisseder.
• Air-gap veya gizli ağ kurulumları. Kamu ve savunma müşterileri SDP'nin bulut eklentilerini çalıştıramaz; istenen her yetenek çevre içinde çalışmak zorundadır.

Gerekçe önemlidir çünkü neyin taşınacağını belirler. KVKK odaklı bir geçiş genellikle her şeyi korur çünkü denetçi soracaktır. Maliyet odaklı bir geçiş kimsenin kullanmadığı özellikleri seve seve geride bırakır.

Aşama 1 — Keşif (2 hafta)

Keşif aşaması, ITSM geçişinin iki en kötü sonucunu önlemek için vardır: önemli olduğu sonradan ortaya çıkan eksik veri ve çöp olduğu sonradan ortaya çıkan taşınmış veri. İki hafta uzun görünür — değildir.

SDP kurulumunun envanterini çıkarın

Dürüst bir envanter alın. SDP yönetim konsolundan aşağıdakileri ortak bir tabloya kaydedin:

• Toplam talep sayısı; duruma (Açık, Beklemede, Çözüldü, Kapatıldı) ve oluşturma yılına göre bölünmüş hâlde.
• Kullanımdaki tüm talep şablonları — kimin oluşturduğunu kimsenin hatırlamadıkları dahil.
• Modül bazında tüm özel alanlar. Alanın tipi, zorunlu olup olmadığı ve hangi şablonların ona atıfta bulunduğu.
• İş saatleri tanımları, tırmandırma seviyeleri ve eşleşme kriterleriyle birlikte tüm SLA politikaları.
• Tüm otomasyon kuralları (Business Rules, Field & Form Rules, Custom Triggers, Time Triggers).
• Tüm e-posta şablonları ve bildirim kuralları.
• Tüm onay iş akışları.
• İzin eşlemeleriyle birlikte tüm roller.
• Her entegrasyon: LDAP/AD, e-posta sunucuları, SCCM/prob'lar, üçüncü taraf API'ler.

Çıktı bir doküman değil — bir karar listesidir. Her madde taşı, yeniden kur veya bırak olarak etiketlenir. Pratik kural: son on iki ayda bir şablon veya özel alan üçten az talepte kullanıldıysa bırakmak için adaydır.

Operasyon ekibiyle görüşün

Keşif yalnız yönetim konsolu yürüyüşü değildir. Üç L1 teknisyeni, bir L2 lideri ve servis masası yöneticisiyle oturun. Haftalık hangi raporları açtıklarını, hangi makroları kullandıklarını ve hangi alanları alışkanlıkla boş bıraktıklarını sorun. Kimsenin açmadığı gösterge panelleri, kimsenin ihtiyaç duymadığı alanlardır.

Entegrasyon bağımlılıklarını haritalayın

SDP çoğu zaman komşu sistemler için bir merkezdir: bir izleme aracı uyarıları talep olarak yazar, bir varlık tarayıcısı CI kayıtları oluşturur, bir bordro entegrasyonu İK işe alım taleplerini tetikler. Her biri ya LinaDesk API'sine yönlendirilmeli ya da geçiş sırasında duraklatılmalıdır. Birini kaçırırsanız Pazartesi sabahı yığınla sahipsiz talep sizi karşılar.

Aşama 2 — Veri eşleme

SDP'nin veri modeli ile LinaDesk'inki kuzendir, ikiz değil. Aşağıdaki tablo başlangıç noktası olarak kullandığımız eşlemedir; özelleştirme her zaman satır ekler.

Deneyimimize göre en çok mühendislik zamanı gerektiren satırlar özel alanlar, kategoriler ve SLA politikalarıdır. Geri kalanı mekaniktir.

Aşama 3 — Dışa aktarma

SDP'den veri çıkarmanın üç yolu vardır: yerleşik zamanlanmış dışa aktarımlar, REST API v3 ve doğrudan veritabanı erişimi. Üçünün de yeri var.

Yapısal veri için REST API v3

API; kullanıcılar, teknisyenler, gruplar, kategoriler, SLA politikaları ve tam alan kümesiyle almanız gereken her varlık için doğru kaynaktır. Uç noktalar stabildir, sayfalamaya saygı gösterirler ve hedef şemamıza temiz eşlenen JSON döndürürler.

Tüm talepleri sayfa sayfa çekip JSON dosyalarına yazan minimal bir PowerShell betiği:

# SDP TECHNICIAN_KEY okuma yetkili olmalı
$sdpUri  = "https://sdp.internal/api/v3/requests"
$authKey = $env:SDP_TECHNICIAN_KEY
$outDir  = "C:\migration\raw\requests"
New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$rowsPerPage = 100
$rowIndex    = 1

do {
  $inputData = @{
    list_info = @{
      row_count   = $rowsPerPage
      start_index = $rowIndex
      get_total_count = $true
      fields_required = @(
        "id","subject","description","status","priority",
        "created_time","resolved_time","closed_time",
        "requester","technician","group","category","subcategory","item",
        "udf_fields")
    }
  } | ConvertTo-Json -Depth 6 -Compress

  $resp = Invoke-RestMethod `
    -Uri "$sdpUri?input_data=$([uri]::EscapeDataString($inputData))" `
    -Headers @{ "authtoken" = $authKey } `
    -Method GET

  $resp.requests | ForEach-Object {
    $_ | ConvertTo-Json -Depth 12 |
      Out-File -Encoding utf8 "$outDir\req_$($_.id).json"
  }

  $total     = $resp.list_info.total_count
  $rowIndex += $rowsPerPage
} while ($rowIndex -le $total)

Kullanıcılar, gruplar ve varlıklar için eşdeğer betikler yapısal kopyalardır. Sürüm kontrolünde tutun — en az üç kez çalıştıracaksınız: kuru koşuda bir, provada bir, geçiş sırasında bir.

Arşiv ekler için doğrudan veritabanı okuması

SDP ekleri talep yükünün dışında saklar. API meta veriyi döndürür ama blob'ları değil. Baytların kendisi için ya kayıt başına dosya-ek uç noktasını kullanın (yavaştır ama izinlere saygı duyar) ya da SDP'nin FileAttachment tablosunu ve diskteki Attachments dizinini okuyun. Büyük kurulumlarda (100 binden fazla ekli talep) yalnızca ikincisi gerçekçidir — gecelik bir rsync planlayın.

Aşama 4 — Talep geçmişinin korunması

Geçişteki en önemli alan CreatedAtUtc'tir. Sessizce şimdi'ye varsayılan olursa on yıllık geçmiş tek bir güne sıkışır ve her SLA raporu anlamsızlaşır.

LinaDesk toplu içe aktarma uç noktası üzerinden geri tarihli talep oluşturmayı destekler. Kural:

Her talep, yorum, durum geçişi ve denetim kaydı kendi orijinal UTC damgasını taşır. İçe aktarma yolundaki hiçbir şey bunun üzerine yazamaz.

Somutlaştırırsak: SDP'nin created_time.value alanı milisaniye cinsinden Unix damgasıdır. UTC ISO-8601'e çevirin ve CreatedAtUtc olarak geçirin. Aynısını resolved_time, closed_time ve her bir notun oluşturulma damgası için yapın. Bir notun created_time'tan farklı bir updated_time'ı varsa ikisini de koruyun — denetim ekipleri arada bir kontrol eder.

İnce bir tuzak: SDP damgaları hesap saat diliminde saklanır fakat API tarafından yalnızca teknisyen anahtarının kullanıcısı UTC gösterim saat dilimindeyse UTC olarak raporlanır. Tüm ihracata güvenmeden önce üç bilinen kayda karşı bunu bir kez doğrulayın.

Aşama 5 — AD / LDAP yeniden eşleme

Geçişteki en zor birleştirme neredeyse her zaman kullanıcılardır. SDP bir kullanıcıyı dahili olarak REQUESTERID ile tanımlar. Active Directory aynı kişiyi objectGUID ile tanımlar. LinaDesk ise ExternalId kullanır (AD objectGUID'sine ayarlanmasını öneririz).

Geçiş, tek bir birincil anahtara güvenemez. Kullandığımız birleştirme, öncelik sırasına göre:

1. UPN (userPrincipalName). AD yeniden adlandırmalarına ve orman-arası taşımalara dayanır. Birincil birleştirme olarak kullanın.
2. E-posta adresi. UPN yoksa yedek olarak devreye girer.
3. sAMAccountName. Son çare; ormanlar arasında benzersiz olduğu garanti değildir.

Üç birleştirmede de başarısız olan her kullanıcı orphans.csv dosyasına düşer. Yaptığımız her gerçek geçişte bu dosya 20 ile 400 satır arasında oldu — şirketten ayrılan kişiler, AD'ye hiç bağlanmamış servis hesapları, 2018'de e-postayla tek talep açan kişiler. Kaderlerine elle karar verin. Bu adımı atlamayın: bu yetimler hâlâ geçmiş taleplerin sahibidir ve isimlerinin raporlarda doğru görünmesi gerekir.

Aşama 6 — SLA politikası yeniden eşleme

SDP'nin SLA modeli düz bir kural motorudur: talep kriterine göre eşleş, iş saati takvimine karşı yanıt/çözüm pencerelerini uygula. LinaDesk'in modeli yakındır ama aynı değildir:

• SDP Operational Hours ↔ LinaDesk WorkCalendar.
• SDP Holidays ↔ LinaDesk WorkCalendarHoliday.
• SDP SLA kriterleri ↔ LinaDesk SlaPolicyMatch koşulları.
• SDP Escalation levels ↔ LinaDesk SlaEscalation zinciri.

Anlamlı olan tek boşluk kısmi duraksamalar etrafındadır. SDP, talep Waiting for Requester iken SLA'nın duraklatılmasına izin verir. LinaDesk aynı davranışı SLA politikasında açık bir PauseOnStatus dizisi olarak modellemeyi gerektirir. Eşlemeyi geçiş betiğinde yapın, varsayılanların denk düşmesini ummayın — incelediğimiz her SDP kurulumunda varsayılan olmayan en az bir duraklatma durumu vardı.

SLA'nın takvim tarafına ilişkin daha uzun bir tartışma için SLA takvimi tasarımı yazımıza bakın — orada verilen modelleme kararları takvimi LinaDesk'te nasıl yeniden kuracağınıza doğrudan uygulanır.

Aşama 7 — Portal, marka, bildirim şablonları

Bunlar taşınmaz. Yeniden inşa edilir.

SDP'nin self-servis portalı ağır şablonlanmış bir Zoho stilinde kabuktur. LinaDesk'inki modern, bileşen tabanlı bir arayüzdür; aynı özellik yüzeyine sahiptir ama farklı bir yapıdadır. Görsel varlıkları (logo, favicon, marka renkleri) ve metinleri (karşılama mesajı, ana sayfa duyuruları, kategori açıklamaları) alın; bir tasarımcı iki gün boyunca portalı LinaDesk yönetim arayüzünde yeniden kursun.

Bildirim şablonları için hikâye aynıdır. Her e-posta şablonunu HTML artı değişken listesi olarak SDP'den çıkarın, sonra LinaDesk şablon editöründe yeniden kurun. LinaDesk değişken sözdizimi {{Ticket.Number}} tarzı; SDP'ninki $Request.RequestID. Sözdizimini makineyle çevirin; metni elle gözden geçirin.

Aşama 8 — Dört haftalık paralel çalışma

Tek bir hafta sonunda geçiş yapmak yazı-tura atmaktır. SDP ile LinaDesk'i dört hafta paralel çalıştırmak değildir — yazı-turayı mühendislik alıştırmasına çevirir.

Önerdiğimiz sıra:

1. -4. hafta: LinaDesk kuruldu. Geçmiş veri içe aktarıldı. Tüm L1 teknisyenlerinin girişleri var ve 90 dakikalık eğitim oturumu tamamladılar. E-posta yönlendirmesi hâlâ SDP'yi gösteriyor.
2. -3. hafta: Gecelik yeniden içe aktarma SDP delta API'sine karşı çalışır ve LinaDesk'i SDP'nin 24 saat içinde tutar. Teknisyenlerden günde on yeni talebi LinaDesk'te örneklemeleri ve hata bildirmeleri istenir. Portal kapalı kalır.
3. -2. hafta: Gelen e-postanın %15'i LinaDesk'e yönlendirilir. Teknisyenler her iki kuyruğu da yönetir. Raporlar çift üretilir ve karşılaştırılır.
4. -1. hafta: Gelenin %50'si LinaDesk'te. Portal küçük bir pilot talep sahibi grubuna beta açılır. P0/P1 fark saptanırsa geçiş bloke olur.
5. Geçiş hafta sonu: Son delta yeniden içe aktarma. E-posta yönlendirmesi %100 LinaDesk'e çevrilir. Portal tüm talep sahiplerine açılır. SDP salt okunur moda alınır; denetim için 90 gün çevrimiçi tutulur.

90 günlük salt okunur dönem önemlidir. Düzenleyiciler (ve iç denetim), zaman zaman bir talebin belirli bir tarihte kaynak sistemde nasıl göründüğüne bakmayı gerektiren sorular sorar. Geçişten bir gün sonra SDP'yi silmek iki kez tanık olduğumuz bir hatadır ve her ikisi de hukuki hold görüşmesiyle sonuçlandı.

Geçiş sonrası doğrulama kontrol listesi

Onay vermeden önce:

• Talep sayıları uyuşur: SDP.count(status=Closed, year=2024), LinaDesk.count(status=Closed, CreatedAtUtc 2024-01-01 ile 2024-12-31 arası) ile ±%0,1 içinde eşittir.
• Yetim talep sahipleri hesaplanmıştır: orphans.csv'deki her kullanıcı ya LinaDesk'te bir yer tutucuya sahiptir ya da açıkça hariç tutulmuştur ve geçmiş talepleri talep gövdesinde korunmuş talep sahibi adını gösterir.
• SLA rapor paritesi: önceki çeyreğin SLA uyum raporunu SDP'den ve LinaDesk'ten alın; sayılar ±%1 içinde olmalıdır. Daha büyük fark takvim veya duraksama durumu yanlış yapılandırmasına işaret eder.
• Ek bütünlüğü: son beş yıl içinden rastgele 200 talep örnekleyin ve her ekin açıldığını doğrulayın.
• Bilgi bankası araması: LinaDesk'te en çok görüntülenen beş bilgi makalesini arayın ve ilk beş sonuçta çıktıklarını doğrulayın.
• Entegrasyonlar: her yeniden yönlendirilmiş webhook, LDAP senkronizasyonu ve dış API çağrısının en az iki kez başarıyla tetiklendiği gözlemlenmiştir.

Sık karşılaşılan tuzaklar

SDP'de var olup LinaDesk v1'de olmayan özellikler

Dürüst liste. LinaDesk v1 şunları içermez:

• Proje yönetimi modülü. SDP'nin Projects alt modülünü SDP müşterilerinin yaklaşık %15'i kullanır; onlardan biriyseniz bu bir kapsam kararıdır, geçici çözüm değildir.
• MSP çok hesaplı kiracılık katmanı. LinaDesk tasarım gereği tek kiracılıdır — her müşteri kendi kurulumunu çalıştırır.
• Yerel mobil uygulama. LinaDesk web arayüzü mobil uyumlu, ancak yerel kabuk v1.2 yol haritasındadır, v1'de değil.

Bunlar operasyonunuz için taşıyıcı ise geçiş haftasından önce keşifte çözün.

Özel alan geçişini yetersiz kapsamlandırma

İncelediğimiz her geçişte geçmiş taleplerin %60'ında ama son yılın taleplerinin yalnızca %3'ünde doldurulmuş en az bir özel alan vardı. Biri yıllar önce kullanmayı bıraktı ve kimse kaldırmadı. Yine de taşıyın — sahipsiz veri de denetim görünür veridir.

SDP'nin "tarih aralığı" dışa aktarma arayüzüne güvenme

SDP dışa aktarma arayüzü bazı build'lerde sessizce 5.000 satırda, diğerlerinde 10.000'de tavan koyar ve hata vermez — yalnızca kırpılmış bir CSV. Birkaç yüz satırın üzerindeki her şey için her zaman API kullanın.

İlgili yazılar

• 2026'da on-premise ITSM neden yeniden gündemde
• Vardiya değişimlerine ve resmi tatillere dayanan SLA takvimi tasarımı
• LinaDesk vs ServiceNow, ManageEngine, Freshservice — karşılaştırma tablosu
• LinaDesk Güvenlik ve Uyumluluk