RoboHelp-Konvertierung: Alte Projekte sauber in die neue Generation migrieren

In erstaunlich vielen Redaktionen läuft noch ein RoboHelp-Classic-Projekt – gestartet irgendwann in den Nullerjahren, durch ein Dutzend Versionen geschleppt, gewachsen wie ein Einfamilienhaus mit vier Anbauten. Es funktioniert ja: Die Ausgaben werden generiert, die Hilfe wird ausgeliefert, und der Satz „nach dem nächsten Release kümmern wir uns um die Migration" gehört seit Jahren zum festen Repertoire der Jahresplanung. Nur: Die neue RoboHelp-Generation ist seit 2019 auf dem Markt, dort findet die Weiterentwicklung statt – und der Abstand zwischen der Welt, in der dein Projekt lebt, und der Welt, in der das Werkzeug lebt, wächst mit jedem Jahr.

Die gute Nachricht: Die Konvertierung ist kein Himmelfahrtskommando. Adobe hat den Übergang bewusst konservativ gebaut – dein Classic-Projekt bleibt beim Upgrade unangetastet, konvertiert wird eine Kopie, und die Inhalte selbst reisen erstaunlich robust. Die weniger gute Nachricht: „Konvertierung" und „Migration" sind zwei verschiedene Dinge. Der Assistent erledigt die erste in Minuten; die zweite – prüfen, reparieren, aufräumen, Prozesse umstellen – ist ein Projekt, dessen Aufwand fast vollständig vom Zustand deines Altprojekts abhängt.

Dieser Artikel führt durch beides: warum Classic und neue Generation wirklich zwei Welten sind, wie der Migrationspfad Schritt für Schritt aussieht, welche Bruchstellen die Praxis kennt – und warum die Migration die beste Aufräumgelegenheit ist, die dein Projekt je bekommen wird.

Classic und neue Generation: warum das zwei Welten sind

Um die Migration richtig einzuordnen, muss man verstehen, was Adobe da eigentlich gebaut hat. Die neue RoboHelp-Generation ist kein Facelift des alten Programms, sondern ein Neubau: eine von Grund auf neue Codebasis, deren Quellformat konsequent auf HTML5 und CSS3 steht. Das Classic-Produkt trug dagegen die Architektur von zwei Jahrzehnten Windows-Hilfe-Geschichte mit sich – vom CHM-Erbe über die WebHelp-Framewelt bis zu den Ausgabeformaten der Flash-Ära. Beides sind vollwertige Werkzeuge; aber sie sprechen intern verschiedene Sprachen, und genau deshalb ist der Übergang kein Update, sondern eine Übersetzung deines Projekts von der einen Architektur in die andere.

Diese Übersetzung lohnt sich aus drei Gründen. Erstens die Zukunftsfähigkeit: Die Weiterentwicklung – neue Funktionen, moderne Ausgaben, Fehlerbehebungen – findet in der neuen Generation statt; wer auf Classic bleibt, konserviert einen Endstand. Zweitens die Quellqualität: Ein sauberes HTML5/CSS3-Fundament macht Inhalte zugänglicher für alles, was danach kommt – von der Weiterverarbeitung über die Suche bis zu KI-gestützten Werkzeugen, die mit sauberem Markup schlicht besser arbeiten als mit historisch gewachsenem Spezialcode. Und drittens die Prozesse: Der integrierte Übersetzungsworkflow mit XLIFF und Sprachprojekten sowie die per Kommandozeile automatisierbare Ausgabegenerierung gehören zur neuen Welt – wer mehrsprachig arbeitet oder Builds automatisieren will, findet die Werkzeuge dort.

Der Umkehrschluss gehört zur Ehrlichkeit dazu: Wenn dein Classic-Projekt ein auslaufendes Produkt dokumentiert, das in zwei Jahren eingestellt wird, und keine Übersetzung ansteht – dann darf das Projekt auch in Würde auf Classic zu Ende gehen. Migration ist eine Investition in die Zukunft eines Projekts; wo keine Zukunft geplant ist, gibt es nichts zu investieren. Für alles, was noch Jahre gepflegt, übersetzt oder ausgebaut wird, gilt dagegen: je früher, desto billiger – der Aufräumberg wächst nicht kleiner.

