Von Zendesk Guide zu Document360 migrieren: Schritt für Schritt

Du hast dich entschieden, Zendesk Guide zu verlassen. Vielleicht ergaben die Preise pro Agent keinen Sinn mehr, als das Help Center über eine Handvoll Mitwirkende hinauswuchs. Vielleicht bist du an die Grenze von fünf Kategorieebenen gestoßen. Vielleicht fühlte sich der Editor irgendwann nicht mehr wie ein Doku-Werkzeug an, sondern wie ein Artikelfeld, das an eine Ticketplattform geschraubt wurde. Was auch der Auslöser war, die Frage ist jetzt mechanisch: Wie bewegst du die Inhalte nach Document360, ohne Suchplatzierungen zu verlieren, Bildverweise zu brechen oder sechs Monate angesammelten Verfall in ein neues Werkzeug auszuliefern?

Dieser Artikel ist der Schritt für Schritt. Sieben Phasen, zwei bis sechs Wochen von Anfang bis Ende, je nach Volumen. Die ersten sechs Phasen sind die Migration. Die siebte lassen die meisten Anleitungen aus: Ein sauberer Cutover ist der eine Moment im Jahr, in dem du den Kreislauf veraltender Dokumentation brechen kannst. Lass diesen Schritt aus, und du hast gerade einen hübscheren Editor bezahlt und dieselben veralteten Artikel, dieselben toten Links und dieselben überholten Screenshots behalten.

Der Plan unten geht davon aus, dass du zwischen 50 und 2.000 Artikel in Zendesk Guide hast, Administrationszugriff auf beide Plattformen und jemanden im Team, der JSON lesen kann. Document360 bietet außerdem einen vollständig begleiteten Migrationsdienst, bei dem das Team dort Export und Transformation übernimmt; wann sich das lohnt, klären wir später.

Warum Teams von Zendesk Guide zu Document360 wechseln

Zuerst die ehrliche Rahmung. Zendesk Guide ist in Ordnung. Es ist nicht das Problem. Das Problem ist, dass Zendesk Guide als Zusatz zur Ticketplattform bepreist und gebaut hat, nicht als Doku-Produkt. Drei Kräfte treiben Teams typischerweise Richtung Document360 oder ein vergleichbares Ziel.

Die erste ist der Preis. Zendesk Guide reitet auf einer Suite-Lizenz pro Agent. Sind deine Mitwirkenden nicht zugleich Vollzeit-Support, zahlst du für Kapazität, die du nicht nutzt. Document360 rechnet nach Teamplätzen plus Lesekapazität ab, was für dokumentationslastige Teams meist günstiger ausfällt. Die genauen Zahlen hängen vom Volumen ab, hol dir also vor der Entscheidung beide Preisseiten frisch. Für die Zendesk-Seite siehe die Preise von Zendesk Guide.

Die zweite ist der Funktionsumfang für Dokumentation. Document360 bietet Kategorien in sieben Ebenen gegenüber fünf bei Zendesk. Die Obergrenze für Kategorien auf oberster Ebene liegt bei 1.000 gegenüber 100 bei Zendesk. Document360 bietet zudem Bausteine zur Wiederverwendung (Vorlagen, Snippets, Variablen, Glossare), die Zendesk Guide nicht hat. Wächst dein Help Center über den Punkt hinaus, an dem Kopieren und Einfügen reicht, zählt der strukturelle Unterschied.

Die dritte ist der Editor. Zendesk Guide hat einen einzigen Rich-Text-Editor. Document360 bietet Markdown und WYSIWYG, dazu einen Kategoriebaum mit Drag-and-drop, der sich leichter umbauen lässt als das Modell aus Abschnitten und Kategorien bei Zendesk. Entwicklungsteams, die Artikel beisteuern, bevorzugen meist Markdown; Marketing und Support bevorzugen meist WYSIWYG; in Document360 koexistiert beides.

Was Document360 nicht löst: Dokumentation, die veraltet, weil niemand weiß, wann sich das Produkt so geändert hat, dass der Artikel gebrochen ist. Dieses Problem folgt den Inhalten. Ein Plattformwechsel behebt es nicht. Darauf kommen wir in Schritt 8 zurück.

