Wie lange dauert eine Hotel-PMS-Migration für ein kleines Haus?

Für ein Haus mit 20-50 Zimmern sollten Sie 4-8 Wochen vom Projektstart bis zur Inbetriebnahme einplanen. Das umfasst 1-2 Wochen für Datenaudit und -bereinigung, 2-3 Wochen für die Konfiguration des neuen Systems und Mitarbeiterschulungen sowie einen 1-2-wöchigen Parallelbetriebszeitraum, in dem beide Systeme gleichzeitig laufen, bevor der vollständige Umstieg erfolgt.

Welche Daten können von einem Hotel-PMS auf ein anderes migriert werden?

Die meisten PMS-Plattformen können exportieren und übertragen: zukünftige Reservierungen (mit Preisen, Sonderwünschen und Zahlungstoken), Gästeprofilhistorie, Ratenplankonfigurationen und Zimmerkategorie-Einstellungen. Historische Rechnungen und archivierte Reservierungen werden weniger zuverlässig übertragen, da Unterschiede im Datenmodell zwischen Plattformen dazu führen, dass einige Felder verloren gehen oder während des Imports manuell bereinigt werden müssen.

Was ist der beste Zeitpunkt für einen Hotel-PMS-Wechsel?

Das risikoärmste Zeitfenster ist eine Periode mit geringer Auslastung unter der Woche in der Nebensaison, idealerweise mit minimaler Zimmerbelegung und keinen Gruppen oder Veranstaltungen im Haus. Vermeiden Sie Hochsaison, lange Wochenenden und Zeiten, in denen Schlüsselpersonal im Urlaub ist. Viele Betreiber planen den Umstieg für einen Dienstag- oder Mittwochabend.

Kann man ein PMS ohne Systemausfallzeit migrieren?

Ja, mit einem Parallelbetriebsansatz. Das alte PMS bleibt als reine Referenz aktiv, während das neue System alle neuen Check-ins und Reservierungen bearbeitet. Dies eliminiert harte Ausfallzeiten, erfordert aber, dass das Personal während des Überlappungszeitraums (typischerweise 24-72 Stunden) beide Systeme prüft. Nach Bestätigung der Datenabstimmung wird das Legacy-System außer Betrieb genommen.

Welche Hotel-PMS-Systeme bieten die besten Datenexport-Tools?

Apaleo führt bei der Exportflexibilität mit vollständigem API-Zugriff und offenem Datenmodell. Mews bietet gut dokumentierte REST-API-Exporte und ein dediziertes Migrationsteam für größere Häuser. Cloudbeds bietet CSV-Export für Reservierungen und Gästeprofile sowie API-Zugriff. Hotelogix enthält Datenexport als Standard. Hostaway (ferienorientiert) exportiert über API. Guestivo verbindet sich mit den meisten dieser Systeme über API für Datenkontinuität der Gästekommunikation während der Migration.

Hotel-PMS-Migration: Systemwechsel ohne Datenverlust

Ein 40-Zimmer-Boutique-Hotel unterzeichnet montags einen Vertrag mit einem neuen PMS. Das alte System speichert noch 180 zukünftige Reservierungen, Tausende von Euro in autorisierten Zahlungstoken und vier Jahre Gästeprofilhistorie. Der CFO möchte alles bis Freitag live haben. Was schiefläuft, ist fast immer dasselbe: Gastdaten werden beim Export abgeschnitten, Zahlungstoken lassen sich nicht zwischen Zahlungs-Gateways übertragen, und das Personal ist vor dem Umstiegsdatum nicht geschult.

Eine PMS-Migration ist eines der am stärksten störenden Technologieprojekte, die ein kleines Hotel unternehmen kann. Aber sie muss nicht katastrophal sein. Häuser, die die Reihenfolge sorgfältig planen, beide Systeme kurz parallel betreiben und Daten exportieren, bevor die alte Plattform außer Betrieb genommen wird, kommen mit unveränderten Reservierungen und erhaltener Gästehistorie durch.

Dieser Leitfaden behandelt die praktischen Mechanismen: was zu exportieren ist, in welcher Reihenfolge, wie lange Systeme parallel betrieben werden sollten und welche Anbieter die Migration für Häuser mit 20-100 Zimmern am besten handhabten. Zum Kontext der PMS-Wahl lesen Sie den Vergleich von Cloud-PMS-Optionen für kleine Hotels sowie den Boutique-Hotel-Technologieleitfaden.

Was beim PMS-Wechsel tatsächlich kaputt geht

Die naive Sicht eines PMS-Wechsels ist ein Datentransfer: alles aus System A exportieren, in System B importieren, fertig. Die Realität ist unordentlicher.