Beruhigend für die Übergangsphase: Classic und neue Generation sind getrennte Anwendungen und vertragen sich nebeneinander. In der Praxis arbeiten viele Teams während der Migration mit beiden Installationen – die alte Welt zum Nachschlagen und für den eingefrorenen Bestand, die neue zum Arbeiten. Das nimmt der Umstellung die Alles-oder-nichts-Dramatik: Du musst nicht an einem Stichtag die Brücken abbrechen, sondern kannst Projekt für Projekt umziehen, solange je Projekt der harte Schnitt gilt.

Abb.: Classic und neue Generation im Vergleich – kein Versionssprung, sondern ein Architekturwechsel mit neuem Quellformat.

Vor dem Knopfdruck: die Inventur

Bevor der Assistent auch nur gestartet wird, lohnt eine halbtägige Inventur – sie entscheidet mehr über den Migrationserfolg als jede Einstellung danach. Punkt eins: die Projektlandkarte. Welche Classic-Projekte existieren, in welcher Version wurden sie zuletzt gepflegt, welche dokumentieren lebende Produkte und welche sind faktisch Archiv? Daraus ergibt sich die Reihenfolge – und oft die erfreuliche Erkenntnis, dass ein Teil der Projekte gar nicht migriert werden muss, sondern nur ordentlich eingefroren.

Punkt zwei: das Sonderlocken-Register. Jedes langlebige Projekt hat sie – die von Hand angepasste Skin-Datei, das eingebettete Skript aus einer vergessenen Agentur-Zusammenarbeit, den Spezialtrick im Master-Layout, den ein Kollege 2014 in einem Forum gefunden hat. Genau diese Anpassungen sind es, die den Umzug nicht überleben; deshalb werden sie vorab gesammelt und dokumentiert – nicht um sie alle zu retten, sondern um nach der Migration bewusst zu entscheiden, was davon die neue Welt überhaupt noch braucht. Erfahrungsgemäß ist die Antwort bei der Hälfte: nichts, das löst die neue Ausgabe von Haus aus. Und für die andere Hälfte gilt: lieber mit den offiziellen Mitteln der neuen Welt nachbauen als den alten Trick transplantieren – sonst steht die nächste Migration vor demselben Register, nur ohne den Kollegen, der sich noch erinnert.

Punkt drei: die technische Vorprüfung. Das Stylesheet durch einen CSS-Validator schicken und Fehler bereinigen – die wichtigste Einzelmaßnahme der ganzen Vorbereitung. Dazu die Ausgabenliste mit Empfängern: Welche Ausgaben werden heute generiert, wer bekommt sie, und was davon lebt noch in der Flash-Ära und braucht ohnehin einen Nachfolger? Und schließlich der Übersetzungsstand: laufende Sprachrunden abschließen, Stände synchronisieren. Wer diese Inventur sauber macht, erlebt die Konvertierung selbst als das, was sie sein sollte – ein unspektakulärer Knopfdruck mit erwartbarem Ergebnis.

Punkt vier schließlich: das Zeitfenster. Die Migration gehört in den Redaktionskalender wie ein Release – mit reservierter Prüf- und Aufräumzeit in einer ruhigen Phase, abgestimmt mit Produktterminen und Übersetzungsrunden. Ein realistisches Fenster nimmt der Übung den Druck, aus dem die meisten Migrationsfehler entstehen: das hastige „passt schon" nach der Konvertierung, weil nebenan schon das nächste Release ruft.

Der Migrationspfad: sechs Schritte, eine eiserne Regel

