Zahlungstoken und gespeicherte Karten migrieren

Die Frage, die eine Migration leise versenkt

Wenn ein Shop den Umzug auf einen neuen Store plant, stellt irgendwann jemand die harmlose Frage: Was passiert eigentlich mit den gespeicherten Karten der Kunden? Die Erwartung ist fast immer, dass die gespeicherten Karten irgendwo Zeilen in einer Datenbank sind und dass man sie wie jede andere Tabelle kopiert. Sind sie nicht, und so geht es auch nicht. Eine gespeicherte Karte ist eines der wenigen Dinge in deinem Shop, die du tatsächlich nicht besitzt, nicht lesen kannst und nicht einfach mitnimmst. Wer das falsch macht, bekommt keinen ordentlichen Fehler. Er bekommt einen Monat voller fehlgeschlagener Verlängerungen, eine Welle von Kunden, die um sechs Uhr früh eine Karte eintippen sollen, und eine Abwanderung, die sich nicht mehr rückgängig machen lässt.

Ich baue individuelle Stores auf Solidus, dem quelloffenen Ecommerce Framework auf Basis von Ruby on Rails, und ich führe die Migrationen darauf durch. Gespeicherte Karten und die Zahlungstoken dahinter sind das eine Thema, bei dem ich besonders darauf achte, einer Kundin die Wahrheit zu sagen, bevor irgendjemand etwas unterschreibt. Dieser Artikel ist diese Wahrheit, ausgeschrieben. Er verweist auf den Elternartikel darüber, was sich übertragen lässt und was nicht, und er steht neben dem Begleitstück zu Abonnements und wiederkehrenden Zahlungen, wo dasselbe Tokenproblem am härtesten zuschlägt.

Wie eine gespeicherte Karte wirklich abgelegt ist

Fang damit an, wo die Karte liegt. Wenn eine Kundin an deiner Kassa eine Karte speichert, behält dein Shop nicht die Kartennummer. Die lange Nummer auf der Vorderseite, die Primary Account Number oder PAN, liegt bei deinem Payment Gateway oder Abwickler in dessen eigenem sicheren Tresor. Im Gegenzug bekommt dein Shop einen Token: eine kurze, bedeutungslose Referenz, die stellvertretend für die Karte steht. Deine Datenbank speichert diesen Token. Beim nächsten Mal schickst du dem Gateway den Token, und es sucht die echte Karte für dich heraus.

Das ist keine Spitzfindigkeit. Es ist der ganze Grund, warum ein normaler Shop überhaupt Karten annehmen kann, ohne die Kosten und die Prüflast des Umgangs mit echten Kartennummern. Weil du die PAN nie selbst speicherst, verarbeitest oder überträgst, bleibst du in der leichtesten Stufe des Sicherheitsstandards der Kartenindustrie, was für die meisten Shops eine kurze Selbstauskunft statt einer vollen Prüfung bedeutet. Diesen Geltungsbereich erkläre ich in PCI DSS erklärt. Der Tresor hält dich im Leichten. Der Token ist die Quittung.

Ein Ding wird nie aufbewahrt, von niemandem, nicht einmal verschlüsselt und nicht einmal mit schriftlicher Zustimmung der Kundin: die drei oder vier Ziffern der Kartenprüfnummer. Das PCI Security Standards Council sagt klar, dass die Prüfnummer nicht aufbewahrt werden darf, sobald die Zahlung, für die sie erhoben wurde, autorisiert ist, und dass sie für Card on File oder wiederkehrende Abbuchungen nicht gebraucht wird.¹ Du brauchst sie nicht, um eine gespeicherte Karte zu belasten, das kostet dich also nichts. Aber es ist das erste Anzeichen, dass die Vorstellung, einfach alles zu exportieren, nie wörtlich stimmt.

Ein Token des einen Gateways bedeutet dem anderen nichts

Hier ist die Einschränkung, die alles Weitere bestimmt. Der Token, den dein Shop hält, gehört genau zu dem Gateway, das ihn ausgegeben hat. Er ist eine Referenz in den Tresor dieses Gateways und nirgendwo sonst. Gib denselben Token einem anderen Gateway, und er ist Rauschen. Es gibt kein gemeinsames Format, keinen Austausch, keine Übersetzungstabelle, die den Token von Gateway A in einen von Gateway B verwandelt.