Laut Mews Migrationsdokumentation unterscheiden sich Datenmodelle zwischen Plattformen erheblich. Opera strukturiert Reservierungen als “Legs” mit Segmenten. Mews verwendet “Reservierungen” mit “Elementen”. Cloudbeds hat sein eigenes Schema. Wenn Felder nicht sauber gemappt werden, gehen Daten entweder verloren oder landen an der falschen Stelle und müssen manuell korrigiert werden.

Drei Dinge brechen am häufigsten:

Zahlungstoken. Tokenisierte Kartendaten erfüllen PCI-Anforderungen und sind an spezifische Zahlungs-Gateway-Konfigurationen gebunden. Wenn Sie PMS wechseln, wechseln Sie oft auch den Zahlungsabwickler. Bestehende Token lassen sich nicht zwischen Gateway-Anbietern übertragen. Gäste mit zukünftigen Reservierungen müssen Karten neu autorisieren oder es ist ein manueller Prozess für Zahlungen beim Check-in erforderlich. Planen Sie dies explizit ein.

Historische Rechnungen. Abgeschlossene Aufenthalte aus früheren Jahren migrieren selten sauber. Die meisten Häuser archivieren historische Daten als Nur-Lese-Export (CSV oder PDF), anstatt sie in das neue System zu importieren. Das ist operativ akzeptabel, aber das Rezeptionspersonal muss wissen, wo es bei historischen Rechnungsanfragen nachschauen soll.

OTA-Kanalverbindungen. Jedes PMS verbindet sich mit OTAs über seine eigenen Channel-Manager-Konfigurationen. Nach dem Wechsel müssen alle Kanalverbindungen im neuen System rekonfiguriert und getestet werden. Das Übersehen dieses Schritts führt am ersten Tag zu Doppelbuchungen oder Preisabweichungen.

Der Datenaudit vor der Migration

Bevor Sie etwas exportieren, verwenden Sie ein bis zwei Wochen auf die Datenbereinigung im bestehenden System. Dies ist der Schritt, den die meisten Betreiber überspringen, und deshalb dauern Migrationen länger als erwartet.

Der Audit deckt vier Bereiche ab:

Gästeprofile. Doppelprofile häufen sich im Laufe der Zeit an: derselbe Gast mit leicht unterschiedlicher Schreibweise des Namens bei mehreren Aufenthalten. Führen Sie einen Deduplizierungsdurchlauf durch, insbesondere für Ihre 200 häufigsten Gäste nach Aufenthaltsfrequenz. Die meisten PMS-Plattformen haben eine Profil-Zusammenführungs-Funktion. Nutzen Sie sie jetzt, denn Duplikate werden in das neue System importiert und sind nach dem Go-live schwerer zu bereinigen.

Zukünftige Reservierungen. Exportieren Sie eine vollständige Liste der Reservierungen von heute plus 12 Monate. Verifizieren Sie, dass jede hat: Zimmertyp, Preiscodes, Gastname, hinterlegte Zahlungsmethode und Sonderwünsche. Reservierungen ohne Preiscodes oder mit Platzhalter-Gastnamen benötigen vor dem Export eine Korrektur.

Ratenplaene und Zimmerkategorien. Mappen Sie Ihre bestehenden Preiscodes auf die Benennung des neuen Systems. Wenn Ihr altes PMS einen Zimmertyp “DBL STD” nennt und das neue “Standard Double” erwartet, muss jede dieser Zimmerkategorie zugewiesene Reservierung neu gemappt werden.

Channel-Manager-Konfigurationen. Dokumentieren Sie alle aktiven OTA-Kanalverbindungen, Ratenplan-Mappings und Restriktionsregeln. Sie werden diese im neuen System von Grund auf neu aufbauen.

Exportmöglichkeiten nach Plattform

Nicht alle PMS-Systeme machen den Datenexport gleichermassen einfach.

Cloudbeds bietet CSV-Export für Reservierungen und Gästeprofile aus dem Berichtsbereich sowie REST-API-Zugriff für detailliertere Datenabrufe. Cloudbeds startet bei ca. EUR 15 pro Zimmer und Monat für kleine Häuser, und Migrationssupport ist inbegriffen.

Mews bietet eine gut dokumentierte Connector-API, die Reservierungen, Abrechnung, Housekeeping und Zahlungsintegrationen abdeckt. Mews stellt ein dediziertes Migrationsteam für größere Häuser bereit und hat eine Sandbox-Umgebung zum Testen von Datenimporten vor dem Go-live.

Apaleo ist die exportfreundlichste Option: Die gesamte Plattform ist API-first konzipiert, mit vollständigem Datenzugriff von Tag eins. Bei der Migration zu oder von Apaleo ist jeder Datentyp über REST-API zugänglich, ohne Anbieter-Unterstützung zu benötigen.

Hotelogix beinhaltet Datenexport als Standardfunktion. CSV-Exporte von Reservierungen und Gästehistorie sind ohne Kontaktaufnahme mit dem Support aus dem Admin-Panel verfügbar.