Audit vor der Migration: was bleibt, was fliegt

Die erste Arbeit passiert in Zendesk, bevor du ein Exportwerkzeug anfasst. Mach ein Audit und schneide hart.

Zieh eine Liste aller veröffentlichten Artikel mit Aufrufen der letzten 90 Tage und dem Datum der letzten Änderung. Zendesk zeigt beides im Guide-Analytics-Dashboard. Sortiere die Liste und teile die Artikel in vier Gruppen:

• Unverändert behalten. Viel Traffic, kürzlich aktualisiert, sachlich korrekt gegen das aktuelle Produkt. Diese Artikel migrierst du zuerst, weil sie die Suchkraft tragen.
• Behalten und auffrischen. Viel Traffic, aber Produkt oder Preise haben sich seit der letzten Bearbeitung geändert. Markiere sie für eine Überarbeitung im Transformationsschritt.
• Archivieren. Wenig Traffic, keine jüngsten Änderungen, Verweise auf Funktionen, die es nicht mehr gibt, oder Preise, die sich zweimal geändert haben. Nicht migrieren. Sie drücken die Autorität und frustrieren Lesende.
• Ganz löschen. Interne Entwürfe, die nie live gingen, doppelte Artikel, aufgegebene Experimente. Lösche sie vor dem Export in Zendesk, nicht danach in Document360.

Ein typisches SaaS-Help-Center hat 20 bis 40 Prozent der Artikel in den unteren beiden Gruppen. Dieses Volumen vor der Migration zu schneiden ist der wirksamste Schritt im ganzen Prozess. Die nachgelagerte Arbeit (Transformation, Weiterleitungstabelle, Qualitätssicherung) skaliert linear mit der Artikelzahl.

Markiere beim Audit auch die Artikel mit eingehenden Links von Drittseiten. Nutze Ahrefs, Semrush oder den kostenlosen Bericht "Links" in der Google Search Console. Diese Artikel brauchen später Vorrang bei den Weiterleitungen: Sie tragen externe Linkkraft, die erhalten bleiben muss.

Schritt 1: Artikel aus Zendesk Guide exportieren

Zendesk hat keinen nativen Export für das Help Center per Klick. Du hast drei echte Optionen.

Option A. Die Help Center API von Zendesk. Das ist der offizielle und verlässlichste Weg. Die Endpunkte sind unter developer.zendesk.com dokumentiert. Zwei davon zählen:

Der erste listet jeden Artikel im Help Center. Der zweite listet nur Artikel, die nach einem Unix-Zeitstempel geändert wurden, was für spätere Teilabgleiche nützlich ist. Beide paginieren; Cursor-Paginierung ist bevorzugt und liefert bis zu 1.000 Artikel pro Seite. Die Authentifizierung läuft über API-Token oder OAuth. Für den inkrementellen Endpunkt brauchst du Agent- oder Administrationsrechte.

Jedes Artikelobjekt enthält id, title, body (HTML, nicht Markdown), locale, section_id, author_id, label_names, html_url, position und Zeitstempel. Das vollständige Schema steht in der Entwicklerdoku von Zendesk.

Ein Python-Skript mit 30 Zeilen reicht. Lauf durch den Paginierungscursor, schreib jeden Artikel als JSON auf die Platte (bewahrt alle Metadaten für spätere Transformationen) und als HTML (für den Textkörper). Zendesk veröffentlicht eine Referenzumsetzung in seiner Anleitung zur Sicherung.

Option B. Die App Swifteq Help Center Export im Zendesk Marketplace. Kostenlos, ohne Code. Exportiert nach CSV. Die Grenze: CSV flacht verschachtelte Struktur (Abschnitte, Kategorien) und Bildverweise ab, du baust also im Transformationsschritt einiges an Metadaten neu. Für kleine Bestände (unter 100 Artikel) in Ordnung, im Maßstab mühsam.