Die naheliegende Idee, die Token zu exportieren und in den neuen Store zu laden, funktioniert also nicht. Und die nächste Idee, die echten Kartennummern zu exportieren und selbst im neuen Gateway zu speichern, ist schlimmer. Ein normaler Händler darf die Kartennummern seiner Kunden nicht in eine Tabelle ziehen und von Hand umziehen. Genau das ist der Umgang mit echten Kartendaten, von dem dich die ganze Tokenlogik fernhalten soll, und es würde dich in einen Geltungsbereich und eine Haftung ziehen, die du nicht willst. Die Kartennummern gehören dir auch nicht. Das Gateway hält sie für dich unter seiner eigenen Compliance und gibt sie nur über einen kontrollierten Ablauf an eine andere Stelle, der man das Empfangen zutrauen kann.

Deshalb ist der Begriff gespeicherte Karten migrieren falsch. Der ehrliche Begriff ist den Tresor migrieren, und das können nur die Gateways tun, und nur manche tun es.

Den Tresor migrieren, von Gateway zu Gateway, wie es wirklich geht

Es gibt einen etablierten, konformen Weg, und er lohnt sich im Detail, denn genau zu wissen, wie er funktioniert, unterscheidet einen umkehrbaren Umzug von einer Falle.

Die Kartennetzwerke und der Sicherheitsstandard erlauben beide eine sichere Übertragung der getresorten Kartendaten von einem Anbieter mit PCI DSS Level 1 zu einem anderen. Level 1 ist die oberste Stufe des Standards, die für die größten Abwickler gilt und eine volle externe Prüfung trägt. Die Übertragung läuft von Anbieter zu Anbieter, von Ende zu Ende verschlüsselt, und der Händler sieht an keiner Stelle eine Kartennummer. In der Praxis veröffentlicht der empfangende Abwickler die Bedingungen, die er akzeptiert. Stripe etwa empfängt oder sendet Kartendaten nur von bzw. zu einem anderen nach PCI DSS Level 1 konformen Abwickler und verlangt dessen aktuelle Konformitätsbescheinigung (oder den Eintrag im Dienstleisterregister von Visa) sowie einen öffentlichen Schlüssel von mindestens 4.096 Bit, gehostet über eine gesicherte Verbindung auf einer eigenen Domain des Abwicklers.² Die Daten selbst werden mit diesem Schlüssel verschlüsselt und über einen eigenen sicheren Dateiserver bewegt. Der Händler liefert keine Kartennummern und fasst keine an.³

Was herüberkommt, sind die gespeicherten Kartendetails und die Rechnungsadressen, mehr nicht. Die Prüfnummer zieht nicht mit, aus dem oben genannten Grund.¹ Zahlungshistorie, vergangene Abbuchungen, Abonnements und Rechnungen laufen über diese Übertragung gar nicht, das sind eigene Probleme mit eigenen Werkzeugen.² Wenn der Import fertig ist, liefert der empfangende Abwickler eine Zuordnungsdatei: eine Liste, die jede alte Kunden und Kartenkennung mit ihrer neuen paart, damit dein neuer Store jeden gespeicherten Kartensatz auf den neuen Token umstellt, bevor die erste Abbuchung läuft.³

Zwei Zahlen zählen für die Planung. Der Import selbst geht meist schnell, sobald saubere Daten ankommen. Der langsame, unsichere Teil ist der Export auf der abgebenden Seite, den der empfangende Abwickler nicht steuern kann und der je nach Ablauf, Formularen und Gebühren des anderen Anbieters ein paar Tage bis mehrere Monate dauert.³ Deshalb ist die Exportanfrage das Erste, was du losschickst, nicht das Letzte.

Die Quelle muss den Tresor freigeben

Jedes Wort oben setzt eines voraus: dass dein aktueller Anbieter den Tresor freigibt. Die meisten gängigen Abwickler tun das. Dein Vertrag verpflichtet sie oft, deine Daten auf Anfrage zurückzugeben, und ein fähiges empfangendes Team steigt in das Gespräch ein und hilft, es voranzubringen.³ Ein Anbieter mit einem veröffentlichten, wiederholbaren Exportablauf ist ein Anbieter, den du verlassen kannst, und das ist beim Unterschreiben mehr wert als eine etwas niedrigere Gebühr, denn ein Anbieter, den du nicht verlassen kannst, kann die Gebühr später erhöhen.