Guestivo verbindet sich über API mit den meisten dieser Systeme für Gästekommunikationsdaten, was bedeutet, dass Pre-Arrival-Messaging-Sequenzen und digitale Check-in-Abläufe während des gesamten Migrationszeitraums weiter funktionieren. Das ist nützlich für die Aufrechterhaltung der Gästeerfahrungs-Kontinuität, wenn das PMS selbst im Umbruch ist.

Parallelbetrieb vs. Kaltumstieg

Dies ist die Entscheidung, die bestimmt, ob Ihre Migration stressig oder katastrophal wird.

Der Kaltumstiegsansatz: Das alte PMS wird Freitagabend abgeschaltet, das neue läuft Samstagmorgen. Personal kommt mit einem System auf die Schicht. Sauber und einfach. Das Problem: Jede Daten, die nicht korrekt übertragen wurden, hat keine Sicherheitsnetz. Eine Reservierung, die Samstagmorgen im neuen System fehlt, bedeutet einen Gast an der Rezeption mit einer bestätigten Buchung, die Sie nicht finden können. Bei 180 zukünftigen Reservierungen ist die Wahrscheinlichkeit mindestens eines Datenfehlers nahezu sicher.

Der Parallelbetriebsansatz: Beide Systeme sind für ein definiertes Fenster aktiv, typischerweise 24-72 Stunden. Das neue PMS bearbeitet alle neuen Check-ins und eingehenden Reservierungen. Das alte PMS bleibt im Nur-Lese-Modus als Referenz erreichbar. Personal prüft beide Systeme während des Überlappungszeitraums. Jede Reservierung, die im alten System erscheint, aber nicht im neuen, wird manuell hinzugefügt, bevor das alte System außer Betrieb genommen wird.

Der Fehlerfall beim Parallelbetrieb ist Personal, das gewohnheitsmäßig weiterhin Daten in das alte System eingibt. Lösen Sie dies, indem Sie am Umstiegstag den Schreibzugriff auf das alte PMS entfernen und den Nur-Lese-Zugriff aktiv lassen. Klare Kommunikation vor dem Go-live darüber, welches System was übernimmt, verhindert die meisten Fehler.

Laut WebRezPro-Migrationsleitfaden erwischen Häuser, die Systeme auch nur 24 Stunden parallel betreiben, die Mehrheit der Importfehler, bevor sie Gäste betreffen.

Wie migriert man historische Gastdaten ohne Kontextverlust?

Das ist die Frage, die die meisten Betreiber stellen, nachdem sie erkennen, dass historische Rechnungen nicht sauber importiert werden. Die Antwort hängt davon ab, wie man “Kontext” definiert.

Echte historische Rechnungsdaten (einzelne Posten aus abgeschlossenen Aufenthalten) überleben eine PMS-Migration selten in nutzbarer Form. Die Datenmodelle sind zu unterschiedlich. Was Sie erhalten können:

Gastprofilfelder: Name, E-Mail, Telefon, Adresse, Präferenzen, Loyalitätsstufe, Gesamtaufenthaltsanzahl, Gesamtumsatz. Diese exportieren sauber aus den meisten Plattformen via CSV und importieren in die Gastdatenbank des neuen Systems mit moderatem Feldmapping-Aufwand.

Aufenthaltshistorie-Zusammenfassungen: Check-in-Datum, Check-out-Datum, Zimmertyp, gezahlte Rate, Rechnungsgesamt. Viele Systeme exportieren dies als separates CSV, das in Gasthistorie-Datensätze importiert wird und Rezeptionspersonal eine Aufenthaltsanzahl und Umsatzzusammenfassung gibt, auch ohne einzelne Posten.

Kommunikationspräferenzen und Sonderwünsche: Einige Plattformen speichern diese als Freitext in Gastprofilen; andere haben strukturierte Felder. Als Freitext exportieren und in das Notizfeld des neuen Systems importieren.

Ein 42-Zimmer-Haus, das drei Jahre Gästehistorie mit einem Parallelbetriebsansatz migriert hat, schloss den Datentransfer in etwa 11 Stunden aktiver Arbeit von zwei Mitarbeitern über zwei Tage ab. Das Ergebnis waren 1.847 importierte Gästeprofile mit intakter Aufenthaltshistorie, obwohl historische Rechnungen als PDFs in einem gemeinsamen Ordner archiviert wurden.

Der praktische Rat: Akzeptieren Sie, dass historische Rechnungen ein Archiv werden, keine Live-Datenbank. Konzentrieren Sie Migrationsenergien auf zukünftige Reservierungen und aktive Gästeprofile. Halten Sie einen Nur-Lese-Export des alten Systems sechs Monate nach der Migration für Rechnungsanfragen zugänglich.

