Zum Inhalt springen
← Impulse

So bewerten Sie die Portabilität einer SaaS-Lösung vor dem Vertragsabschluss

Prüfen Sie, ob sich eine SaaS-Lösung ersetzen lässt, ohne Daten zu verlieren oder Abläufe zu unterbrechen. Entscheidend sind Exporte, Abhängigkeiten, Ausstiegstests und klare Zuständigkeiten.

Team prüft einen Ausstiegsplan für eine SaaS-Lösung mit Daten, Abhängigkeiten und Integrationen

Eine Lösung kann den Download von Dateien ermöglichen und dennoch schwer zu ersetzen sein. Daten kommen möglicherweise ohne Beziehungen, Verlauf oder Kontext an; Automatisierungen hängen womöglich von proprietären Funktionen ab, und das Team weiß vielleicht nicht, wie es ohne den Anbieter weiterarbeiten soll. Deshalb bedeutet die Bewertung der Portabilität vor dem Vertragsabschluss mehr, als nur nach einer Exportfunktion zu fragen: Es geht darum zu prüfen, ob das Unternehmen die benötigten Inhalte wiederherstellen und seine Abläufe mit einer anderen Lösung oder aus eigener Kraft fortsetzen könnte.

Diese Prüfung ist besonders wichtig, wenn der Dienst kritische Informationen enthält, wiederkehrende Abläufe unterstützt oder mit anderen Systemen verbunden ist. Dafür muss nicht vom ersten Tag an eine vollständige Migration geplant werden. Es ist jedoch nötig zu verstehen, was übertragen werden müsste, welche Hindernisse bestehen und welche betrieblichen Kosten ein Ausstieg verursachen könnte. Das Ergebnis sollte den Vergleich verschiedener Optionen und die Verhandlung konkreter Bedingungen ermöglichen. Es sollte nicht zu der Annahme verleiten, jeder Anbieter biete einen reibungslosen Übergang.

Was es bedeutet, wenn eine Lösung portabel ist

Was es bedeutet, wenn eine Lösung portabel ist

Portabilität ist die praktische Fähigkeit, die für die Fortsetzung einer Tätigkeit erforderlichen Ressourcen wiederherzustellen und außerhalb der aktuellen Lösung weiterzuverwenden. Dazu zählen Daten, aber auch Struktur, Berechtigungen, Geschäftsregeln, Integrationen, Dokumentation und betriebliches Wissen. Die technische Verfügbarkeit eines Exports allein beweist nicht, dass sich der Dienst ersetzen lässt. Es muss geprüft werden, ob sich die exportierten Inhalte verstehen, validieren und in eine alternative Umgebung übertragen lassen.

Es empfiehlt sich, drei Fragen zu unterscheiden:

  • Lassen sich die Daten abrufen? Ermitteln Sie, welche Datensätze enthalten sind, in welchem Format sie vorliegen und welche Einschränkungen gelten.
  • Lassen sich Beziehungen und Kontext rekonstruieren? Prüfen Sie Kennungen, Status, Anhänge, Zeitangaben, Berechtigungen und Verknüpfungen zwischen Entitäten.
  • Kann der Betrieb während des Wechsels aufrechterhalten werden? Berücksichtigen Sie Prozesse, Nutzerinnen und Nutzer, Integrationen, Schulungen und eine mögliche Übergangsphase mit parallelem Betrieb.

Bei der Bewertung sollte außerdem getrennt werden, was vom Anbieter und was vom eigenen Unternehmen abhängt. Der Anbieter kann Werkzeuge und Dokumentation bereitstellen; das Unternehmen muss trotzdem festlegen, was kritisch ist, wer die Informationen überprüft und wie der Übergang umgesetzt werden soll.

Daten und Ressourcen erfassen, die verfügbar sein müssen

Beschreiben Sie zunächst die Anwendungsfälle, die von der Lösung unterstützt werden, und die dafür unverzichtbaren Ressourcen. Beschränken Sie die Bestandsaufnahme nicht auf die Hauptdatenbank. Je nach Produkt können Anhänge, Kommentare, historische Einträge, Vorlagen, Berichte, Konfigurationen, Berechtigungen, Automatisierungsregeln und Kataloge relevant sein. Berücksichtigen Sie auch Daten, die durch Integrationen erzeugt oder für Entscheidungen abgefragt werden.

