Von Smoobu zu Apaleo wechseln: ein vorsichtiger Migrationsplan

Nach der Entscheidung kontrolliert umschalten

Dieser Artikel beginnt nach der grundsätzlichen Systementscheidung. Wenn noch offen ist, ob ein Wechsel nötig ist, starte beim Vergleich: Smoobu behalten oder wechseln. Wenn Apaleo als Ziel vorgesehen ist, prüfe zusätzlich seine Rolle, Voraussetzungen und Grenzen auf der Seite Apaleo PMS für Ferienwohnungen. Die folgenden Schritte zeigen ein Modell für die praktische Migration. Sie sind keine Garantie für Datenimport, Dauer oder einen Wechsel ohne Unterbrechung.

• W1–4 · Zielsystem aufbauen

  • Smoobu bleibt für den laufenden Betrieb aktiv.

• W5–8 · Daten prüfen und testen

  • Künftige Reservierungen und Regeln je unterstütztem Feld abgleichen.

• W8–11 · Portale geplant umstellen

  • Je Portal kontrolliert umschalten; bei Airbnb zuerst die bestehende Verbindung trennen.

• ab W11 · Altsystem nicht mehr aktiv pflegen

  • Exporte sichern; Zugriff und Kündigung nach Vertrag.

• VIER PHASEN EINES VORSICHTIGEN WECHSELS
• Zeiträume sind ein Projektmodell, keine Produktgarantie.

Vier Karten führen durch die Datenliste und Zuordnung, den Aufbau des Zielsystems, das kontrollierte Umschalten der Portale sowie Sicherung und Rückfallplan. Während der Vorbereitung bleibt das Altsystem zuständig. Für jede Art von Daten darf immer nur ein System Änderungen übertragen. Exporte, Zugriff und Kündigung richten sich nach dem Vertrag.

1. Dateninventar und Exportprobe – Datenliste und Probeexport

Erstelle vor jeder Einrichtung eine Liste der benötigten Daten. Dazu gehören Unterkünfte und Einheiten, Preise, Buchungsregeln, Steuern und Gebühren, künftige Reservierungen, Gäste- und Rechnungsfelder, Zahlungsstatus, Nachrichten, Bilder und Portalzuordnungen. Halte für jede Datenart fest:

• woher die Daten kommen und welches System dafür zuständig ist,
• ob es einen Export oder Zugang zur technischen Schnittstelle (API) gibt,
• welche Felder im Zielsystem gebraucht werden,
• wie lange Daten aufbewahrt und wann sie gelöscht werden müssen,
• wie Du die Übernahme per Anzahl, Summe oder Stichprobe prüfst,
• wer verantwortlich ist.

Die öffentliche Dokumentation der technischen Smoobu-Schnittstelle (API) belegt nicht automatisch, dass jedes Konto jedes historische Feld exportieren kann. Führe deshalb einen echten Stichprobenexport aus und gleiche ihn mit Konto, Vertrag und Zielimport ab.

2. Felder und Inhalte dem Ziel zuordnen

Kopiere die bestehende Struktur nicht einfach blind. Lege eine Tabelle an, die jedes alte Feld einem Ziel zuordnet. Das gilt für Unterkunft, Einheit, Preis, Buchungsregel, Steuer, Gebühr, Quelle, Gast, Unternehmen und Zahlungsstatus. Für jeden Wert gibt es genau eine dokumentierte Entscheidung: übernehmen, umwandeln, archivieren oder bewusst weglassen.

Prüfe die offiziell dokumentierten technischen Apaleo-Schnittstellen (APIs) für Dein tatsächliches Projekt. Eine vorhandene Schnittstelle bedeutet noch nicht, dass ein fertiger Import besteht oder alle Felder fachlich richtig zugeordnet sind.

3. Reservierungen und Zahlungen

Künftige Reservierungen benötigen mindestens Anreise, Abreise, Einheit, Status, Quelle, Preisbestandteile, Steuerlogik, Zahlungsstatus und Stornobedingung. Vergleiche Anzahl und Summen nach definierten Stichtagen. Historische Reservierungen können wegen Feldumfang, Datenschutz oder Zielsystemgrenzen anders behandelt werden als zukünftige Aufenthalte.

Übernimm Zahlungen nicht nur anhand eines Gesamtbetrags. Auch die Kennung beim Zahlungsdienst, Freigabe, Einzug, Erstattung, Rückbuchung und offene Forderung müssen richtig zugeordnet werden. Lege mit Buchhaltung oder Steuerberatung fest, welche Rechnungen im alten oder neuen System bleiben und wie Anfangsbestände dokumentiert werden. Das ist eine Prüfung für das Projekt und den Fachbereich, keine Rechts- oder Steuerberatung.

