Die Helpdesk-Migrations-Checkliste: alles prüfen, bevor Sie wechseln

Die meisten Helpdesk-Migrationen scheitern nicht beim Import. Sie scheitern drei Wochen früher, als niemand geprüft hat, ob der alte Tarif überhaupt einen Massenexport erlaubt – oder drei Wochen später, als sich der SLA-Report stillschweigend um zwei Stunden verschoben hatte und niemand erklären konnte, warum. Der Import selbst ist Mechanik. Entschieden werden Projekte an der Prüfarbeit drumherum.

Das hier ist die Master-Checkliste für genau diese Prüfarbeit – sortiert nach Etappen statt nach Kalendertagen. Ob Ihr Cutover ein einzelnes Wochenende dauert oder ein Monat Parallelbetrieb: Die Häkchen bleiben dieselben, nur der Kalender ändert sich. Arbeiten Sie die Liste von oben nach unten ab, und der Umzug wird langweilig planbar – genau das, was man sich von einem Projekt wünscht, das jede einzelne Kundenkonversation berührt.

Etappe 1: das Ziel prüfen, bevor Sie sich binden

Am günstigsten fängt man ein Problem vor der Vertragsunterschrift ab. Bestätigen Sie – mit Belegen statt mit Vertriebszusagen:

• Jeder Kanal, den Sie heute betreiben, hat ein Zuhause. E-Mail-Adressen, Website-Chat, Messenger, Social-DMs. Ein Kanal ohne Landeplatz wird zwei Tage vor dem Cutover zum Notfall.
• Die Integrationen, die Geld verdienen, existieren. Rechnungsabfragen, Bestellstatus, CRM-Sync. Nice-to-have-Integrationen können warten, umsatzrelevante nicht.
• Der Import deckt Ihre Objekte ab. Tickets, Kontakte, Artikel der Wissensdatenbank, Makros, Tags, benutzerdefinierte Felder – lassen Sie sich die Liste schriftlich geben und fragen Sie, was mit Anhängen passiert.
• Das Preismodell passt zum Zuschnitt Ihres Teams. Abrechnung pro Platz bestraft Wachstum, Pauschaltarife bestrafen sehr kleine Teams. Modellieren Sie Ihre Teamgröße in 12 Monaten, nicht die von heute.

Wenn Sie konkrete Anbieter gegeneinander abwägen, ist eine strukturierte Gegenüberstellung wie unser Freshdesk im Vergleich schneller als zwanzig Tabs voller Feature-Seiten.

Etappe 2: den Ausstiegspfad prüfen

Wie leicht Sie gehen können, entscheidet Ihr aktueller Helpdesk – und Sie wollen diese Antworten haben, solange Sie noch zahlender Kunde in gutem Stand sind:

• Kann Ihr aktueller Tarif Konversationen, Kontakte, Artikel und Makros im Massenexport ausgeben – oder liegt der Export hinter einer höheren Stufe?
• In welchen Formaten kommen die Exporte an, und enthalten sie Anhänge und eingebettete Bilder?
• Wann verlängert sich Ihr Vertrag, und wie viele Tage Frist verlangt die Kündigung? Fenster mit automatischer Verlängerung haben mehr Teams erwischt als jedes technische Problem.
• Was sagt die Richtlinie des Anbieters zur Datenlöschung nach dem Abschied? Eine Schonfrist ist Gold wert, wenn Sie etwas nachexportieren müssen.

Etappe 3: inventarisieren, was Sie tatsächlich besitzen

Gegen ein Inventar, das Sie nie erstellt haben, lässt sich keine Migration prüfen. Eine Person, ein Dokument, ein halber Tag:

• Jede E-Mail-Adresse, die in den Support weiterleitet – inklusive der Aliasse, die vor Jahren jemand angelegt und vergessen hat.
• Jede Widget-Installation samt ihren Seiten, jeder angebundene Messenger.
• Die Makro-Zählung: wie viele existieren und welche zehn wirklich genutzt werden.
• Automationsregeln – in Klartext aufgeschrieben, denn Regeln exportieren selten sauber, und undokumentierte sterben lautlos.
• Benutzerdefinierte Felder an Tickets und Kontakten, mit ihren Typen.
• Struktur der Wissensdatenbank: Kategorien, Artikelanzahl, Entwürfe gegenüber Veröffentlichtem.
• API-Verbraucher und Webhooks – alles, was programmatisch aus dem alten Helpdesk liest oder in ihn schreibt.

Etappe 4: den Importpfad Feld für Feld prüfen

Das ist die Etappe, die Teams überspringen – und genau sie entscheidet, ob Ihre Reports im nächsten Quartal noch etwas bedeuten:

• Bauen Sie eine Mapping-Tabelle: jedes Quellfeld auf sein Zielfeld, inklusive Typ. Ein Dropdown, das als Freitext ankommt, verfolgt Ihr Reporting ein Jahr lang.
• Legen Sie fest, wie sich Ticket-Status übersetzen – die meisten Tools kennen fünf bis sieben Zustände, und sie decken sich nie eins zu eins.
• Wählen Sie den Dublettenschlüssel für Kontakte (fast immer die E-Mail-Adresse) und entscheiden Sie, was gewinnt, wenn zwei Datensätze kollidieren.
• Bestätigen Sie, dass Anhänge und eingebettete Bilder in den Speicher des neuen Tools kopiert und nicht auf das alte verlinkt werden.
• Fahren Sie zuerst einen Probeimport von 50–100 Tickets. Prüfen Sie die Zeitstempel gegen die Quelle – eine stille Zeitzonenverschiebung verrückt jede SLA-Kennzahl um Stunden. Danach Threading, Urheberschaft und Unversehrtheit der Anhänge, bevor Sie den vollen Lauf starten.

Etappe 5: die technischen Nahtstellen prüfen

An den Nahtstellen zwischen Systemen versteckt sich die Ausfallzeit:

• E-Mail-Routing: die DNS-TTL Tage im Voraus senken und die Weiterleitung mit einer echten Nachricht Ende-zu-Ende testen.
• Widget-Tausch: Sie wissen genau, welcher Commit den Snippet ändert – und wer ihn deployen darf.
• Anmeldung: Bestätigen Sie, dass sich jeder Agent anmelden kann, vor dem Cutover-Tag und nicht an ihm.
• Webhooks und API-Verbraucher aus Etappe 3 zeigen ausnahmslos auf das neue Tool – eine Integration, die nach dem Cutover weiter in den alten Helpdesk schreibt, ist die klassische Quelle von Geistertickets.
• CSAT-Umfragen gehen aus dem neuen Tool raus und laufen in dessen Reporting ein.

Etappe 6: die menschliche Seite prüfen

• Rollen und Berechtigungen sind neu aufgebaut, mit mindestens zwei Admins.
• Ein einseitiger Spickzettel übersetzt alte Gewohnheiten in neue: wohin die Ansichten gewandert sind, wie eskaliert wird, welche Tastenkürzel jetzt gelten.
• Eine benannte Champion-Rolle pro Team – eine Person, die das Tool eine Woche früher lernt.
• Eine Personalplanung für die erste Woche, die einen moderaten Produktivitätsknick einkalkuliert, denn den wird es geben.

Etappe 7: den Cutover selbst prüfen

• Spielen Sie 25 Golden Tickets nach – echte Konversationen aus dem letzten Quartal – und lesen Sie jede Antwort kritisch.
• Proben Sie das Rollback: die zwei, drei Schritte, die das Routing zurückstellen, aufgeschrieben und mit benannter Verantwortung.
• Frieren Sie Konfigurationsänderungen im alten Tool während des Transferfensters ein, damit die Exporte konsistent bleiben.
• Bereiten Sie die Kundeninfo vor und halten Sie sie auf zwei Sätzen. Kunden interessiert die Antwortqualität, nicht Ihr Tooling.

Etappe 8: nach dem Go-live prüfen

Die Migration ist nicht mit dem Cutover fertig, sondern dann, wenn die Zahlen vertrauenswürdig sind:

• Beobachten Sie die Queue auf Geisterstille – ein Kanal, der null Tickets produziert, ist meistens fehlgeleitet und nicht ruhig.
• Prüfen Sie den ersten SLA-Report gegen die Basiswerte des alten Tools auf Plausibilität.
• Bestätigen Sie, dass die Suche migrierte Historie und Artikel findet.
• Halten Sie das alte Tool schreibgeschützt am Leben, bis der Abrechnungszeitraum endet, und bestätigen Sie die Kündigung anschließend schriftlich.

Die Kurzfassung auf einer Seite

Passung vor Vertrag. Ausstiegsbedingungen schriftlich. Vollständiges Inventar. Mapping Feld für Feld, mit Probeimport. Nahtstellen Ende-zu-Ende getestet. Team vorbereitet statt überrascht. Cutover geprobt, mit benannter Rollback-Verantwortung. Zahlen nach dem Go-live verifiziert. Acht Etappen, kein Heldentum.

Wo MoveDesk hineinpasst

MoveDesk existiert, weil diese Checkliste früher eine Beratung erforderte. Die White-Glove-Migration ist in jedem Tarif kostenlos: Unser Team übernimmt Export, Mapping und Import aus Zendesk, Intercom oder Freshdesk – Anhänge, Artikel, Makros und Historie inklusive –, während beide Tools so lange parallel laufen, wie Sie vergleichen möchten. Die 14-tägige Testphase reicht, um jede Etappe von oben an Ihren echten Daten durchzuarbeiten, bevor Sie sich zu irgendetwas verpflichten.

Drucken Sie die Checkliste aus, buchen Sie eine ruhige Woche und starten Sie bei Etappe 1. Teams, die zweimal prüfen, migrieren einmal.