Option C. Der begleitete Migrationsdienst von Document360. Stell die Anfrage im Document360-Portal (Einstellungen, Knowledge base portal, Migrate content). Das Team dort nutzt dieselbe Help Center API plus eigene Werkzeuge, um die Inhalte zu ziehen. Du gibst Lesezugriff über ein Zendesk-API-Token. Das ist der aufwandsärmste Weg; der Handel sind Zeitplan (typischerweise einige Wochen Iteration) und weniger Kontrolle über die Transformationsentscheidungen.

Welchen Weg du auch wählst: Exportiere je Sprache einzeln. Ist dein Help Center mehrsprachig, mach zuerst die Hauptsprache, prüfe die gesamte Pipeline und wiederhole dann für jede Übersetzung.

Schritt 2: Inhalte transformieren

Der Export liefert rohe Inhalte. Die Transformation macht daraus etwas, das Document360 sauber aufnehmen kann. Vier Teilschritte.

Formatumwandlung. Die Textkörper in Zendesk sind HTML. Document360 nimmt HTML und Markdown. Nutzt dein Team den Markdown-Editor, lass das HTML durch einen Konverter laufen (pandoc, turndown oder eine beliebige Bibliothek). Die Umwandlung ist nicht perfekt: Die Rich-Text-Elemente von Zendesk enthalten Callouts, Hinweise und Akkordeons ohne sauberes Markdown-Pendant. Entscheide vorab, ob du sie als rohes HTML im Markdown behältst (Document360 unterstützt das) oder in native Blöcke umschreibst.

Bildadressen umschreiben. Jedes Bild in einem Zendesk-Artikel verweist auf eine Zendesk-CDN-Adresse (theme.zdassets.com oder ähnlich). Diese Adressen funktionieren nach der Migration weiter, bis sie es nicht mehr tun. Einträge im Zendesk-CDN können aufgeräumt werden oder ablaufen, und sobald dein Abo endet, verschwinden die Adressen ganz. Schreib jeden Bildverweis bei der Transformation auf eine in Document360 gehostete Adresse um. Die Mechanik: jedes referenzierte Bild herunterladen, in Document360 (oder dein eigenes CDN) hochladen und die Adressen im Artikel-HTML ersetzen.

Interne Links umschreiben. Artikel verlinken auf Artikel. In Zendesk sehen diese Links so aus: https://deinesubdomain.zendesk.com/hc/en-us/articles/123456-article-slug. Nach der Migration nutzen die Adressen in Document360 eine andere Pfadstruktur. Baue beim Import eine Zuordnungstabelle (Zendesk-Artikel-ID zu Document360-Artikel-ID) und führe eine Suchen-und-Ersetzen-Operation über alle Artikeltexte aus. Ohne diesen Schritt lieferst du ein Help Center aus, in dem jeder Querverweis kaputt ist.

Kategorien abbilden. Zendesk nutzt ein Dreiebenenmodell (Kategorie, Abschnitt, Artikel). Document360 nutzt einen Kategoriebaum mit bis zu sieben Ebenen. Flach klopfen oder erweitern, wie es passt. Das häufigste Muster: Jede Zendesk-Kategorie wird eine Document360-Kategorie oberster Ebene, jeder Zendesk-Abschnitt wird eine Unterkategorie, und Artikel liegen darunter. Hat dein Help Center Abschnitte uneinheitlich genutzt, ist jetzt der Moment, die Taxonomie zu reparieren. Zur Frage, wie das Ziel strukturiert sein sollte, siehe wie du eine SaaS-Wissensdatenbank aufbaust.

Schritt 3: Import nach Document360

Document360 bietet zwei Importwege.

Den begleiteten Migrationsdienst gehen die meisten Teams. Stelle die Anfrage, gib dein Zendesk-API-Token und die Zielstruktur an, und das Team von Document360 erledigt den Upload. Der Prozess läuft in Schleifen mit Prüfpunkten. Das Team bestätigt Zeitplan und Weiterleitungsregeln, bevor das neue Help Center live geht.

Der Weg in Eigenregie nutzt die öffentliche API von Document360. Du authentifizierst dich über ein API-Token (Einstellungen, API tokens) und legst Artikel per POST in den zuvor erstellten Kategorien an. Die API nimmt den Textkörper als HTML oder Markdown. Du läufst über deine transformierten Artikel und legst sie programmatisch an. Diese Option gibt dir volle Kontrolle über Reihenfolge, Metadaten, Slugs und Zeitpunkt.