Aber nicht jeder Kartentresor sitzt hinter einem Anbieter, der ihn gehen lässt. Manche Zahlungsprodukte sind mit der Plattform verschweißt, auf der der Shop läuft. Die Plattform hält den Tresor, behandelt ihn als Teil ihres eigenen Dienstes und bietet keinen Weg, die zugrunde liegenden Kartendaten an einen externen Abwickler zu exportieren. Wenn das die Konstellation ist, kommt die Übertragung von Gateway zu Gateway schlicht nicht infrage, und die Token können gar nicht herüber.

Ein anonymisiertes Lehrstück

Ich halte das bewusst vage, denn es geht um die Form der Falle und nicht um Namen. Ein echtes Abo Unternehmen wollte zu einem günstigeren Gateway wechseln. Es hatte seine wiederkehrende Abrechnung auf dem eigenen Zahlungsprodukt der Plattform aufgebaut, das Abonnements nur über dieses Produkt und über ein einziges dahinter benanntes Gateway erlaubte. Die getresorten Karten lagen bei diesem Gateway, nicht beim Händler, und es gab keinen Export irgendwohin. Das Unternehmen konnte seinen Katalog, seine Kunden und seine Inhalte umziehen, aber die gespeicherten Karten und die laufenden Abos dahinter waren an das Produkt gebunden, das es verlassen wollte. Es zog trotzdem teilweise um und endete mit dem Schlechtesten aus beiden Welten: einem neuen Shop, der seine bestehenden Abonnenten nicht abbuchen konnte, und einem alten System, für das es nur deshalb weiterzahlte, weil dort noch die Karten der zahlenden Kunden lagen. Die harte Lehre ist, dass all das vor dem Umzug absehbar war. Die längere Fassung, wie Gateway Bindungen Leute erwischen, erzähle ich in den versteckten Gefahren beim Wechsel des Payment Gateways.

Was sich bewegen lässt und was nicht, in einem Blick

Vor den Notbehelfen hier die ehrliche Zusammenfassung, wo jedes Stück steht.

Was du hast	Zieht es um?	Der ehrliche Plan
Die gespeicherte Kartennummer (PAN)	Nur von Anbieter zu Anbieter, verschlüsselt, Level 1 zu Level 1, wenn die Quelle zustimmt	Zuerst den Export anfordern, dann klären, ob das Ziel empfängt
Deine Gateway Token	Nein, sie bedeuten jedem anderen Gateway nichts	Werden durch die eigenen Token des Ziels ersetzt, über die Tresorübertragung
Die Kartenprüfnummer	Nie, für niemanden	Zum Belasten einer gespeicherten Karte nicht nötig
Nachweis früherer Authentifizierung	Ja, als Netzwerk Transaktions ID, wenn die Quelle sie mitgibt	Im Export verlangen, damit Kunden nicht erneut geprüft werden
Zahlungshistorie und Abonnements	Nicht über die Kartenübertragung	Eigene Werkzeuge, alte Pläne beenden, sobald neue laufen
Ein an ein Plattformprodukt gebundener Tresor	Oft gar nicht	Vor dem Festlegen entscheiden, dann das erneute Erheben einplanen

Netzwerktoken sind keine Migration, aber sie helfen

Wenn eine saubere Tresorübertragung verfügbar ist, nimm sie. Wenn sie heikel ist, oder wenn du die Karten, die du bewegst, so haltbar wie möglich machen willst, lohnen sich zwei Dienste auf Netzwerkebene. Sie werden oft mit Migration verwechselt. Keiner ist eine Migration, und das klar zu sagen gehört dazu, das ehrlich zu machen.

Der erste ist der Netzwerktoken. Statt dass dein Gateway die echte Kartennummer speichert und seinen eigenen privaten Token prägt, können die Kartennetzwerke einen Token auf Netzwerkebene ausgeben, der über die ganze Lebensdauer für die Karte steht. Mastercard beschreibt seinen Tokendienst so, dass er die PAN ersetzt und die sensible Nummer in einen digitalen Token verwandelt, damit Händler mit digitalen Token statt mit Karten PANs arbeiten, und bietet einen Massendienst, um bereits hinterlegte Karten zu tokenisieren.⁴ Visa betreibt einen gleichwertigen Dienst. Ein Netzwerktoken übersteht eher Ereignisse, die eine gespeicherte Karte sonst brechen würden, etwa eine Neuausgabe, und Abwickler berichten von besseren Autorisierungsraten damit. Stripe etwa führt Netzwerktoken unter den Funktionen auf, die die Autorisierung migrierter Karten verbessern können.³ Die Grenze, die du verstehen musst: Ein Netzwerktoken wird immer noch über die Integration eines Anbieters bereitgestellt und gehalten. Es ist ein besseres Zahlungsmittel zum Mitnehmen, kein Zauberdraht, der deinen Tresor von einem Anbieter zum anderen beamt. Es macht eine echte Migration glatter. Es ersetzt sie nicht.

