Migration · 19. Sep. 2026 · 12 Min. Lesezeit

Migration von ManageEngine Service Desk Plus — ein Praxisleitfaden

Was mitgenommen werden sollte, was nicht, und wie sich der CSV-Export aus SDP nach LinaDesk skripten lässt, ohne die Benutzerhistorie zu beschädigen.

Jede ITSM-Migration ist ein kleines archäologisches Projekt. Zehn Jahre Ticket-Historie, drei oder vier Generationen benutzerdefinierter Felder, eine halb vergessene SLA-Regel, die nur während der Bilanzstichtags-Sperre greift — all das muss den Umzug überstehen, sonst verliert das Operations-Team sein institutionelles Gedächtnis. Dieser Leitfaden richtet sich an Ingenieure oder IT-Manager, denen eine ManageEngine-Service-Desk-Plus-Instanz (SDP) übergeben wurde, mit dem Auftrag, sie vor dem nächsten Verlängerungszyklus zu LinaDesk zu migrieren.

Wir gehen davon aus, dass Sie SDP On-Premise (Build 14xxx oder 15xxx) betreiben, irgendwo zwischen 5.000 und 200.000 historischen Tickets liegen, ein Active-Directory-gestütztes Benutzerverzeichnis vorhanden ist und eine kleine Handvoll E-Mail-/LDAP-Integrationen existiert. Falls Ihr SDP die MSP-Edition ist oder Sie Enterprise mit stark befülltem CMDB-Modul betreiben, muss die folgende Zuordnung erweitert werden — die Form der Arbeit bleibt aber gleich.

Warum Organisationen von SDP wegmigrieren

Vor den technischen Details die Gründe — denn sie prägen die späteren Zuordnungsentscheidungen. In der Praxis landen Teams, die eine SDP-zu-LinaDesk-Migration starten, bei einem oder mehreren der folgenden Punkte:

Der Grund ist entscheidend, weil er festlegt, was übernommen wird. Eine KVKK-getriebene Migration bewahrt in der Regel alles, weil Prüfer danach fragen werden. Eine kostengetriebene Migration lässt bereitwillig Funktionen zurück, die niemand nutzt.

Phase 1 — Discovery (2 Wochen)

Die Discovery-Phase existiert, um die zwei schlimmsten Ergebnisse einer ITSM-Migration zu verhindern: fehlende Daten, die sich später als wichtig erweisen und migrierte Daten, die sich als Müll erweisen. Zwei Wochen wirken lang — sie sind es nicht.

Die SDP-Instanz inventarisieren

Führen Sie eine ehrliche Bestandsaufnahme durch. Erfassen Sie aus der SDP-Admin-Konsole Folgendes in einer gemeinsamen Tabelle:

Das Ergebnis ist kein Dokument — es ist eine Entscheidungsliste. Jeder Eintrag wird mit mitnehmen, neu aufbauen oder verwerfen markiert. Eine Faustregel: Wurden in den letzten zwölf Monaten weniger als drei Tickets mit einer Vorlage oder einem benutzerdefinierten Feld erstellt, ist es ein Kandidat zum Verwerfen.

Das Operations-Team befragen

Discovery ist nicht nur ein Rundgang durch die Admin-Konsole. Setzen Sie sich mit drei L1-Technikern, einem L2-Lead und dem Service-Desk-Manager zusammen. Fragen Sie, welche Reports sie wöchentlich öffnen, welche Makros sie verwenden und welche Felder sie gewohnheitsmäßig leer lassen. Die Dashboards, die niemand öffnet, sind die Felder, die niemand braucht.

Integrationsabhängigkeiten kartieren

SDP ist häufig der Knotenpunkt für angrenzende Systeme: Ein Monitoring-Tool postet Alerts als Tickets, ein Asset-Scanner schreibt CI-Datensätze, eine Lohnbuchhaltungs-Integration löst HR-Onboarding-Requests aus. Jede davon muss entweder auf die API von LinaDesk umgestellt oder während des Cutovers pausiert werden. Wird eine übersehen, bringt der Montagmorgen einen Stapel verwaister Tickets.

Phase 2 — Datenzuordnung

Die Datenmodelle von SDP und LinaDesk sind Cousins, keine Zwillinge. Die folgende Tabelle ist die Zuordnung, mit der wir als Ausgangspunkt arbeiten; Anpassungen fügen stets weitere Zeilen hinzu.