Eine wichtige Eigenart: Zendesk liefert über die Help Center API keine Artikelreihenfolge, Document360 kann die Reihenfolge innerhalb eines Abschnitts also nicht erhalten. Geh nach dem Import jede Kategorie durch und sortiere die Artikel im Drag-and-drop-Baum von Hand. Für ein Help Center mit 500 Artikeln sind das 4 bis 6 Stunden. Plane sie ein, geh nicht davon aus, dass der Import es richtig macht.

Sind die Artikel drin, mach vor Schritt 4 eine Plausibilitätsprüfung. Nimm die 20 meistgelesenen Artikel, öffne jeden im Document360-Portal und prüfe, ob Bilder rendern, interne Links auflösen und die Formatierung dem Original entspricht. Sieht etwas schief aus, repariere das Transformationsskript und importiere den Stapel neu. An diesem Prüfpunkt zu reparieren ist deutlich günstiger als nach dem Livegang der Weiterleitungen.

Schritt 4: Bilder und Anhänge

Bilder sind der Fehlermodus, der Teams beißt, die die Migration als reine Inhaltsübung behandelt haben. Drei Regeln.

Alles neu hosten. Die Versuchung ist, Bilder auf dem Zendesk-CDN zu lassen und Document360 nur darauf zeigen zu lassen. Die Adressen funktionieren, die Verweise lösen auf. Bis sie es nicht mehr tun. Die CDN-Adressen hängen an deinem Abo. Kündige Zendesk, und jedes Bild bricht. Selbst wenn du beide Abos behältst, sind die Adressen nicht vertraglich garantiert; Zendesk kann sie rotieren. Hoste im Rahmen der Transformation alles neu.

Sprechende Dateinamen nutzen. Zendesk erzeugt Dateinamen wie 1234567890123_image.png. Document360 nutzt den ursprünglichen Dateinamen in der Asset-Adresse. Benennst du Bilder beim Neu-Hosten um (artikel-slug-schritt-1.png, artikel-slug-schritt-2.png), nimmst du einen kleinen SEO-Vorteil mit, und dein zukünftiges Ich findet Bilder am Namen. Günstiger Schritt, echter langfristiger Wert.

Alternativtexte prüfen. Zendesk erzwingt keine Alternativtexte bei hochgeladenen Bildern. Eine Migration ist ein erzwungener Blick auf jeden Bildverweis. Ergänze Alternativtexte, wo sie fehlen. Dasselbe Prinzip wie beim Artikelaudit: Die Migration ist der einzige Moment, in dem du jedes Bild ansiehst.

Anhänge (PDFs, ZIPs, Vorlagen zum Herunterladen) folgen derselben Regel. Neu hosten, nicht verlinken. Document360 unterstützt Dateianhänge nativ. Bei der Transformation hochladen, Verweise im Text ersetzen, Originale archivieren.

Schritt 5: Kategorien und Berechtigungen abbilden

Der Kategoriebaum wird großteils in Schritt 2 gelöst, doch Berechtigungen sind ein eigenes Problem. Zendesk Guide nutzt Berechtigungsgruppen: Jeder Artikel gehört zu einer Gruppe, die bestimmt, wer ihn lesen darf. Document360 nutzt ein Modell aus Workspaces und Lesegruppen, mit feinerer Steuerung darüber, welche Gruppe welche Artikel sieht.

War dein Zendesk-Help-Center vollständig öffentlich, ist dieser Schritt trivial. Überspring ihn. Hast du geschützte Inhalte (Partnerdoku, nur für Beschäftigte, nur für höhere Tarife), bilde die Gruppen vor den Weiterleitungen ab. Die Abbildung ist selten eins zu eins. Das Konzept der Lesegruppen erlaubt Muster, die Berechtigungsgruppen bei Zendesk nicht konnten, was mit ein Grund für den Wechsel ist; du musst die neue Struktur allerdings definieren, statt die alte zu kopieren.