Der Weg selbst ist gut ausgeschildert, wenn man ihn in der richtigen Reihenfolge geht. Schritt eins ist das Sichern: Bevor irgendetwas passiert, wandert das komplette Classic-Projekt als datiertes ZIP-Archiv in die Ablage – nicht nur als Kopie im Nachbarordner, sondern als bewusst weggeschlossener Stand. Das ZIP hat zwei Jobs: Es ist die Versicherung, falls etwas schiefgeht, und es ist die saubere Ausgangsbasis für jeden weiteren Anlauf – denn es ist völlig normal, die Konvertierung mehrfach zu fahren, bis Vorbereitungen und Ergebnis stimmen. Ein Datumspräfix im Dateinamen erspart später das Rätselraten, welcher Stand der richtige war.

Schritt zwei betrifft die Altersfrage: Der direkte Sprung in die neue Generation ist für Projekte aus aktuellen Classic-Versionen gedacht. Stammt dein Projekt aus einer deutlich älteren Version, führt der empfohlene Weg über einen Zwischenschritt – erst das Projekt auf einen aktuellen Classic-Stand wie 2015, 2017 oder 2019 heben, dann von dort konvertieren. Das klingt nach Umweg, erspart aber genau die diffusen Fehlerbilder, die entstehen, wenn der Konverter auf Projektstrukturen trifft, mit denen er nie gerechnet hat. Schritt drei ist dann der eigentliche Assistent: Er liest das Classic-Projekt, erzeugt ein neues Projekt im neuen Format und sortiert dabei auf – Bilder kommen unverändert mit, Medien und Stylesheets wandern in eine geordnete Asset-Struktur, aus der .xpj wird eine .rhpj. Das Original bleibt liegen, wie es war.

Schritt vier ist der wichtigste und der am häufigsten verkürzte: das Prüfen. Erst die Upgrade-Protokolle sichten – sie liegen im Temp-Verzeichnis des Benutzers im RHTMP-Ordner und verraten, wo der Konverter Kompromisse machen musste. Dann systematisch durchs Projekt: Links auf Brüche testen, das Stylesheet kontrollieren, Skins und Layouts sichten, eine komplette Ausgabe generieren und gegen die alte Ausgabe halten. Schritt fünf ist das Aufräumen – dazu gleich ein eigenes Kapitel, denn hier liegt der eigentliche Gewinn. Und Schritt sechs die Produktivsetzung: formale Abnahme gegen die alte Ausgabe, das Classic-Projekt einfrieren, und ab diesem Tag wird ausschließlich im neuen Projekt gearbeitet. Parallelpflege in beiden Welten ist der sichere Weg ins Chaos.

Zur Abnahme in Schritt sechs noch ein Wort, weil sie gern zur Formsache verkommt: Verglichen wird systematisch, nicht nach Gefühl. Ein Stichprobenplan quer durch das Projekt – Startseiten, verzweigte Kapitel, Topics mit Tabellen, Bildern und Spezialelementen, dazu Inhaltsverzeichnis, Index und Suche – wird in alter und neuer Ausgabe nebeneinander durchgeklickt und abgehakt. Zwei Personen, ein Nachmittag, ein dokumentiertes Ergebnis: Das ist der Unterschied zwischen „sieht gut aus" und einer Abnahme, auf die man sich später berufen kann, wenn doch noch eine Abweichung auftaucht.

Abb.: Der Migrationspfad in sechs Schritten – konvertiert ist schnell, migriert ist geprüft, aufgeräumt und abgenommen.

Was mitkommt – und was zurückbleibt

Was genau passiert nun mit den Bestandteilen deines Projekts auf der Reise? Die Antwort lässt sich in drei Kategorien sortieren – und die Sortierung entscheidet darüber, wo deine Prüfzeit hingehört. Die beruhigende Grundregel der Konvertierung lautet: Inhalte reisen gut. Topics samt Ordnerstruktur, Bilder, Inhaltsverzeichnis, Index, Glossar, Variablen, Snippets und die Verknüpfungen dazwischen – das Rückgrat des Projekts kommt zuverlässig an. Auch bei den Ausgaben denkt der Konverter mit: WebHelp- und Multiscreen-HTML5-Ausgaben werden auf Responsive HTML5 umgestellt, also auf die zeitgemäße Ausgabeform der neuen Welt. Und wer in Classic mit responsiven Skins gearbeitet und sie über den Skin-Editor angepasst hat, findet diese Anpassungen im neuen Projekt wieder.

