Wie migriert man bestehende dynamische QR-Codes zu einem anderen Anbieter?

Entscheidend ist die Adresse im gedruckten Code

Ein dynamischer QR-Code enthält keine „unsichtbar änderbare“ Zielseite, sondern eine feste Webadresse, die weiterleitet. Ob ein Anbieterwechsel ohne Neudruck möglich ist, hängt deshalb zuerst von der Kontrolle über Domain und Pfad ab. GS1 empfiehlt für langfristige QR-Anwendungen eine eigene Domain und nennt eine getrennte Subdomain wie id.example.de als praktikable Struktur. Bleibt diese Adresse unter eigener Kontrolle, kann der technische Dienst dahinter ausgetauscht werden.

Migration in neun kontrollierten Schritten

1. Bestand erfassen: Für jeden Code werden gedruckte Adresse, aktuelles Ziel, Einsatzort, Sprache, Parameter und verantwortliche Person inventarisiert. Aus 1 QR-Adresse können mehrere Zielvarianten entstehen; diese Zuordnungen müssen vollständig exportiert werden.
2. Domainrechte klären: Registrar, Domaininhaber, DNS-Zugang, TLS-Zertifikat und Nutzungsrechte an der Kurzadresse werden dokumentiert. Eine bloße Exportdatei hilft nicht, wenn die gedruckte Domain dem bisherigen Anbieter gehört.
3. Zuordnungen exportieren: Pfade, Ziele, Status, zeitliche Regeln und benötigte Parameter werden in einem offenen Format übernommen. Der neue Dienst muss unbekannte Pfade eindeutig mit 404 Not Found behandeln und vorhandene Parameter korrekt weiterreichen.
4. Neue Umgebung parallel aufbauen: Alle alten Pfade werden unter derselben kontrollierten Domain nachgebildet. Die neue Plattform erhält ein gültiges HTTPS-Zertifikat und wird zunächst außerhalb des öffentlichen DNS getestet.
5. DNS rechtzeitig vorbereiten: Wird der Zielserver per DNS gewechselt, sollte eine niedrigere TTL mindestens eine volle bisherige TTL-Periode vor der Umschaltung gesetzt werden. Genau darauf weist RFC 9803 hin. Erst am Umschalttag die TTL zu verkürzen, beschleunigt bereits zwischengespeicherte Antworten nicht.
6. Weiterleitungen bewusst wählen: RFC 9110 unterscheidet unter anderem 301 und 308 für dauerhafte sowie 302 und 307 für vorübergehende Weiterleitungen. Dauerhafte Antworten können zwischengespeichert werden. Bei weiterhin änderbaren QR-Zielen muss deshalb geprüft werden, ob eine temporäre Weiterleitung oder ein Resolver-Eintrag fachlich besser passt.
7. Abnahme durchführen: Jeder reale Code wird gescannt; geprüft werden endgültiges Ziel, Sprache, Parameter, Weiterleitungsschleifen, Zertifikat und Fehlerseite. Besonders häufig genutzte Codes sollten vor der allgemeinen Umschaltung priorisiert werden.
8. Überlappenden Betrieb halten: Das alte System wird nicht unmittelbar abgeschaltet. Die Mindestüberlappung richtet sich nach DNS-TTL, Cache-Verhalten, Vertrag und Rückfallplan. Erst wenn Protokolle und Stichproben keine relevanten Fehler zeigen, wird der Altvertrag beendet.
9. Eigentum dauerhaft sichern: Muss eine generische Top-Level-Domain zu einem anderen Registrar übertragen werden, ist dafür ein Auth-Code erforderlich. ICANN verlangt, dass der bisherige Registrar ihn grundsätzlich innerhalb von 5 Kalendertagen bereitstellt, falls er nicht selbst erzeugt werden kann. Ein Registrartransfer ist jedoch nicht dasselbe wie die technische Resolvermigration.

Steht im Druck ausschließlich eine fremde Anbieter-Domain, kann das Unternehmen DNS und Weiterleitung nicht selbst ändern. Dann muss der Anbieter die bisherigen Pfade dauerhaft weiterleiten oder die Domain beziehungsweise einen kontrollierbaren Teil davon vertraglich übertragen. Ist das nicht möglich, muss der physische Code ersetzt oder überklebt werden. Für neue Auflagen verhindert eine eigene Domain diese Abhängigkeit, garantiert aber nicht automatisch einen fehlerfreien Betrieb; Export, Monitoring und Rückfallplan bleiben notwendig.