4. Buchungskanäle und Preise zuordnen

Dokumentiere für jedes Portal genau eine zuständige Verbindung. Ordne Zimmer oder Inserat, Preisplan, Verfügbarkeit, Mindestaufenthalt, Storno, Steuern und Gebühren zu. Teste nicht nur eine neue Buchung. Prüfe auch eine Änderung, eine Stornierung und einen absichtlich fehlerhaften Fall.

Das Umschalten ist je Portal unterschiedlich. Für Airbnb beschreibt die Channex-Dokumentation, dass eine bestehende Channel-Manager-Verbindung vor der neuen getrennt werden muss. Übertrage dieses Vorgehen nicht ungeprüft auf andere Portale.

Kontrollierter Parallelbetrieb – beide Systeme sicher testen

Ein paralleler Test bedeutet nicht, dass beide Systeme dieselben echten Daten gleichzeitig verändern. Vor dem Umschalten eines Portals kannst Du das Zielsystem mit Testdaten, Kopien und kontrollierten Verbindungen prüfen. Smoobu bleibt dabei für den laufenden Betrieb zuständig. Für jede Datenart muss feststehen:

• welches System nur lesen und welches Änderungen übertragen darf,
• wie Änderungen während des Übergangs nachgetragen werden,
• ab wann keine Änderungen mehr im alten System erlaubt sind,
• wer Unterschiede vergleicht,
• bei welchem Fehler der Wechsel gestoppt wird.

Nach dem Umschalten übernimmt das Zielsystem den jeweiligen Datenweg. Zwei Systeme dürfen nicht gleichzeitig dieselben Daten übertragen. Auch unkontrollierte Mischungen aus Kalenderdateien (iCal) und technischen Schnittstellen (API) bleiben gesperrt.

Checkliste vor dem Start

Vor der Freigabe dokumentiert das Team mindestens:

• Quell- und Zielzahlen der künftigen Reservierungen stimmen gemäß Abnahmeregel überein.
• Raten, Restriktionen, Steuern und Gebühren wurden je Kanal stichprobenartig geprüft.
• Testbuchung, Änderung und Storno erreichen die erwarteten Systeme.
• Zahlungs-, Rechnungs- und Erstattungsfälle haben benannte Verantwortliche.
• Nachrichten, Check-in und Zugänge wurden mit Testgästen geprüft.
• Überwachung, Warnungen und Kontakte für dringende Fehler sind aktiv.
• Der Zeitpunkt, ab dem im Altsystem nichts mehr geändert wird, das Umschaltfenster und der Kommunikationsweg sind bestätigt.
• Exportkopie, Zugänge und Vertragsfristen des Altsystems sind gesichert.

Rückfallplan

Der Rückfall zum alten System ist je Portal unterschiedlich. Er muss vor dem Trennen getestet oder zumindest vertraglich und technisch geklärt sein. Lege fest, welche Fehler den Rückfall auslösen, wer entscheidet, welche vollständige Datenkopie zuletzt vorlag und wie die alte Verbindung wiederhergestellt wird. Plane auch manuelle Notabläufe und die Kommunikation mit Gästen. Nicht jede Portalverbindung lässt sich sofort auf den alten Stand zurücksetzen. Dann kann es sicherer sein, vor dem nächsten Kanal zu stoppen.

Verantwortungsmatrix – wer entscheidet, ausführt und prüft

Dokumentiere für jede Aufgabe, wer entscheidet, wer sie ausführt und wer das Ergebnis prüft:

• Datenumfang und Aufbewahrung: Betreiber, Migrationsteam sowie Verantwortliche für Datenschutz und Fachfragen.
• Zuordnung von Unterkünften, Preisen und Kanälen: Betreiber, Einrichtungsteam und laufender Betrieb oder Preisverantwortung.
• Abgleich von Reservierungen und Zahlungen: Betreiber, Einrichtungsteam und Rezeption oder Buchhaltung.
• Umschalten der Portale: Betreiber, verantwortliche Person für die Verbindung und laufender Betrieb.
• Start oder Rückfall: Betreiber, Projektleitung und benannte Person für die Abnahme.

Die Namen, Erreichbarkeit und Vertretung gehören in den Projektplan. „Der Anbieter“ oder „die Verbindung“ sind keine ausreichenden Verantwortlichen.

Nach dem Umschalten

Prüfe Reservierungen, Verfügbarkeit, Preise, Zahlungen, Nachrichten und Zugänge für einen vorher festgelegten Zeitraum besonders eng. Sichere vor der Kündigung die vereinbarten Exporte. Kläre auch, wie lange das alte Konto noch lesbar bleibt. Für eine konkrete Einschätzung zum Umschalten und Rückfall führt der nächste Schritt zur Beratungsanfrage.