Zurück bleibt, was die Zeit ohnehin überholt hat – und ein paar Dinge, die wehtun können. Die Flash-Ära-Ausgaben sind Geschichte: Adobe AIR, FlashHelp, JavaHelp und Oracle Help existieren in der neuen Generation nicht mehr; wer solche Ausgaben noch ausliefert, braucht ohnehin einen Nachfolgeplan, und der heißt in aller Regel Responsive HTML5. Alte WebHelp-Skins werden nicht übernommen – die Gestaltung der Ausgabe wird in der neuen Welt neu aufgesetzt, was meist ein Gewinn ist, aber eben Arbeit. Und die wichtigste Trennlinie verläuft bei den Skins zwischen offiziell und gebastelt: Anpassungen über den Skin-Editor reisen mit, Anpassungen daran vorbei – von Hand editierte Skin-Dateien, eingeschleuste Spezialtricks – gehen verloren. Wer über die Jahre kreativ war, sollte diese Kreativität vor der Migration dokumentieren, um sie danach bewusst neu zu entscheiden.

Die dritte Kategorie sind die Prüffälle: Dinge, die grundsätzlich mitkommen, aber Aufmerksamkeit verdienen. Ganz vorn das Stylesheet – dazu gleich mehr, denn hier lauert die bekannteste Falle. Dann die interaktiven Spezialeffekte der Classic-Ära, allen voran die DHTML-basierten Auf- und Zuklapp-Konstruktionen: Sie sind in der Community ein wiederkehrender Prüfpunkt nach dem Upgrade, und die kluge Haltung ist, sie nicht als gesetzt zu betrachten, sondern nach der Konvertierung gezielt zu testen und im Zweifel mit den Mitteln der neuen Welt neu zu bauen. Und schließlich alles Verlinkte über Projektgrenzen hinweg – nach jedem Upgrade steht die systematische Prüfung auf gebrochene und unaufgelöste Links auf dem Zettel, das empfiehlt selbst der Hersteller.

Abb.: Die Reisebilanz des Upgrades – Inhalte kommen zuverlässig an, Gestaltung und Spezialeffekte brauchen den zweiten Blick.

Typische Bruchstellen – und wie du sie entschärfst

Kein Migrationsartikel ist ehrlich ohne das Kapitel über die Stellen, an denen es knirscht. Die gute Nachricht vorweg: Die Bruchstellen sind bekannt, gut dokumentiert und fast alle vermeidbar – wenn man weiß, wo sie liegen. Die folgenden fünf decken nach aller Erfahrung den Großteil der Überraschungen ab.

Bruchstelle Nummer eins ist das Stylesheet, und sie verdient den Spitzenplatz, weil sie so heimtückisch dokumentiert ist: Enthält das CSS des Altprojekts Syntaxfehler, läuft die Konvertierung durch – aber das Stylesheet im neuen Projekt bleibt leer, und plötzlich sieht alles nach Systemschrift und Werkseinstellung aus. Die Abhilfe ist simpel und gehört in die Vorbereitung: das CSS vor der Migration durch einen Validator schicken und Fehler bereinigen. Zwanzig Jahre gewachsene Stylesheets enthalten praktisch immer Leichen – der Validatorlauf kostet eine Stunde und erspart die böse Überraschung.