Account Updater hält Karten aktuell, er bewegt sie nicht

Der zweite Dienst wird noch öfter mit Migration verwechselt, sei also vorsichtig damit. Der Account Updater von Visa und der Automatic Billing Updater von Mastercard halten die Karten aktuell, die du ohnehin schon hältst. Wenn die Karte einer Kundin neu ausgegeben wird, abläuft oder ersetzt wird, können die Netzwerke die neue Nummer und das neue Ablaufdatum an teilnehmende Händler zurückspielen, damit eine wiederkehrende Abbuchung nicht nur deshalb scheitert, weil sich das Plastik in der Geldbörse geändert hat. Visa beschreibt seinen Dienst so, dass Issuer, Acquirer und qualifizierte Händler aktualisierte Kontoinformationen austauschen, darunter neue Kontonummern, Ablaufdaten und Kontoschließungen, damit Issuer die Händlerbeziehung einer Karteninhaberin nach Kontoänderungen erhalten.⁵ Mastercard beschreibt seinen Dienst so, dass er aktualisierte Zahlungskontodaten einschließlich PAN und Ablaufdatum bereitstellt, um die Card on File Ablehnungen durch abgelaufene oder neu ausgegebene Karten zu senken.⁶

Lies diese Beschreibungen genau, und du siehst, was sie nicht sind. Sie aktualisieren die Kartendaten, die du ohnehin halten darfst. Sie geben deinen Tresor nicht an einen anderen Anbieter, und sie legen keine gespeicherte Karte an, wo du keine hattest. Ein Account Updater ist Wartung für einen Tresor, den du behältst. Er ist nach einem Umzug wirklich nützlich, damit deine frisch migrierten Karten belastbar bleiben. Er ist kein Weg, den Umzug selbst durchzuführen.

Karten erneut erheben, gut gemacht

Manchmal lässt sich der Tresor nicht bewegen. Die Quelle gibt ihn nicht frei, oder ein Teil davon steckt in Wallet Zugangsdaten, die nicht exportieren. Dann bleibt als einziger ehrlicher Weg, die Kunden erneut um ihre Karte zu bitten. Unachtsam gemacht ist das das Teuerste, was du bei einer Migration tun kannst. Gut gemacht ist es überstehbar, und der Unterschied liegt ganz in der Planung.

Der erwartete Verlust daraus, eine Gruppe von Kunden zur erneuten Eingabe einer Karte zu bewegen, lässt sich leicht beziffern, und er ist ein Erwartungswert, eine Wahrscheinlichkeit mal einem Betrag, den ich in der Grundlagen Referenz darlege:

L = N \times (1 - q) \times v \times T

Dabei ist $L$ der erwartete Umsatzverlust, $N$ die Zahl der Kunden, deren Karte du erneut erheben musst, $q$ der Anteil, der es erfolgreich tut, sodass $(1 - q)$ der Anteil ist, den du verlierst, $v$ der durchschnittliche Wert pro Kunde und Monat und $T$ die Zahl der Monate, die eine gehaltene Kundin sonst weiter gezahlt hätte. Die ganze Kunst besteht darin, $q$ , den Anteil, der den Schritt abschließt, so nah wie möglich an eins zu heben.

Was ihn hebt: ein einziger, ruhiger, einmaliger Ablauf, der die Kundin bittet, ihre Daten zu bestätigen, kein totes Abo, das still aufhört. Nutze ein gehostetes Feld oder das Zahlungsblatt deines neuen Abwicklers, damit die Karte direkt in den neuen Tresor wandert und dein Store die Nummer trotzdem nie anfasst. Lege die Bitte auf einen Moment, in dem die Kundin ohnehin da ist, etwa den nächsten Login oder die nächste Bestellung, statt auf eine kalte Mail. Sag klar, warum, halte es auf einem Bildschirm, und bündle es nie mit einer Preiserhöhung oder einem Redesign, damit die einzige Entscheidung davor lautet: ja, das ist weiterhin meine Karte. Und staffle es: zieh eine Gruppe um, beobachte die Abschlussrate, und zieh erst dann die nächste, damit ein Problem dich eine Gruppe kostet und nicht den ganzen Bestand.

