Vantas Migration von über 128.000 Tickets zu Jira Service Management: Verlauf erhalten, Komplexität vereinfacht

Vanta, eine Agentic Trust Platform, migrierte über 128.000 Tickets, 512.000 Kommentare und 86.000 Anhänge von Freshservice zu Jira Service Management mit benutzerdefinierter Feldzuordnung und Beibehaltung der historischen Daten – die Migration wurde mit Help Desk Migration.

Über Vanta

Vanta ist die führende Plattform für agentenbasierte Vertrauensbildung. Sie wurde 2018 gegründet, um Unternehmen bei der Automatisierung von Compliance-Prozessen, dem Risikomanagement und dem kontinuierlichen Nachweis von Vertrauen zu unterstützen. Das Unternehmen entstand als Reaktion auf den wachsenden Bedarf an stärkerem Datenschutz und konzentrierte sich zunächst auf die Automatisierung von Compliance-Prozessen für Standards wie SOC 2, HIPAAund ISO 27001.

Vanta bietet heute eine KI-gestützte Plattform, die Unternehmen bei der kontinuierlichen Verwaltung von Sicherheit, Compliance und Risiken unterstützt. Über 15.000 Kunden, darunter Atlassian, Duolingo, Icelandair, Ramp und Synthesia, vertrauen auf Vanta. Die Plattform ermöglicht es Unternehmen, durch kontinuierliche Echtzeitprozesse Vertrauen aufzubauen, zu erhalten und nachzuweisen. Vanta konzentriert sich weiterhin darauf, Unternehmen beim Schutz ihrer Daten, der Optimierung von Compliance-Prozessen und dem Nachweis von Vertrauen in großem Umfang zu unterstützen.

Wir sprachen mit Janiece Caldwell, Leiterin des IT-Betriebs im Corporate Engineering Team von Vanta, über die Migration von Freshservice zu Jira Service Management . Sie verantwortet Helpdesk-Support, internes Ticketing und IT-Systeme mit Fokus auf Automatisierung, Skalierbarkeit und effiziente Servicebereitstellung. Janiece erläutert Vantas Migrationsziele, zentrale Herausforderungen und ihre Erfahrungen mit der Umstellung auf Jira Service Management im Rahmen der Help Desk Migration.

Warum Vanta sich für die Migration von Freshservice zu Jira Service Management entschieden hat

JSM ist unser internes Anfrageportal. Die IT nutzt es für Hardware-, Softwarezugriffs- und Fehlerbehebungsanfragen, aber es hat sich auch zur gemeinsamen Plattform für People Ops, Workplace, GTM-Systeme, HR und Zugriffsmanagement entwickelt. Praktisch jeder Vantan-Mitarbeiter nutzt es als Anfragender, und unsere IT-/Enterprise-Engineering-Mitarbeiter arbeiten täglich damit. Wir haben außerdem eine Slack-Integration, sodass Tickets bidirektional zwischen Slack und JSM synchronisiert werden.

Freshservice konnte mit unseren Anforderungen nicht mehr mithalten – Skalierbarkeit, Flexibilität und Integrationsmöglichkeiten reichten mit unserem Wachstum nicht mehr aus. Wir wollten bessere Arbeitsabläufe, aussagekräftigere Berichte und eine engere Abstimmung mit unseren übrigen Entwicklungs- und IT-Tools. Deshalb entschieden wir uns für den Wechsel zu JSM.

Herausforderungen

• Die Felder Freshservice und JSM stimmen nicht Feld für Feld überein.
• Auf jedem Ticket mussten die ursprünglichen Angaben zum Melder und Empfänger verbleiben.
• Katalogartikel, Genehmigungsprozesse und Automatisierungen mussten in JSM neu aufgebaut werden.
• Statt redundante oder veraltete Anfragetypen einfach zu replizieren, sollten diese entfernt werden.
• Eine Demo-Migration half dabei, frühzeitig Lücken zu erkennen, darunter Probleme bei der Zuordnung von Meldern und Bearbeitern, noch vor der vollständigen Migration.

Anpassungsmöglichkeiten + sofort einsatzbereite Migrationsoptionen, maßgeschneidert auf die Bedürfnisse von Vanta

Welche Daten waren in Jira Service Managementam wichtigsten zu erhalten?

Die Speicherung der Tickethistorie war für die Kontinuität und die Durchführung von Audits wichtig – als Compliance-Unternehmen ist die Anzeige von Zeitstempeln und Anfragehistorie beispielsweise für unser eigenes SOC 2 Audit unerlässlich. Zudem wollten wir sicherstellen, dass unsere Teams auch im neuen System weiterhin auf frühere Tickets zugreifen können und dieses interne Wissen nicht verloren geht.

Wie wichtig war die Möglichkeit, die Migration an die spezifischen Anforderungen Ihres Teams anzupassen, und welche Anpassungen waren für Sie am wertvollsten?

Anpassungen waren wichtig. Freshservice ließ sich nicht in allen Bereichen nahtlos auf JSM abbilden – beispielsweise mussten wir sicherstellen, dass die ursprünglichen Namen des Melders und des Bearbeiters übernommen wurden, obwohl JSM kein direkt entsprechendes Feld hatte.

Wir benötigten außerdem unsere Katalogartikel, Genehmigungsprozesse und Automatisierungen neu aufgebaut statt nur kopiert, da wir die Migration als Gelegenheit nutzten, redundante oder veraltete Anfragetypen zu bereinigen.

