Warum der Umstieg gefühlt größer ist, als er tatsächlich ist
Die meisten Praxen verschieben den Wechsel jahrelang, weil sie Datenverlust fürchten. Diese Sorge ist verständlich – aber bei sauberer Vorbereitung selten begründet. Mit einer geordneten Vorgehensweise dauert die eigentliche Migration drei bis sieben Werktage. Während dieser Zeit läuft Deine bisherige Software weiter, Du wechselst zum vereinbarten Stichtag.
In den begleiteten Migrationsprojekten der letzten Monate – von der Einzelpraxis mit 800 Patientinnen und Patienten bis zur Klinik mit drei Standorten – waren die größten Stolperfallen nie technisch, sondern organisatorisch. Das Team-Onboarding entscheidet mehr über den Erfolg als die Datenbank-Konvertierung.
Was Du vor dem Umzug entscheiden sollten
Drei Entscheidungen vorab sparen Dir später viele Stunden:
Cutover-Datum festlegen. Lege einen konkreten Stichtag fest, an dem das alte System eingefroren wird. Erfahrungsgemäß funktionieren Wochenenden oder Brückentage am besten – minimaler Patientenkontakt, Dein Team kann sich konzentrieren.
Historien-Tiefe entscheiden. Du musst nicht alle 18 Jahre Karteikarten-Historie umziehen. Standard sind drei Jahre vollständige Behandlungsverläufe, alles davor als PDF-Archiv. Das spart Migrationszeit und vermeidet Performance-Probleme.
Parallelbetrieb ja oder nein. Manche Praxen lassen die alte Software für Lese-Zugriff weiterlaufen, andere ziehen einen klaren Schnitt. Beides hat Vor- und Nachteile. Empfehlung: zwei Wochen Lese-Zugriff parallel, dann Cutover.
Aufbewahrungsfristen beachten
Die alte Software darf nicht einfach abgeschaltet werden. Behandlungsdokumentation und Impfeinträge unterliegen nach § 12 TÄHAV einer Aufbewahrungsfrist von 10 Jahren. Steuer- und buchhaltungsrelevante Daten (Rechnungen, GoBD-Daten) müssen nach § 147 AO mindestens 10 Jahre vorgehalten werden. Praktisch bedeutet das:
- Alle Behandlungs- und Buchhaltungs-Daten der letzten 10 Jahre müssen entweder migriert oder als revisionssicheres Archiv (PDF/A oder Datenbank-Dump) gesichert werden
- Das Altsystem darf erst abgeschaltet werden, wenn der Datenbestand nachweislich exportiert ist
- Backup-Strategie für das Archiv: 3-2-1-Regel (3 Kopien, 2 Medien, 1 extern)
Die 7 Datenbereiche, die wirklich umziehen müssen
In jedem Praxisprogramm gibt es genau diese sieben Bereiche, die migriert werden:
- Tierhalter-Stammdaten: Name, Anschrift, Kontakt, Kommunikationspräferenzen
- Tier-Stammdaten: Spezies, Rasse, Chip, Geburtsdatum, Allergien, Medikation
- Behandlungs-Historie: SOAP-Einträge der letzten drei Jahre
- Termine: offene Termine ab Cutover-Datum
- Rechnungen und GOT-Leistungen: offene Beträge der letzten zwei Jahre
- Impfungen: kompletter Verlauf pro Tier
- Mahnwesen: offene Stufen pro Halter
Alles andere – etwa interne Notizen, alte Protokolle, ausgelaufene Belege – kannst Du im alten System belassen oder als ZIP archivieren.
Der Export aus Deiner bisherigen Praxissoftware
Praxisprogramme unterscheiden sich im Detail beim Export, aber das Vorgehen ist immer gleich:
- Datenbank vor dem Export konsolidieren. Die meisten Systeme haben ein Wartungs-Menü, das Dubletten und inkonsistente Einträge markiert. Eine halbe Stunde Aufräumen spart später Stunden.
- Dubletten zuerst im Altsystem zusammenführen. Zwei Akten für dasselbe Tier wandern sonst auch doppelt ins neue System.
- Export-Encoding prüfen. Manche Systeme exportieren standardmäßig in Latin-1, was deutsche Umlaute zerstört. Setze UTF-8 als Zielkodierung.
- Datumsformat auf ISO 8601 konvertieren. Deutsches Format (
01.04.2026) wird von vielen Import-Tools nicht richtig erkannt, ISO 8601 (2026-04-01) ist unmissverständlich. - Bei mehreren Standorten: standortweise exportieren. Wir importieren parallel und mappen die Standort-Felder korrekt.
Petflare nimmt CSV-, XML- und JSON-Exports entgegen, validiert Felder und zeigt Dir vor dem Übernehmen Konflikte an. Typische Konflikte sind unsaubere Anrede-Felder („Hr.", „Hr", „Herr") oder Chipnummern in unterschiedlichen Formaten.
Was tun, wenn der Export scheitert?
Drei Szenarien, die in der Praxis vorkommen:
Hersteller verweigert Datenexport oder verlangt hohe Gebühren. Rechtliche Position: Du bist als Praxis Eigentümer:in der Daten, die Software ist nur Verwalterin. Das ergibt sich aus dem allgemeinen Datenschutzrecht (DSGVO Art. 20 Datenportabilität für personenbezogene Daten der Halter:innen) und aus dem Vertragsrecht – auch in den AGB der Software muss eine Daten-Herausgabepflicht bei Vertragsende stehen. Wenn nicht: Schreiben des Anwalts genügt meist.
Support antwortet nicht. Eskalations-Pfad: Erst E-Mail mit Fristsetzung (14 Tage), dann Einschreiben mit Rückschein an die Geschäftsführung, dann anwaltliches Schreiben. Parallel selbst Daten extrahieren, soweit über Reports und Drucken-zu-PDF möglich.
Export-Datei ist unbrauchbar (kaputt, unvollständig). Stichproben-Validierung sofort nach Export, nicht erst beim Import. Bei Unstimmigkeiten Hersteller mit konkretem Fehlerprotokoll konfrontieren – das ist erfahrungsgemäß der schnellste Weg zu einem brauchbaren Export.
Mitarbeiter-Schulung: der häufigste Stolperstein
In den begleiteten Migrationen war Team-Training der Faktor mit dem größten Effekt auf die Akzeptanz im Alltag. Wer am Cutover-Tag das neue System zum ersten Mal sieht, kommt in Stress – und drückt im Zweifel auf das, was er kennt (das alte System). Empfehlung:
- 2 Wochen vor Cutover: Test-Umgebung mit Beispiel-Daten, jede:r Mitarbeitende führt einen typischen Tagesablauf durch (Termin anlegen, Patient empfangen, Behandlung dokumentieren, Rechnung erstellen)
- 1 Woche vor Cutover: Live-Umgebung mit echten Halter-Daten zum Lesen, schreibgeschützt
- 1 Tag vor Cutover: Final-Briefing mit Notfall-Kontakt, Rollback-Plan, Pausen-Vertretung
- Cutover-Tag selbst: mindestens eine Person als „Migrations-Lotse" freigestellt – nicht behandelnd, ausschließlich für Fragen
Wer die Schulung auf den Cutover-Tag verschiebt, riskiert Doppelaufwand für Wochen. Der Schulungs-Aufwand vorab amortisiert sich in den ersten 14 Tagen Live-Betrieb.
Zeitplan: Woche -4 bis Woche +2
| Phase | Aktivität |
|---|---|
| Woche -4 | Cutover-Datum fixieren, Vertrag mit Altsystem über Datenherausgabe sicherstellen |
| Woche -3 | Datenbank im Altsystem konsolidieren, Dubletten zusammenführen |
| Woche -2 | Test-Migration in Sandbox-Umgebung, Team-Schulung Tag 1 |
| Woche -1 | Live-Daten-Schulung, Stichproben-Plan validieren, Notfall-Kontakte vereinbaren |
| Cutover-Wochenende | Datenexport, Import, Validierung, Go-live |
| Woche +1 | Doppelte Augen auf jeder Buchung, Migrations-Lotse vor Ort |
| Woche +2 | Letzte Halter-Anfragen aus Altsystem, dann Lese-Zugriff abschalten |
Qualitätscheck vor dem Go-live
Vor dem Live-Schalten machst Du vier Stichproben:
- 10 zufällige Halter: alle Pflichtfelder vorhanden, Tiere korrekt verknüpft
- 5 Behandlungsverläufe: SOAP-Einträge lesbar, Diagnosen vorhanden
- 5 offene Rechnungen: Beträge stimmen, Status korrekt
- 5 Impfschemata: nächste Fälligkeit plausibel
Wenn das passt, ist die Migration solide. Findest Du Auffälligkeiten, klären wir vor Go-live – nicht danach.
Vertragsende der Altsoftware
Mit dem Cutover ist die Altsoftware nicht automatisch gekündigt. Drei Punkte sind zu klären:
- Kündigungsfrist: Steht im Vertrag, häufig 3 Monate zum Quartalsende. Frühzeitig kündigen, sonst zahlen Du länger als nötig parallel.
- Daten-Herausgabe: Bei Vertragsende muss der Anbieter die Daten in maschinenlesbarem Format zur Verfügung stellen. Fixe Frist im Kündigungsschreiben setzen.
- Software-Lizenz und Wartung: Lizenzen verfallen mit Vertragsende. Wer nach Vertragsende noch Lese-Zugriff für die 10-jährige Aufbewahrungsfrist braucht, sollte das vorher schriftlich vereinbaren oder ein revisionssicheres Datenbank-Archiv anfordern.
Parallelbetrieb: 2 Wochen sind genug
Längerer Parallelbetrieb hilft niemandem. Dein Team gewöhnt sich nicht an das neue System, weil es immer wieder ins alte zurückfällt. Zwei Wochen Lese-Zugriff auf das Altsystem sind ausreichend für historische Recherchen, danach wird abgeschaltet.
In der Übergangszeit gilt strikt: Neue Termine, Behandlungen und Rechnungen werden ausschließlich in Petflare angelegt. Wer das im Altsystem macht, riskiert Datenverlust beim endgültigen Cutover.
Checkliste zum Abhaken
- Cutover-Datum fixiert (am besten Wochenende oder Brückentag)
- Historien-Tiefe entschieden (Empfehlung: 3 Jahre vollständig, älter als Archiv)
- Parallelbetrieb-Strategie definiert (max. 2 Wochen Lese-Zugriff)
- Aufbewahrungsfrist § 12 TÄHAV und § 147 AO beachtet, Archiv-Lösung geplant
- Altsystem-Datenbank konsolidiert
- Dubletten im Altsystem zusammengeführt
- Halter ohne Aktivität in den letzten 3 Jahren bereinigt
- Export-Encoding auf UTF-8 gesetzt
- Datumsformat auf ISO 8601 konvertiert
- Stichproben-Plan erstellt (10 Halter, 5 Verläufe, 5 Rechnungen, 5 Impfungen)
- Team-Schulung 2 Wochen vor Go-live in Sandbox
- Live-Daten-Schulung 1 Woche vor Go-live
- Migrations-Lotse für Cutover-Tag freigestellt
- Notfall-Kontakt für die ersten 48 Stunden vereinbart
- Altsystem-Kündigung mit fixer Frist eingereicht
- Daten-Herausgabe schriftlich bestätigt
Wer diese Liste systematisch abarbeitet, hat eine sehr gute Chance auf einen reibungslosen Umstieg. Den Rest übernimmt unser Migrations-Team in direkter Abstimmung mit Deinem Praxis-Team.
Häufige Fehler beim Cutover
Aus den letzten begleiteten Migrationen wiederholen sich vier Fehler-Muster, die alle vermeidbar sind:
- Cutover an einem Wochentag mit hohem Patientenaufkommen. Wer den Stichtag auf einen Dienstag legt, hat am Mittwoch das Chaos. Wochenende oder Brückentag, immer.
- Kein klarer Notfall-Kontakt. Wenn am Cutover-Tag etwas nicht läuft, brauchen Praxis-Team und Migrations-Team eine direkte Telefonleitung. WhatsApp-Gruppe oder Slack-Channel funktioniert hier besser als E-Mail.
- Stichproben erst nach Go-live. Stichproben gehören vor das Live-Schalten. Wenn nach Go-live Probleme auftauchen, müssen sie unter Zeitdruck gelöst werden – das vervielfacht den Stress.
- Kein Rollback-Plan. Was passiert, wenn am Cutover-Tag etwas nicht funktioniert? Klare Antwort: Altsystem läuft weiter, Cutover wird verschoben. Diese Entscheidung muss vorab schriftlich definiert sein, damit niemand im Stress eine Bauchentscheidung trifft.
Häufige Fragen
Was passiert mit den E-Mail-Verläufen aus dem Altsystem? Wenn das Altsystem ein internes Mail-System hat, wandern die Verläufe als PDF-Archiv mit. Künftige Halter-Kommunikation läuft über das neue System. Halter:innen müssen einmalig hinweisen werden, dass die alte Adresse nicht mehr gepflegt wird.
Wie verfahre ich mit alten Röntgenbildern? Bilder gehören in ein PACS-System (DICOM-Standard) und werden separat behandelt. In Petflare lassen sich Röntgenbilder per DICOM-Schnittstelle anbinden – die Migration läuft dann parallel zur Stammdaten-Migration.
Können wir während der Migration neue Patient:innen anlegen? Ja, im Petflare-System ab Cutover-Datum. Die Altsystem-Bestandsdaten werden nicht überschrieben. Wichtig ist, dass nach Cutover keine neuen Daten mehr im Altsystem entstehen, sonst entsteht ein Datenfork.
Was kostet eine Migration typischerweise? Der Aufwand variiert stark nach Datenvolumen, Altsystem-Qualität und Anzahl Standorte. Eine saubere Einzelpraxis ist meist innerhalb der Standard-Onboarding-Phase migrierbar; Klinik-Migrationen mit komplexer Daten-Historie laufen als individuelles Projekt. Konkrete Schätzung gibt's nach Sichtung des Altsystem-Exports.