SDP-EntitätLinaDesk-EntitätHinweise
RequestersUsers (Rolle: EndUser)Zuordnung über UPN, nicht über interne user_id — siehe AD-Abschnitt.
TechniciansUsers (Rolle: Technician)Techniker-Gruppenzugehörigkeit als LinaDesk Teams erhalten.
GroupsTeamsSDPs Support Group ↔ LinaDesk Team ist eine saubere 1:1-Zuordnung.
RequestsTicketsUrsprüngliches CreatedAt als CreatedAtUtc erhalten (siehe Backdating).
Request notesTicketCommentsPrivat/öffentlich-Kennzeichnung wird direkt übernommen.
Request attachmentsAttachmentsBlob-Speicherort ändert sich; URLs in Kommentartexten müssen umgeschrieben werden.
AssetsAssetsSDPs ProductType ↔ LinaDesk AssetCategory.
Asset Additional FieldsCustomFields (scope=Asset)Typzuordnung: SDP text → LinaDesk string; SDP picklist → LinaDesk enum.
Solutions (KB-Artikel)KnowledgeArticlesGenehmigungsstatus-Kennzeichnung erhalten.
Categories / Subcategories / ItemsCategory tree (verschachtelt)LinaDesk nutzt einen einzelnen verschachtelten Baum; SDPs dreistufige Aufteilung wird zu einem Pfad abgeflacht.
SLA PoliciesSlaPoliciesGeschäftszeiten wandern in WorkCalendar; siehe SLA-Abschnitt.
Business RulesAutomationsNeuimplementierung erforderlich — kein direkter Import.
Change requestsChangesCAB-Genehmigungsketten werden im ChangeApproval-Flow von LinaDesk neu aufgebaut.

Die Zeilen, die nach unserer Erfahrung den meisten Engineering-Aufwand erfordern, sind benutzerdefinierte Felder, Kategorien und SLA-Richtlinien. Alles andere ist mechanisch.

Phase 3 — Export

SDP bietet drei Wege, Daten herauszubekommen: die integrierten geplanten Exporte, die REST-API v3 und den direkten Datenbankzugriff. Alle drei haben ihre Berechtigung.

Die REST-API v3 für strukturierte Daten

Die API ist die richtige Quelle für Benutzer, Techniker, Gruppen, Kategorien, SLA-Richtlinien und jede Entität, die Sie mit vollständigem Feldsatz benötigen. Die Endpunkte sind stabil, unterstützen Paginierung und liefern JSON, das sauber auf unser Zielschema abgebildet werden kann.

Ein minimales PowerShell-Skript, das alle Requests seitenweise in ein Verzeichnis von JSON-Blobs zieht:

# requires SDP TECHNICIAN_KEY with read access
$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)

Die entsprechenden Skripte für Benutzer, Gruppen und Assets sind strukturelle Kopien. Halten Sie sie unter Versionskontrolle — Sie werden sie mindestens dreimal ausführen: einmal im Testlauf, einmal bei der Generalprobe, einmal beim Cutover.

Direkter Datenbankzugriff für archivierte Anhänge

SDP speichert Anhänge außerhalb der Request-Nutzlast. Die API liefert Metadaten, aber keine Blobs. Für die tatsächlichen Bytes nutzen Sie entweder den Dateianhang-Endpunkt pro Datensatz (langsam, aber berechtigungskonform) oder lesen direkt aus SDPs FileAttachment-Tabelle plus dem Attachments-Verzeichnis auf der Festplatte. Bei großen Instanzen (100.000+ Tickets mit Anhängen) ist Letzteres die einzig realistische Option — planen Sie einen nächtlichen rsync ein.

Phase 4 — Erhalt der Ticket-Historie

Das mit Abstand wichtigste Feld bei der Migration ist CreatedAtUtc. Fällt es stillschweigend auf jetzt zurück, komprimieren sich zehn Jahre Historie auf einen einzigen Tag, und jeder SLA-Report wird bedeutungslos.

LinaDesk unterstützt rückdatierte Ticket-Erstellung über seinen Bulk-Import-Endpunkt. Die Regel:

Jedes Ticket, jeder Kommentar, jeder Statusübergang und jeder Audit-Eintrag trägt seinen ursprünglichen UTC-Zeitstempel. Nichts im Importpfad darf ihn überschreiben.