Was bis nach dem Go-live warten kann

Nicht alles muss vor dem Umstieg konfiguriert sein. Die Umfangspriorisierung ist eine der wertvollsten Maßnahmen in den zwei Wochen vor dem Go-live.

Kann warten: Integrationen mit Sekundärtools (Upselling-Software, Reputation-Management, Business-Intelligence-Dashboards). Diese verbinden sich über API und können konfiguriert werden, nachdem das kern-PMS stabil ist.

Kann warten: vollständige Automatisierung von Pre-Arrival-E-Mails. Grundlegende Bestätigungs-E-Mails müssen am Go-live-Tag funktionieren. Automatisierte Pre-Arrival-Sequenzen, Upsell-Angebote und Post-Stay-Bewertungsanfragen können in Woche zwei oder drei nach dem Start konfiguriert und getestet werden.

Kann warten: detaillierte Berichts- und Analysekonfiguration. Standard-Berichte funktionieren. Benutzerdefinierte Dashboards und KPI-Tracking können aufgebaut werden, wenn das Team mit dem neuen System vertraut ist.

Kann nicht warten: Channel-Manager-Verbindungen zu allen aktiven OTAs, Zahlungsverarbeitungskonfiguration, Zimmertyp- und Ratenplan-Einrichtung, Personalschulung zu Kern-Check-in und -out-Workflows sowie ein getesteter Prozess für Telefon- und Walk-in-Reservierungen.

Der Leitfaden zu integrierten Hotel-Tech-Stacks behandelt, wie Tool-Integrationen nach einem stabilen Kern-PMS sequenziert werden.

Realistischer Migrations-Zeitplan für ein 30-Zimmer-Boutique-Hotel

Tag	Aktivität
-14	Neuen PMS-Vertrag unterzeichnen. Datenexport-Dokumentation beim aktuellen Anbieter anfordern.
-13 bis -10	Gastprofil-Deduplizierung im alten System. Vollständigkeit der Daten aller zukünftigen Reservierungen verifizieren.
-9 bis -7	Neue PMS-Sandbox-Umgebung einrichten. Zimmertyp- und Ratenplan-Konfiguration beginnen.
-6 bis -5	Vollständige Reservierungsdatei und Gastprofildatenbank aus dem alten System exportieren. Testimport in neue System-Sandbox durchführen.
-4 bis -3	Channel-Manager-Verbindungen im neuen System konfigurieren. OTA-Synchronisation in der Sandbox testen. Raten-Mapping-Fehler beheben.
-2	Personalschulung zu Check-in, Check-out, Reservierungsänderung und Zahlungsverarbeitung im neuen System.
-1	Finaler Datenexport aus dem alten System. Verifizieren, dass alle Reservierungen für den Zeitraum -1 bis +30 im neuen System vorhanden sind. Schreibzugriff auf altes PMS entfernen.
0 (Umstiegstag)	Neues System in Betrieb nehmen. Altes PMS im Nur-Lese-Referenzmodus. Zusätzliches Personal auf der Schicht.
+1	Reservierungsabweichungen zwischen altem und neuem System abgleichen. Alten PMS-Zugriff schließen.
+2 bis +7	Auf Integrationsprobleme achten. Sekundärtool-Verbindungen konfigurieren (Upselling, Gästekommunikation usw.).
+14	Post-Migrations-Review. Bestätigen, dass alle Kanalverbindungen funktionieren. Personalkomfort mit neuem System bewerten.

Dieser Zeitplan setzt ein einzelnes Haus mit ein bis zwei Mitarbeitern voraus, die die Migration neben dem regulären Betrieb durchführen. Häuser mit komplexeren Preisstrukturen oder mehr OTA-Kanälen sollten der Konfigurationsphase ein bis zwei Wochen hinzufügen.

Fazit

Eine PMS-Migration ist disruptiv, egal wie gut Sie sie planen. Die Häuser, die ohne Datenverlust durchkommen, behandeln sie als strukturiertes Projekt und nicht als Wochenend-Software-Tausch.

Beginnen Sie mit dem Datenaudit. Exportieren Sie vor der Außerbetriebnahme. Betreiben Sie Systeme mindestens 24 Stunden lang parallel. Halten Sie historische Daten archiviert und sechs Monate lang zugänglich. Und seien Sie realistisch, was Sie vom Personal verlangen: Ein neues PMS ist eine erhebliche Workflow-Änderung, und die Wochen nach dem Go-live werden Probleme aufdecken, die das Testen nicht erfasst hat.

Die Reibung ist vorübergehend. Ein PMS, das besser zu Ihrem Haus passt, schlägt sich in Wert über Monate und Jahre nieder: bessere Integrationen, schnellere Workflows und Daten, die Ihr Team tatsächlich nutzen kann.