Wenn die starke Kundenauthentifizierung wieder auftaucht

Es wartet noch eine Überraschung auf europäische Kunden, und sie wird besser jetzt benannt als bei der ersten Verlängerung entdeckt. Nach den europäischen Regeln zur starken Kundenauthentifizierung brauchen die meisten Online Kartenzahlungen, bei denen die Kundin beteiligt ist, dass sie ihre Identität mit zwei unabhängigen Faktoren bestätigt, die Art Prüfung, die du als Bankapp Aufforderung oder Einmalcode kennst. Die rechtliche Grundlage sind die technischen Regulierungsstandards aus der zweiten Zahlungsdiensterichtlinie.⁷ Die Europäische Bankenaufsichtsbehörde hat bestätigt, dass Kartenzahlungen als von der zahlenden Person ausgelöst gelten und unter diese Regeln fallen, und dass das Einrichten oder Ändern einer Zahlungsvereinbarung über einen Fernkanal selbst der Prüfung unterliegt.⁸

Die praktische Folge ist diese. Eine Karte, die einmal authentifiziert wurde, unter einer auf dem alten Anbieter eingerichteten Vereinbarung, trägt den Nachweis dieser Authentifizierung in Form einer Netzwerk Transaktions ID. Wenn eine richtige Tresorübertragung diese Kennung mitnimmt, kann der neue Anbieter sie vorlegen, und die Kundin wird meist nicht erneut geprüft. Braintree etwa nimmt die Felder der Netzwerk Transaktions ID in seinen Export mit, damit die Historie mit der Karte reist.⁹ Wenn du stattdessen die Karte erneut erhebst, richtest du eine frische Vereinbarung ein, und dieser erste Schritt über einen Fernkanal kann eine neue Authentifizierung auslösen.⁸ Das ist normal und in Ordnung, solange du es erwartest, den Prüfschritt in deinen Ablauf des erneuten Erhebens einbaust und ihn nicht zu einer Stunde laufen lässt, zu der die Kundin schläft. Der Fehlerfall ist eine stille Verlängerung, die die Bank prüfen will, wenn niemand am Bildschirm ist.

Die Entscheidung, die du vor dem Festlegen treffen musst

Alles oben fällt in drei Fragen zusammen, und der ganze Sinn dieses Artikels ist, dass du sie beantwortest, bevor du dich auf einen Umzug festlegst, nicht mitten in einem:

Erstens: Wird mein aktueller Anbieter den Tresor freigeben, über eine dokumentierte Übertragung von Gateway zu Gateway, und wie lange und wie teuer? Zweitens: Wird der Zielanbieter diese Übertragung empfangen, und verlangt er eine Level 1 Bescheinigung und einen Schlüssel, den ich liefern kann? Drittens: Wenn ein Teil oder alle Karten nicht umziehen können, was kostet mich das erneute Erheben an Abwanderung, mit der Formel oben, und kann ich mir das leisten? Ein Umzug, bei dem alle drei Antworten bekannt sind, ist ein Projekt. Ein Umzug, bei dem sie unterwegs entdeckt werden, ist die Falle aus dem Lehrstück.

Ein durchgerechnetes Beispiel

Mach ich es konkret an einem erfundenen Unternehmen. Rowan Supplements ist eine Firma in Linz, die ein monatliches Nahrungsergänzungs Abo auf rowansupplements.example verkauft. Priya führt es. Es hat 25.000 gespeicherte Karten bei einem gängigen Abwickler und zieht auf einen individuellen Solidus Store mit einem neuen Level 1 Abwickler hinter der Kassa um. Jede Zahl hier ist erfunden, damit ich die Schritte zeigen kann.

Priyas erster Zug, Monate vor jedem Starttermin, ist der langweilige, der alles entscheidet: Sie fragt ihren aktuellen Abwickler schriftlich nach einem Kartendatenexport an ein benanntes Level 1 Ziel, und sie bittet ihren neuen Abwickler, zu bestätigen, dass er empfängt, und seine Bescheinigung und seinen Schlüssel zu liefern.² Der aktuelle Abwickler bestätigt, dass er den Tresor freigibt, und nennt eine Gebühr und eine Frist von mehreren Wochen.³ Gut: Das ist ein umkehrbarer Umzug, keine Falle.