Halten Sie für jede Ressource fest, wem sie gehört, wie kritisch sie ist, woher sie stammt, wohin sie übertragen werden könnte und wie häufig sie aktualisiert wird. Kennzeichnen Sie, welche Informationen für den Betrieb erforderlich sind, welche aus internen oder regulatorischen Gründen aufbewahrt werden müssen und auf welche verzichtet werden könnte. Gehen Sie nicht davon aus, dass ein Export alles enthält: Prüfen Sie ausdrücklich, ob Verlauf, Metadaten, Beziehungen sowie gelöschte oder archivierte Elemente enthalten sind, sofern diese relevant sind.

Eine einfache Tabelle hilft dabei, abstrakte Fragen in konkrete Prüfungen zu übersetzen:

  • Ressource: Kontakte, Bestellungen, Dokumente, Konfigurationen oder Aktivitätsprotokolle.
  • Verwendung: Der Prozess, der auf die Ressource angewiesen ist, und die Folgen eines Verlusts.
  • Erwarteter Export: Format, Struktur, Häufigkeit und ungefähres Volumen.
  • Validierung: Zuständige Person und Kriterien zur Bestätigung von Vollständigkeit und Nutzbarkeit.

Diese Bestandsaufnahme verhindert sowohl eine Unterschätzung des Umfangs als auch die Migration von Informationen ohne betrieblichen Nutzen. Außerdem lässt sich so ein Ausstiegstest auf die Daten konzentrieren, die den Dienst tatsächlich tragen.

Exporte und tatsächliche Bedingungen überprüfen

Fordern Sie konkrete Unterlagen zu den verfügbaren Exportmethoden an und prüfen Sie die Bedingungen des in Betracht gezogenen Tarifs. Fragen Sie, ob der Export manuell, automatisiert oder über eine API zugänglich ist, welche Formate erzeugt werden, ob Mengen- oder Häufigkeitsbeschränkungen gelten und ob die für den Abgleich von Datensätzen erforderlichen Kennungen erhalten bleiben. Die Antworten können je nach Produkt oder Tarif unterschiedlich ausfallen. Lassen Sie sie sich daher schriftlich geben und verlassen Sie sich nicht auf eine Verkaufspräsentation.

Bitten Sie, wenn möglich, um eine repräsentative Beispieldatei und lassen Sie diese von einer Person prüfen, die mit den Daten vertraut ist. Eine Datei, die sich öffnen lässt, ist nicht zwangsläufig wiederverwendbar: Achten Sie auf fehlende Felder, schwer interpretierbare Kodierungen, mehrdeutige Datumsangaben, unterbrochene Beziehungen und Anhänge, die von den zugehörigen Datensätzen getrennt sind. Prüfen Sie auch, ob die Dokumentation das Schema erläutert und die Bedeutung der Felder verständlich macht, statt lediglich ihre Namen aufzulisten.

Klären Sie die Bedingungen für den Zugriff und die Aufbewahrung während eines Ausstiegs: Wann kann der Export gestartet werden? Wie lange bleiben die Daten nach Vertragsende verfügbar? Was geschieht mit Kopien und welche Unterstützung beim Übergang ist vorgesehen? Gehen Sie nicht davon aus, dass ein bestimmtes Zeitfenster, Format oder eine bestimmte Dienstleistung angeboten wird, solange dies nicht im Vertrag oder in den einschlägigen Unterlagen bestätigt ist. Sind sensible Daten betroffen, sollten Sicherheit und Datenschutz in die Prüfung der Übertragungs-, Zugriffs- und Löschverfahren einbezogen werden.

Abhängigkeiten erfassen, die im Export nicht sichtbar sind

Daten können exportiert werden, während die Möglichkeit, sie zu nutzen, im Produkt verbleibt. Erfassen Sie Integrationen, Zugangsdaten, Webhooks, Automatisierungen, Berechtigungsmodelle, Identitäten und Regeln, die den Dienst mit dem übrigen Betrieb verbinden. Halten Sie fest, welches System die jeweiligen Daten erzeugt, welches sie verwendet und wer die Verbindung betreut. Auch eine scheinbar nebensächliche Integration kann Abrechnung, Kundenservice oder Managementberichte unterstützen.

Berücksichtigen Sie auch die Abhängigkeit von einzelnen Personen. Wenn nur eine Person weiß, wie Ausnahmen behandelt werden, was bestimmte Status bedeuten oder wie Fehler behoben werden, besteht selbst bei einem vollständigen Export ein Risiko für die Betriebskontinuität. Dokumentieren Sie manuelle Aufgaben, Verfahren, betriebliche Entscheidungen und das Wissen, das für die Einarbeitung eines Ersatzteams benötigt wird.