Bruchstelle Nummer zwei ist das Scheitern selbst: Gelegentlich bricht ein Upgrade schlicht ab, im unglücklichsten Fall mit einem leeren Protokoll. Dann hilft Systematik statt Panik: die Upgrade-Logs im RHTMP-Ordner des Temp-Verzeichnisses prüfen, das Projekt aus dem sauberen ZIP erneut aufsetzen, den Zwischenschritt über einen aktuellen Classic-Stand gehen und testweise Projektteile isolieren, um den Störenfried einzukreisen. Hilft das alles nicht, ist der Adobe-Support für die Technical-Communication-Produkte die richtige Adresse – und daneben lohnt der Blick in die RoboHelp-Community, in der erfahrene Anwender rund um die bekannte Ressourcen-Sammlung von Peter Grainge seit Jahren genau solche Fälle sezieren. Viele Migrationstücken sind dort längst gelöst, bevor man sie selbst zum ersten Mal sieht.

Eine Sonderprüfung verdient die kontextsensitive Hilfe: Wenn deine Software über Map-IDs direkt in Hilfethemen springt, ist diese Verdrahtung zwischen Produkt und Doku das empfindlichste Glied der Kette. Nach der Migration gehört deshalb ein Ende-zu-Ende-Test ins Programm – aus der laufenden Anwendung heraus stichprobenartig die Kontexthilfe aufrufen, quer durch die Module, und die Zuordnungen gegen die neue Ausgabe prüfen. Nichts ist peinlicher als eine technisch gelungene Migration, nach der der F1-Druck im Produkt ins Leere führt – und nichts fällt später auf, wenn niemand es jetzt testet.

Verwandt damit, aber nach außen gerichtet: die Adressen deiner veröffentlichten Hilfe. Mit dem Wechsel der Ausgabetechnik können sich Dateinamen und Pfadstrukturen der publizierten Ausgabe ändern – und damit brechen Lesezeichen, Links aus Support-Tickets, Verweise aus der Wissensdatenbank und alles, was Suchmaschinen über Jahre eingesammelt haben. Wer seine Hilfe öffentlich oder kundenweit bereitstellt, plant deshalb den Adressübergang mit: alte Einstiegsadressen weiterleiten, zentrale Deep-Links prüfen, die wichtigsten Verweise in Nachbarsystemen aktualisieren. Das ist eine Stunde Konzept und erspart wochenlange „der Link geht nicht mehr"-Tickets.

Bruchstelle Nummer drei ist hausgemacht: das unaufgeräumte Altprojekt. Jede Karteileiche, jedes tote Topic, jeder vergessene Testordner wandert mit durch die Konvertierung und macht danach die Prüfung unübersichtlicher – man sucht Fehler in Inhalten, die niemand mehr braucht. Deshalb gilt: Grob aufräumen vor der Migration (Offensichtliches löschen, Baustellen schließen), gründlich aufräumen danach, in der neuen Umgebung mit ihren besseren Werkzeugen. Und Bruchstelle Nummer vier ist organisatorisch: der schleichende Parallelbetrieb. Wenn „nur noch schnell" im alten Projekt eine Korrektur gemacht wird, während das neue schon lebt, driften die Stände auseinander – deshalb der harte Schnitt mit Einfrieren und Abnahme aus dem Migrationspfad.

Die Aufräumchance: Warum die Migration der beste Frühjahrsputz ist

Jetzt zum erfreulichen Teil, der in Migrationsplanungen chronisch zu kurz kommt: Die Konvertierung ist die beste Gelegenheit, die dein Projekt je bekommen wird, um Altlasten loszuwerden. Im Tagesgeschäft räumt niemand ein laufendes Hilfeprojekt auf – zu riskant, zu unsichtbar, zu undankbar. Die Migration ändert die Rechnung: Es gibt ohnehin eine Prüfphase, es gibt ohnehin eine Abnahme, und das alte Projekt liegt als Referenz daneben. Bessere Bedingungen für einen Frühjahrsputz wird es nie geben. Wer sie verstreichen lässt, konvertiert seinen Wildwuchs originalgetreu in die neue Welt – technisch sauber, inhaltlich verschenkt.