Prüfe mit Stichproben. Melde dich als beispielhafte eingeschränkte Person an und bestätige, dass sie nur sieht, was sie soll. Melde dich als öffentliche Person an und bestätige, dass geschützte Artikel unsichtbar bleiben. Mach das auf dem Staging-Help-Center vor dem Cutover, nicht danach.

Schritt 6: Strategie für Weiterleitungen

Dieser Schritt entscheidet, ob deine Suchplatzierungen überleben. Mach ihn falsch, und das Help Center verliert über Nacht sechs bis zwölf Monate angesammelte Suchkraft.

Jeder Artikel in Zendesk hat eine Adresse wie https://deinesubdomain.zendesk.com/hc/en-us/articles/123456-article-slug. Nach der Migration liegt derselbe Artikel unter https://docs.deinunternehmen.de/kategorie/unterkategorie/article-slug. Jede alte Adresse muss per 301 auf die neue weiterleiten. Ohne das sieht Google 404 bei den alten Adressen und spült die Platzierungen binnen Wochen weg.

Drei Mechaniken sind einzurichten.

Zuordnungstabelle. Erfasse beim Import zu jedem Artikel die Zendesk-ID und die Document360-Adresse. Das einfachste Format ist eine CSV: zendesk_url, document360_url. Das ist deine Quelle der Wahrheit für die Weiterleitungsregeln.

Entscheidung zur Subdomain. Die meisten Teams verschieben das Help Center von support.deinunternehmen.de (dem Muster von Zendesk) auf docs.deinunternehmen.de oder behalten dieselbe Subdomain. Behältst du sie, tauschst du das DNS, und die Weiterleitungen leben am neuen Host. Wechselst du sie, zeigt die alte Subdomain auf einen statischen Weiterleitungshost, der die 301 ausliefert, und die neue zeigt auf Document360.

Umsetzung. Der begleitete Migrationsdienst von Document360 erledigt das, wenn du ihn nimmst. In Eigenregie richtest du Cloudflare Page Rules ein, einen kleinen Weiterleitungsdienst in Node oder Python auf Vercel oder Cloudflare Workers oder statische Weiterleitungen in deinem CDN. Das Werkzeug zählt weniger als die Anforderung: Jede Adresse /hc/en-us/articles/{id} liefert eine 301 auf ihr Document360-Pendant, und zwar mit echtem 301-Statuscode (keine 302, kein Meta-Refresh, keine Weiterleitung per JavaScript).

Reiche danach deine neue Sitemap in der Google Search Console ein. Die Neuindexierung greift die Weiterleitungen auf, Google entfernt die alten Adressen aus dem Index, und die Platzierungen wandern auf die neuen Adressen. Der vollständige Übergang dauert zwei bis sechs Wochen.

Schritt 7: Der Cutover-Plan

Die Checkliste für den Tag. Eine Person verantwortet diese Liste, teil die Verantwortung nicht auf.

• DNS umstellen. Die Help-Center-Subdomain auf Document360 zeigen lassen (oder auf deinen Weiterleitungsdienst, wenn die Subdomain wechselt).
• Weiterleitungen prüfen. Ruf die 50 wichtigsten alten Adressen per curl ab und bestätige, dass jede eine 301 auf die richtige neue Adresse liefert. Prüfe den langen Schwanz stichprobenartig.
• Neuindexierung anstoßen. Reiche die neue Sitemap in der Google Search Console ein. Reiche das Bing-Pendant ein, wenn dir Bing-Traffic wichtig ist.
• Interne Kommunikation. Sag dem Supportteam, dass das Help Center umgezogen ist. Aktualisiere interne Links im Ticketsystem, in Slack-Kanälen und in Onboarding-Dokumenten. Das Team wird in der ersten Woche kaputte Verweise finden; jemand sollte sie sammeln und reparieren.
• Externe Kommunikation. Hast du eine Statusseite oder einen Kundenkanal, poste einen Absatz zur Migration. Der Adresswechsel fällt in gespeicherten Lesezeichen auf.
• Überwachung. Beobachte die Google Search Console auf Crawl-Fehler, deine Help-Center-Analytik auf Traffic-Einbrüche und den Supportposteingang auf "Wo ist X hin"-Tickets. Die ersten 72 Stunden sind die, in denen du Probleme fängst.
• Zendesk 30 Tage weiterlaufen lassen. Kündige Zendesk Guide nicht am Tag des Cutovers. Halte es 30 Tage als Rückfalloption, falls die Migration Übersehenes zutage fördert. Nach 30 Tagen sauberem Traffic auf Document360 und ohne größere Probleme kannst du kündigen.