Konkret: SDPs created_time.value ist ein Unix-Millisekunden-String. Konvertieren Sie ihn in UTC-ISO-8601 und übergeben Sie ihn als CreatedAtUtc. Machen Sie dasselbe für resolved_time, closed_time und den Erstellungszeitstempel jedes einzelnen Kommentars. Weicht bei einem Kommentar updated_time von created_time ab, bewahren Sie beide auf — Audit-Teams prüfen das gelegentlich.

Eine subtile Falle: SDPs Zeitstempel werden in der Kontozeitzone gespeichert, werden von der API aber nur dann in UTC ausgegeben, wenn der Benutzer des Techniker-Keys UTC als Anzeigezeitzone eingestellt hat. Prüfen Sie dies einmalig anhand von drei bekannten Datensätzen, bevor Sie dem gesamten Export vertrauen.

Phase 5 — AD-/LDAP-Neuzuordnung

Benutzer sind fast immer der schwierigste Join bei der Migration. SDP identifiziert einen Benutzer intern über seine REQUESTERID. Active Directory identifiziert dieselbe Person über ihre objectGUID. LinaDesk verwendet ExternalId (wir empfehlen, diese auf die AD-objectGUID zu setzen).

Die Migration kann sich nicht allein auf einen der beiden Primärschlüssel verlassen. Der Join, den wir verwenden, in Prioritätsreihenfolge:

  1. UPN (userPrincipalName). Übersteht AD-Umbenennungen und forestübergreifende Verschiebungen. Als primären Join verwenden.
  2. E-Mail-Adresse. Fallback, falls UPN fehlt.
  3. sAMAccountName. Letzte Option, da nicht forestübergreifend eindeutig garantiert.

Jeder Benutzer, der bei allen drei Joins scheitert, landet in einer orphans.csv-Datei. In jeder realen Migration, die wir durchgeführt haben, enthält diese Datei zwischen 20 und 400 Zeilen — Personen, die das Unternehmen verlassen haben, Service-Accounts, die nie mit AD verknüpft wurden, und Anfragende, die 2018 ein einziges Ticket per E-Mail eingereicht haben. Entscheiden Sie ihr Schicksal manuell. Überspringen Sie diesen Schritt nicht: Diese Waisen besitzen weiterhin historische Tickets, und ihre Namen müssen im Reporting korrekt erscheinen.

Phase 6 — SLA-Richtlinien-Neuzuordnung

SDPs SLA-Modell ist eine flache Regel-Engine: Zuordnung nach Request-Kriterien, Anwendung von Reaktions-/Lösungsfenstern gegen einen Geschäftszeitkalender. LinaDesks Modell ist ähnlich, aber nicht identisch:

Die eine relevante Lücke betrifft partielle Pausen. SDP erlaubt, die SLA zu pausieren, wenn das Ticket auf Waiting for Requester steht. LinaDesk verlangt, dasselbe Verhalten als explizites PauseOnStatus-Array in der SLA-Richtlinie zu modellieren. Führen Sie die Zuordnung im Migrationsskript durch, statt darauf zu hoffen, dass die Standardwerte passen — jede SDP-Instanz, die wir bisher gesehen haben, hatte mindestens einen nicht standardmäßigen Pause-Status.

Eine ausführlichere Diskussion der Kalenderseite des SLA-Designs finden Sie im Beitrag zum SLA-Kalenderdesign — die dort beschriebenen Modellierungsentscheidungen lassen sich direkt darauf übertragen, wie Sie den Kalender in LinaDesk neu aufbauen.

Phase 7 — Portal, Branding, Benachrichtigungsvorlagen

Diese werden nicht migriert. Sie werden neu aufgebaut.

SDPs Self-Service-Portal ist eine stark templategesteuerte, Zoho-gestylte Hülle. LinaDesks Portal ist eine moderne, komponentenbasierte Oberfläche mit demselben Funktionsumfang, aber anderer Struktur. Kopieren Sie die visuellen Assets (Logo, Favicon, Markenfarben) und die Texte (Willkommensnachricht, Startseiten-Ankündigungen, Kategoriebeschreibungen) und lassen Sie einen Designer zwei Tage lang das Portal in der Admin-Oberfläche von LinaDesk neu aufbauen.