Die dankbarsten Aufräumfelder: Erstens das Stylesheet – nach der Migration einmal konsequent konsolidieren, historische Sonderklassen zusammenführen, Formatierung aus den Topics in die Vorlagenlogik ziehen; das zahlt bei jeder künftigen Layoutänderung zurück. Zweitens die Struktur – Ordner und Topic-Namen so ordnen, dass ein neuer Kollege sie versteht, statt die Chronologie des Zufalls zu konservieren. Drittens die Inventur der Bausteine: Variablen, Snippets und Bedingungen sichten – was davon wird wirklich genutzt, was ist Erblast? Viertens die toten Inhalte: nicht verlinkte Topics, verwaiste Bilder, vergessene Entwürfe. Fünftens die Ausgabenlandschaft: Responsive HTML5 sauber aufsetzen und bei der Gelegenheit auch die Word-Ausgabe nach Firmenvorgaben ordentlich konfigurieren – warum genau das ein eigenes Minenfeld ist und wie es gelingt, behandelt der Beitrag zur RoboHelp-Word-Ausgabe.

Und sechstens der größte Prozessgewinn: die Übersetzung. Wer in Classic mit Projektkopien je Sprache gearbeitet hat, stellt mit der Migration auf den integrierten Workflow der neuen Generation um – ein führendes Quellprojekt, Sprachprojekte über Übersetzungsprofile, Austausch per XLIFF, Delta-Export für Folgeübersetzungen. Das ist kein Nebeneffekt, sondern für mehrsprachige Redaktionen oft das stärkste Argument für die ganze Übung; den kompletten Workflow von der ersten Sprache bis zur Vollautomatik beschreibt der Beitrag zur Mehrsprachigkeit mit RoboHelp. Wichtig für die Planung: Die Umstellung gelingt am saubersten zu einem Sprachstand, an dem alle Fassungen synchron sind – also direkt nach einer abgeschlossenen Übersetzungsrunde.

Und wenn du schon dabei bist, hebe gleich den Automatisierungsschatz: Die Ausgabegenerierung der neuen Generation lässt sich über die Kommandozeile ansteuern – damit werden regelmäßige Builds, nächtliche Testausgaben oder die Generierung aller Sprachfassungen in einem Rutsch zur Routine statt zur Klickstrecke. Gerade nach einer Migration, in der ohnehin jede Ausgabe neu eingerichtet wird, kostet die Automatisierung kaum Zusatzaufwand – und sie diszipliniert nebenbei die Projektqualität, weil reproduzierbare Builds keine ungespeicherten Handgriffe verzeihen.

Zwei Gewinne jenseits des Projekts selbst gehören noch auf die Liste. Erstens die Ablage: Die neue, sauber dateibasierte Projektstruktur eignet sich deutlich besser für eine geordnete, versionierte Ablage als das gewachsene Classic-Verzeichnis – der Umzug ist der richtige Moment, das Projekt aus dem Wildwuchs des Laufwerks in eine strukturierte, gesicherte Umgebung mit nachvollziehbaren Ständen zu heben. Zweitens das Team: Die neue Oberfläche ist eine echte Umgewöhnung, und ein halber Schulungstag nach der Migration zahlt sich schneller aus als drei Wochen stilles Fluchen. Wer die Autoren mitnimmt, statt sie vor vollendete Tatsachen zu setzen, bekommt die neue Welt auch gelebt statt nur installiert.

Abb.: Sechs Aufräumgewinne, für die es nie wieder so günstige Bedingungen gibt wie während der Migration.

Fazit