Ist die Migration groß (über 1.000 Artikel, mehrere Sprachen, komplexe Berechtigungen), fahr zuerst eine Staging-Migration. Document360 unterstützt einen Sandbox-Workspace, in dem du die gesamte Pipeline trocken durchspielen kannst. Die Zeit lohnt sich.

Schritt 8: Der Prozessschritt nach der Migration

Hier ist der Schritt, den die meisten Anleitungen weglassen. Du hast die Arbeit gemacht. Die Artikel sind umgezogen. Die Taxonomie ist sauberer. Der Editor ist besser. Werden die Artikel in sechs Monaten noch stimmen?

Änderst du nichts daran, wie das Team schreibt, prüft und aktualisiert, lautet die Antwort nein. Die Artikel veralten in demselben Tempo wie in Zendesk, weil das Problem nicht der Editor ist. Das Problem ist, dass niemand weiß, wann sich das Produkt so geändert hat, dass der Artikel gebrochen ist, und dass es im Ablauf des Teams kein Signal dafür gibt.

Eine Migration ist der seltene Moment, in dem du diesen Kreislauf brechen kannst. Das Team schaut aufs Help Center. Die Artikel liegen vor jemandem. Der Kategoriebaum wird angefasst. Nutze das Fenster.

Drei Prozessänderungen lohnen sich im Migrationsfenster.

Verantwortliche pro Kategorie. Jede Document360-Kategorie bekommt eine benannte Person als Verantwortung. Ihre Aufgabe ist, dafür geradezustehen, ob die Artikel darin stimmen. Nicht alle selbst zu schreiben, sondern die Person zu sein, die bemerkt, wenn etwas veraltet, und die Überarbeitung auslöst. Ohne Verantwortung ist jeder Artikel das Problem aller und damit von niemandem.

Ein Prüftakt. Wähle einen Zyklus, der zu deinem Produkttempo passt. Bei wöchentlichen Releases prüfe jeden Artikel quartalsweise. Bei monatlichen reicht halbjährlich. Bei jährlichen jährlich. Der Takt muss keine vollständige Überarbeitung sein; zehn Minuten Durchgang mit der Frage, ob etwas jetzt falsch ist, reichen. Was es kostet, das auszulassen, steht in den versteckten Kosten veraltender Dokumentation.

Ein Änderungssignal. Das Schwerste und Wertvollste. Ändert sich das Produkt (eine Funktion geht live, eine Einstellung zieht um, ein Tarif ändert sich), muss ein Signal automatisch die Doku erreichen. Die meisten Teams erreichen das über Release-Note-Termine oder einen gemeinsamen Slack-Kanal. Eine kleine Gruppe erreicht es über Werkzeuge, die das laufende Produkt mit der Dokumentation vergleichen. Die vorgelagerte Fassung dieser Idee steht in selbst aktualisierendes Help Center.

Was bei dieser Migration verloren geht

Sei ehrlich zum Team, was den Umzug nicht überlebt. Zeig die Liste vor dem Cutover, nicht danach.

Der Verlust von Aufrufzahlen und Analytik-Historie überrascht Teams am meisten. Daran führt kein Weg vorbei; die Daten bleiben in Zendesk. Brauchst du historische Traffic-Daten zu bestimmten Artikeln, exportiere sie aus der Guide-Analytik, bevor du kündigst. Die Analytik von Document360 zählt ab dem Cutover-Tag.

Häufige Fehler bei der Migration

Fünf Fehlermodi, die es zu benennen lohnt, damit du sie vermeidest.

Alles migrieren. Das Audit überspringen und alle 2.000 Artikel importieren, auch die toten. Du zahlst für Speicher, für Prüfzeit, für die kognitive Last eines aufgeblähten Kategoriebaums, und die Artikel, die du hättest löschen sollen, ranken weiter für Suchen, die die falsche Person zur falschen Antwort schicken.