Dann fährt sie die zwei Spuren parallel. Neue Kunden und neue Bestellungen gehen sofort auf dem neuen Store und dem neuen Abwickler live und bauen dort frische getresorte Karten auf. Zugleich wird der Export der bestehenden 25.000 angefordert, von Anbieter zu Anbieter verschlüsselt und in den neuen Tresor importiert, mit mitgeführten Netzwerk Transaktions IDs, damit ihre Abonnenten bei der ersten Verlängerung nicht erneut authentifizieren müssen.⁹ Wenn die Zuordnungsdatei zurückkommt, stellt ihr Store alle 25.000 gespeicherten Kartensätze auf die neuen Token um, bevor eine Verlängerung darauf läuft.³ Danach schaltet sie einen Account Updater ein, damit eine neu ausgegebene Karte nicht drei Monate später still scheitert.⁶

Nicht alles kommt sauber. Der Export markiert 1.800 Karten, die über ein Wallet Zugangsmittel erfasst wurden, das sich nicht zwischen Abwicklern übertragen lässt.² Genau für diese 1.800, und nur diese, fährt Priya einen gestaffelten Ablauf zum erneuten Erheben: ein einmaliger Schritt zum Bestätigen der Karte beim nächsten Login, gehostet vom neuen Abwickler, klar kommuniziert, in Gruppen von einigen Hundert bewegt, mit der Abschlussrate dazwischen beobachtet. Mit der Formel, bei $N = 1.800$ , einem Abschlussanteil $q = 0,9$ , $v = 24$ pro Monat und $T = 10$ Monaten, ist der erwartete Verlust $1.800 \times 0,1 \times 24 \times 10 = 43.200$ Euro, und der ganze Zweck des gestaffelten, gut getimten Ablaufs ist, $q$ höher und diese Zahl tiefer zu drücken. Sie beziffert es, bevor sie beginnt, damit es ein eingeplanter Posten ist und keine böse Überraschung. Die 23.200 Karten, die sauber umgezogen sind, kosteten nichts, und niemand hat es gemerkt.

Was ich frage, bevor jemand unterschreibt

Das meiste am Ausgang entscheidet sich im Vertrag und in der Dokumentation, lange bevor eine Zeile Migrationscode geschrieben ist. Ich frage also jeden Anbieter, abgebend und empfangend, dieselbe kurze Liste, und ich will die Antworten schriftlich:

Wie exportiere ich gespeicherte Karten zu einem anderen Anbieter mit PCI DSS Level 1, wie lange dauert es, und was kostet es? Nimmst du Netzwerk Transaktions IDs mit, damit Kunden nicht erneut authentifizieren müssen? Empfängst du eingehend eine Tresorübertragung von einem anderen Level 1 Anbieter? Welche Karten, falls welche, lassen sich nicht übertragen, weil sie als Wallet Zugangsdaten gehalten werden? Und wie lange behalte ich nach dem Ende der Verarbeitung Zugriff für Erstattungen und Anfechtungen zu alten Zahlungen?

Ein Anbieter, der das klar beantwortet, ist einer, bei dem dir die Beziehung gehört. Das gehört in dieselbe Checkliste wie die Datenschutzfragen beim Prüfen von Dienstleistern, bevor sie deine Compliance untergraben, und es liegt unter der größeren Wahrheit, dass deine Kunden und Zahlungsbeziehungen dir zum Mitnehmen gehören sollten, was das Thema von wem deine Geschäftsdaten eigentlich gehören ist. Wenn dein Shop so zahlen lässt, wie es Kundschaft im DACH Raum erwartet, ist die Zielseite davon in DACH Zahlungsarten in Solidus abgedeckt.

Gespeicherte Karten lassen sich sehr oft bewegen, sauber und konform, über eine richtige Migration von Gateway zu Gateway. Aber nur mit der Mitwirkung der Quelle, und die ehrliche, unglamouröse Arbeit besteht darin, diese Mitwirkung festzustellen, bevor du dich festlegst, nicht danach. Das ist die ganze Aufgabe, und sie in der richtigen Reihenfolge zu machen ist der Unterschied zwischen einem leisen und einem schmerzhaften Umzug.