Die Demo-Migration ermöglichte es uns, die Feldzuordnung und Datenintegrität zu überprüfen, bevor wir die vollständige Migration der historischen Daten durchführten. Dabei wurden frühzeitig einige Lücken aufgedeckt – wie beispielsweise das Problem mit dem Feld „Melder/Bearbeiter“ –, die wir vor der eigentlichen Migration beheben konnten, anstatt sie erst im Nachhinein festzustellen.

Anpassungen, die entwickelt wurden, um die Daten und den Kontext von Vanta zu erhalten

Die Migration erforderte mehr als einen Standard-Datentransfer, um sicherzustellen, dass Freshservice -Daten mit der Jira Service Management Umgebung kompatibel sind. Die Migration wurde individuell angepasst, um wichtige Feldwerte, Genehmigungen, Serviceelemente, ursprüngliche Benutzerinformationen und die Autorenschaft von Agentenkommentaren zu erhalten. Diese maßgeschneiderten Zuordnungen sorgten außerdem dafür, dass die migrierten Daten strukturiert, durchsuchbar und für die Vanta-Teams in JSM einfach zu verwenden waren.

• Folgende Feldwerte werden in die Ticketbeschreibung migriert: Ursprüngliche ID, Gruppe, Quelle, Vorgangstyp, Vorgangstyp „Personen“, Vorgangstyp „Recht“, AWS-Rolle, Kategorie. Ist ein Quellfeld leer, wird es mit dem Wert „ leer“.
• Serviceelemente für Serviceanfragen (SRs) in die Ticketbeschreibung migrieren
• Genehmigungen in die Ticketbeschreibung migrieren , einschließlich Name des Genehmigenden, E-Mail-Adresse und Genehmigungsdatum.
• Die Felder „Bearbeiter“ und „Melder“ dürfen beim Erstellen von Tickets nicht übergeben werden . Setzen Sie das Ticket auf „Nicht zugewiesen“ und zeigen Sie in der Benutzeroberfläche „Anonym“ als Melder an
• Migrieren Sie den ursprünglichen Bearbeiter in ein benutzerdefiniertes „Ursprünglicher Bearbeiter“ und den ursprünglichen Anforderer in ein „Ursprünglicher Melder“ .
• Bei Kommentaren von Agenten fügen Sie bitte die Daten des ursprünglichen Verfassers am Anfang des Kommentars im folgenden Format hinzu: Vor- und Nachname email@vanta.com
• Identifizieren Sie das Mitarbeiter-Onboarding und übertragen Sie es in die Ticketbeschreibung.
• Formatieren Sie die Feldnamen in der Ticketbeschreibung fett.

Sofort einsatzbereite Migrationsoptionen für mehr Datenkontrolle

Die zusätzlichen Migrationsoptionen wurden genutzt, um sicherzustellen, dass wichtige Ticketinhalte nach der Migration weiterhin zugänglich und einfach zu verwalten sind. Eingebettete Bilder wurden als Ticketanhänge beibehalten, während benutzerdefinierte Tags die Identifizierung und Organisation migrierter Datensätze erleichterten.

• Inline-Bilder als Ticketanhänge migrieren: Bilder, die direkt im Ticketinhalt eingebettet sind, werden als separate Ticketanhänge übertragen, damit sie auch nach der Migration zugänglich bleiben.
• Fügen Sie ein neues Tag hinzu: Tickets werden anhand des Felds „Gruppe“ getaggt. Wenn keine Gruppe angegeben ist, fügen Sie das Tag „migrated-no group“ hinzu . Fügen Sie allen diesen Tags das Präfix „FS-“ hinzu
• Das Premium-Supportpaket beinhaltete die Remigration, was genau dem Bedarf des Vanta-Teams entsprach. Nach Abschluss aller erforderlichen Anpassungen und ersten Tests ermöglichte die Remigration die fehlerfreie Durchführung des finalen Transfers.

Ergebnis: Eine einheitliche JSM-Plattform mit intakten historischen Daten

Wir verfügen nun über eine einheitliche Plattform anstelle mehrerer Systeme, verbesserte Berichtsfunktionen und Automatisierung sowie eine Suchfunktion für historische Tickets im neuen Portal. Nach dem Start gab es eine übliche Eingewöhnungsphase, aber nichts Gravierendes – hauptsächlich erwartete Aufräumarbeiten.

Rückmeldung

„Von der ersten Phase bis zur vollständigen Umstellung dauerte das Projekt einige Monate. Wir gingen Anfang September mit JSM live und migrierten anschließend die bestehenden Tickets mit Help Desk Migration . Es dauerte etwas länger als ursprünglich geplant, aber die zusätzliche Zeit wurde genutzt, um die Zuordnung korrekt vorzunehmen, anstatt zu hetzen – im Nachhinein hat es sich gelohnt.“.

Ich würde Help Desk Migration anderen Teams empfehlen, die einen ähnlichen Schritt planen. Das Team war reaktionsschnell und hat eine wirklich komplexe, historische Migration überschaubar gemacht

Janiece Caldwell,
Leiterin IT-Betrieb, Unternehmensentwicklung bei Vanta

Verfasst von

Kvitoslava Martsynyshyn

Content-Marketing-Manager, Help Desk Migration

Kvitoslava ist Content-Marketing-Managerin und verantwortet das Marketing für Help Desk Migration. Sie erstellt umfassende Leitfäden, Checklisten und Landingpages und übersetzt technische Migrationsprozesse in klare, wertorientierte Botschaften.