Die RoboHelp-Konvertierung hat zwei Gesichter: Die technische Übersetzung von Classic in die neue Generation ist ein gelöstes Problem – Assistent, Kopierprinzip und Zwischenschritt über einen aktuellen Classic-Stand machen den Weg berechenbar, und die Inhalte kommen zuverlässig an. Die eigentliche Migration ist das, was du daraus machst: Stylesheet vorher validieren, Protokolle und Links danach prüfen, Gestaltung bewusst neu aufsetzen, Altlasten entsorgen und die Übersetzung auf den XLIFF-Workflow heben. Wer so vorgeht, bekommt kein konvertiertes Altprojekt, sondern ein saniertes – auf einem Fundament, auf dem sich die nächsten zehn Jahre bauen lassen. Und die Nebengewinne sind keine Kleinigkeit: ein Übersetzungsworkflow mit XLIFF statt Projektkopien, automatisierbare Builds, eine Ablage mit nachvollziehbaren Ständen – die Migration ist die seltene Gelegenheit, Werkzeug, Inhalt und Prozess in einem Zug zu modernisieren.

Der pragmatische Einstieg: das kleinste echte Projekt als Pilot, ein datiertes ZIP als Ausgangspunkt, eine ruhige Phase im Redaktionskalender. Und wenn du die Migration deiner Projektlandschaft planen, absichern oder gleich mit der Umstellung des Übersetzungsworkflows verbinden willst: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zur RoboHelp-Konvertierung

Muss ich von RoboHelp Classic auf die neue Generation wechseln?

Müssen nicht – aber für jedes Projekt mit Zukunft lohnt es sich. Die Weiterentwicklung findet in der neuen Generation statt, ebenso der integrierte XLIFF-Übersetzungsworkflow und die automatisierbare Ausgabegenerierung. Sinnvolle Ausnahme: Projekte für auslaufende Produkte ohne Übersetzungsbedarf dürfen auf Classic in Würde zu Ende gehen. Für alles andere gilt: Je früher migriert wird, desto kleiner der Aufräumberg.

Geht bei der Konvertierung mein altes Projekt kaputt?

Nein. Der Upgrade-Assistent arbeitet nach dem Kopierprinzip: Das Classic-Projekt bleibt unangetastet, konvertiert wird eine neu erzeugte Kopie im Format der neuen Generation. Trotzdem gehört ein datiertes ZIP-Archiv des Altprojekts vor den Start – als Versicherung und als saubere Ausgangsbasis, falls du die Konvertierung nach Vorbereitungsarbeiten erneut fahren willst.

Unser Projekt stammt aus einer uralten Version – klappt der direkte Sprung?

Davon ist abzuraten. Der empfohlene Weg für sehr alte Projekte führt über einen Zwischenschritt: erst auf einen aktuellen Classic-Stand wie 2015, 2017 oder 2019 heben, dann von dort in die neue Generation konvertieren. Das vermeidet diffuse Fehlerbilder aus Projektstrukturen, mit denen der Konverter nicht mehr rechnet. Schlägt ein Upgrade fehl, lohnt der Blick in die Logs im RHTMP-Temp-Ordner – und notfalls der Weg zum Adobe-Support.

Was passiert mit unseren WebHelp- und Flash-Ausgaben?

WebHelp- und Multiscreen-HTML5-Ausgaben werden beim Upgrade auf Responsive HTML5 umgestellt – die zeitgemäße Ausgabeform der neuen Generation. Die Formate der Flash-Ära wie Adobe AIR, FlashHelp, JavaHelp und Oracle Help existieren nicht mehr. Alte WebHelp-Skins werden nicht übernommen; die Gestaltung wird in der neuen Welt neu aufgesetzt – Skin-Editor-Anpassungen responsiver Skins kommen dagegen mit.

Wie lange dauert eine solche Migration realistisch?

Die Konvertierung selbst dauert Minuten – der ehrliche Aufwand steckt in Vorbereitung, Prüfung und Aufräumen und hängt fast vollständig vom Zustand des Altprojekts ab. Für ein gepflegtes mittleres Projekt sind wenige Tage realistisch; für einen fünfzehn Jahre gewachsenen Bestand mit Skin-Bastelei und Formatierungs-Wildwuchs eher zwei bis drei Wochen inklusive Neuaufbau der Gestaltung. Ein Pilot mit dem kleinsten echten Projekt liefert die belastbarste Schätzung für den Rest.