Eine hilfreiche Übersicht muss keine vollständige Architekturdokumentation sein. Es reicht, kritische Prozesse, verbundene Systeme, Zuständigkeiten und Fehlerquellen darzustellen. Unterscheiden Sie zwischen Abhängigkeiten, die sich mit vertretbarem Aufwand nachbilden lassen, Funktionen, die eine Neugestaltung des Prozesses erfordern würden, und Fähigkeiten ohne erkennbare Alternative. Diese Unterscheidung hilft bei der Entscheidung, ob die Nutzung proprietärer Funktionen reduziert oder eine betriebliche Alternative beibehalten werden sollte.

Einen dem Risiko angemessenen Ausstiegstest planen

Führen Sie einen begrenzten Test durch, bevor Sie wichtige Prozesse an die Lösung binden. Wählen Sie eine repräsentative Auswahl an Datensätzen und einen Geschäftsprozess aus. Exportieren Sie die Informationen, importieren oder verarbeiten Sie sie in einer unabhängigen Umgebung und prüfen Sie, ob das Team die wesentlichen Aufgaben erledigen kann. Dafür ist keine parallele Plattform erforderlich. Ziel ist es, Format-, Kontext-, Berechtigungs- oder Verfahrensprobleme zu erkennen, solange noch Spielraum für eine Anpassung der Entscheidung besteht.

  1. Legen Sie fest, welcher Prozess und welche Daten getestet werden und welches Ergebnis als akzeptabel gilt.
  2. Benennen Sie Verantwortliche für den Export, die technische Prüfung und die betriebliche Validierung.
  3. Dokumentieren Sie Probleme, manuelle Arbeit, externe Abhängigkeiten und unbestätigte Annahmen.
  4. Entscheiden Sie, was vor einer Ausweitung der Nutzung korrigiert, dokumentiert oder verhandelt werden muss.

Die Tiefe des Tests sollte sich nach Kritikalität, Datenvolumen und Ersetzbarkeit richten. Bei einem ergänzenden Werkzeug kann es genügen, einen Export zu prüfen und die Schritte zu dokumentieren. Bei einem System, das essenzielle Abläufe trägt, kann es erforderlich sein, den Datenabgleich, die Wiederherstellung von Integrationen und einen vorübergehenden Parallelbetrieb zu erproben. Legen Sie außerdem Kriterien fest, um den Test abzubrechen oder rückgängig zu machen, falls er den Produktivbetrieb beeinträchtigt.

Den Ausstiegsplan in eine Kaufentscheidung einbeziehen

Den Ausstiegsplan in eine Kaufentscheidung einbeziehen

Ein brauchbarer Ausstiegsplan benennt, wer über die einzelnen Schritte entscheidet und sie ausführt, was zuerst migriert wird, wie die Informationen validiert werden, welche Systeme koordiniert werden müssen und wie der Dienst während des Übergangs aufrechterhalten wird. Planen Sie bei Bedarf einen Parallelbetrieb sowie einen Rückweg mit klaren Bedingungen ein: etwa, welche Fehler eine Fortsetzung verhindern und wer die Rückkehr zum vorherigen Zustand genehmigt. Legen Sie keine Fristen oder Kosten fest, die nicht durch überprüfte Schätzungen gestützt sind.

Fragen Sie den Anbieter im Rahmen der Bewertung, wer einen Export starten kann, welche technische Dokumentation vorliegt, welche Einschränkungen für den Anwendungsfall gelten, wie Integrationen verwaltet werden und welche Unterstützung beim Übergang tatsächlich enthalten ist. Bitten Sie darum, relevante Antworten in verbindliche Vereinbarungen aufzunehmen. Warnzeichen sind vage Antworten, fehlende Möglichkeiten zum Testen des Exports, undokumentierte Formate, nicht erklärte Abhängigkeit von manuellen Eingriffen und unklare Bedingungen für den späteren Datenzugriff.

Überführen Sie die Erkenntnisse schließlich in eine ausdrückliche Entscheidung: das Risiko mit geeigneten Kontrollen akzeptieren, Änderungen verhandeln, die in der Lösung gespeicherten Daten oder Prozesse begrenzen, eine Alternative bereithalten oder die Lösung ablehnen. Portabilität beseitigt nicht jede Abhängigkeit, macht sie aber sichtbar und ermöglicht eine bewusste Entscheidung darüber, ob sie tragbar ist. Wird der Plan bei Änderungen an Prozessen oder Integrationen überprüft, bleibt die Entscheidung aktuell und Hindernisse werden nicht erst entdeckt, wenn ein Ausstieg dringend wird.

Fuentes y referencias

  1. Web standardsW3C
  2. OWASP Cheat Sheet SeriesOWASP Foundation
  3. Web performanceweb.dev