Bilder verlinken. Bildverweise auf dem Zendesk-CDN lassen. Funktioniert an Tag eins, bricht an Tag 180, wenn das Abo endet oder die Adressen rotieren. Immer neu hosten.

Weiterleitungen auslassen. Ohne 301 von den alten Adressen umschalten. Das Help Center verliert sechs bis zwölf Monate Suchkraft, Menschen mit Lesezeichen landen auf 404, interne Links aus deiner Produktoberfläche und aus E-Mails brechen. Die Weiterleitungsarbeit sind die wirksamsten 4 Stunden der gesamten Migration.

Zu früh kündigen. Am Tag des Cutovers den Stecker ziehen. Du verlierst die Rückfalloption, den Zugriff auf die vergessene Analytik-Historie und die Möglichkeit, den Originalzustand mit der migrierten Fassung zu vergleichen. Lass Zendesk mindestens 30 Tage laufen.

Nur an Inhalte denken. Die Migration als reine Inhaltsübung behandeln. Schritt 8 auslassen. Sechs Monate später merkt das Team, dass die Artikel in Document360 genauso veraltet sind wie in Zendesk, nur der Editor ist hübscher. Die Migration war die Gelegenheit, den Verfallsprozess zu reparieren. Diese Gelegenheit kommt ohne eine weitere Migration nicht zurück.

Wann der begleitete Dienst und wann Eigenregie

Kurze Entscheidungsregel.

Nimm den begleiteten Migrationsdienst, wenn: du unter 500 Artikel hast, in deinem Team niemand mit der Zendesk-API vertraut ist, du eine feste Frist hast (meist ein Verlängerungsdatum bei Zendesk, das du nicht treffen willst) oder du mehrere Sprachen parallel migrierst.

Geh den Weg in Eigenregie, wenn: du über 500 Artikel hast und feine Kontrolle über die Transformation willst, jemand im Team ein Python-Skript schreiben kann, du bei der Migration nicht triviale Umbauten brauchst (Überarbeitungen, Entdopplung, neue Taxonomie) oder du die Mechanik für künftige Migrationen lernen willst.

Ein Mischweg ist üblich. Das Team von Document360 übernimmt Export und Massenimport. Dein Team übernimmt die Transformationen (Bilder neu hosten, interne Links umschreiben, Taxonomie entscheiden). Für Bestände zwischen 200 und 800 Artikeln ist das oft der schnellste Weg.

Bist du noch in der Bewertung und hast dich nicht auf Document360 festgelegt, sind das die relevanten Direktvergleiche: HappySupport gegen Document360 für den Blick auf Korrektheit, Document360 gegen Helpjuice für die Seite dedizierter Wissensdatenbanken und HappySupport gegen Zendesk, falls Bleiben noch nicht ausgeschlossen ist. Der Vergleich Help Scout Docs gegen Zendesk Guide behandelt einen weiteren üblichen Weg aus Zendesk heraus.

Wo HappySupport in dieses Bild passt

Wir bauen HappySupport, weil die Migrationsgeschichte oben real ist und das zugrunde liegende Problem geteilt wird. Teams verlassen Zendesk Guide, weil Editor und Preise gedrückt haben. Sie wechseln zu Document360, weil es das bessere Doku-Werkzeug ist. Sechs Monate später veralten die Artikel weiterhin.

HappySupport sitzt neben deinem Ticketsystem (Intercom, Zendesk, Help Scout, HubSpot, Front, Freshdesk) als die Help-Center-Schicht, die korrekt bleibt, wenn sich das Produkt ändert. Kategoriebaum und Editor sind nicht das Problem, das ist gelöst. Das Problem ist das Signal vom Produkt zurück in die Dokumentation, und diese Schicht fehlt den meisten Help Centern.

Bist du mitten in der Migration und beschäftigt dich die Frage der Korrektheit, findest du den Vergleich unter HappySupport gegen Document360. Stehst du noch vor der Entscheidung und suchst das richtige Ziel, behandelt selbst aktualisierendes Help Center die größere Frage, wie das Help Center nach dem Umzug korrekt bleibt.