Bei den Benachrichtigungsvorlagen verhält es sich genauso. Extrahieren Sie jede E-Mail-Vorlage aus SDP als HTML plus Variablenliste und bauen Sie sie dann im Vorlageneditor von LinaDesk neu auf. Die Variablensyntax von LinaDesk folgt dem Muster {{Ticket.Number}}; die von SDP lautet $Request.RequestID. Übersetzen Sie die Syntax maschinell; prüfen Sie die Texte manuell.

Phase 8 — Der vierwöchige Parallelbetrieb

Ein Cutover an einem einzigen Wochenende ist ein Münzwurf. SDP und LinaDesk vier Wochen lang parallel laufen zu lassen, ist das nicht — es macht aus einem Münzwurf eine Ingenieursaufgabe.

Unsere empfohlene Abfolge:

  1. Woche -4: LinaDesk ist bereitgestellt. Historische Daten sind importiert. Alle L1-Techniker haben Logins und eine 90-minütige Schulung absolviert. Das E-Mail-Routing zeigt noch auf SDP.
  2. Woche -3: Nächtliche Re-Importe laufen gegen SDPs Delta-API und halten LinaDesk innerhalb von 24 Stunden zu SDP synchron. Techniker werden gebeten, täglich zehn neue Tickets in LinaDesk stichprobenartig zu prüfen und Bugs zu melden. Das Portal bleibt dunkel.
  3. Woche -2: Fünfzehn Prozent der eingehenden E-Mails werden zu LinaDesk geroutet. Techniker bearbeiten beide Warteschlangen. Reports werden doppelt erzeugt und verglichen.
  4. Woche -1: Fünfzig Prozent der eingehenden E-Mails werden zu LinaDesk geroutet. Portal-Beta für eine kleine Gruppe von Pilot-Anfragenden geöffnet. Jede P0/P1-Abweichung blockiert den Cutover.
  5. Cutover-Wochenende: Finaler Delta-Re-Import. E-Mail-Routing wird zu 100 % auf LinaDesk umgestellt. Portal für alle Anfragenden geöffnet. SDP wird auf schreibgeschützt gesetzt und für 90 Tage zu Audit-Zwecken online gehalten.

Die 90-tägige Schreibschutz-Phase ist wichtig. Regulierungsbehörden (und interne Revisionen) stellen gelegentlich Fragen, die verlangen, wie ein Ticket im Quellsystem an einem bestimmten Datum aussah. SDP am Tag nach dem Cutover zu löschen, ist ein Fehler, den wir zweimal erlebt haben, und beide Male endete es in einem unangenehmen Legal-Hold-Gespräch.

Checkliste zur Validierung nach der Migration

Vor Ihrem finalen Sign-off:

Häufige Fallstricke

Funktionen, die es in SDP, aber nicht in LinaDesk v1 gibt

Die ehrliche Liste. LinaDesk v1 liefert nicht mit:

Ist eines davon geschäftskritisch für Ihren Betrieb, klären Sie das in der Discovery, nicht in der Woche vor dem Cutover.

Zu geringer Umfang bei der Migration benutzerdefinierter Felder

Bei jeder Migration, die wir untersucht haben, gab es mindestens ein benutzerdefiniertes Feld, das in 60 % der historischen Tickets, aber nur in 3 % der Tickets des letzten Jahres befüllt war. Jemand hat es vor Jahren aufgehört zu nutzen, und niemand hat es entfernt. Migrieren Sie es trotzdem — verwaiste Daten sind weiterhin auditrelevante Daten.

Der „Datumsbereich"-Export-UI von SDP vertrauen

Die Export-UI von SDP begrenzt in manchen Builds die Zeilenanzahl stillschweigend auf 5.000 und in anderen auf 10.000, und es gibt keine Fehlermeldung — nur eine abgeschnittene CSV-Datei. Verwenden Sie für alles über ein paar hundert Zeilen immer die API.

Sprechen Sie mit uns über Ihre SDP-Migration

Wir haben dieses Playbook in den letzten achtzehn Monaten viermal von Anfang bis Ende durchgeführt. Wenn Sie Ihre eigene Migration planen, führen wir Sie durch die Discovery-Vorlage, die wir verwenden.

LinaDesk-Team kontaktieren

Weiterführende Artikel