Von selbstgebauten Lizenzschlüsseln zu Keyright migrieren, ohne Kunden etwas kaputtzumachen

Jedes selbstgebaute Lizenzsystem beginnt gleich: ein Wochenende, eine GUID, eine Prüfsumme, vielleicht ein bisschen XOR-„Verschlüsselung” und eine Prüfung, die true zurückgibt. Es geht in Produktion, es funktioniert, und dann wird es still und leise tragend. Jahre später wollen Sie echte Sitze, Online-Aktivierung, Widerruf und ein Kundenportal — und stoßen auf die Frage, die die meisten Teams stocken lässt: Wie bringe ich Tausende Kunden, die bereits Schlüssel im Feld ausführen, auf ein richtiges System, ohne Stichtag, ohne Massen-Reaktivierungs-E-Mail und ohne eine Woche Support-Tickets?

Sie können, und kein Kunde muss es bemerken. Der Trick ist, die Migration als Übergangsfenster zu behandeln statt als Schalter, und den Client beide Formate lesen zu lassen, während Sie im Verborgenen echte Lizenzen neu ausstellen. Dieser Artikel ist der konkrete Plan.

Kernaussage: Migrieren Sie hinter einer einzigen Schnittstelle. Veröffentlichen Sie einen Client, der zuerst die neue signierte Lizenz validiert und auf Ihren Alt-Schlüssel zurückfällt, stellen Sie für jeden bestehenden Kunden aus Ihren eigenen Datensätzen eine signierte Lizenz aus, liefern Sie sie wie jedes Update aus, und lassen Sie jede App sich beim nächsten Start selbst stillschweigend umstellen. Behalten Sie den Alt-Rückfall einen Erneuerungszyklus, dann löschen Sie ihn. Keine Reaktivierung, kein Stichtag.

Schritt 1 — Inventarisieren Sie, was Ihre aktuellen Schlüssel wirklich kodieren

Bevor Sie Alt auf Neu mappen können, müssen Sie genau wissen, was Ihr selbstgebauter Schlüssel bedeutet. Die meisten hausgemachten Schemata schmuggeln überraschend viel Zustand in eine Zeichenkette oder einen danebenliegenden Datensatz. Schreiben Sie es explizit auf:

• Identität — welcher Kunde, welche E-Mail oder Bestell-ID.
• Umfang — Produkt, Edition/Stufe und jeder Funktionsschalter, den Sie von Hand umgelegt haben.
• Lebensdauer — unbefristet oder ein Ablaufdatum (und wo dieses Datum wirklich lebt — im Schlüssel, in einer Konfigurationsdatei, in Ihrer Datenbank?).
• Menge — Sitzzahlen, falls Sie sie je durchgesetzt haben (die meisten hausgemachten Systeme tun das nicht, was oft der Grund für Ihre Migration ist).

Dieses Inventar ist die Migrationsspezifikation. Jedes Feld wird zu einem Claim in der signierten Lizenz, die Sie ausstellen. Ist eine Tatsache aus Ihren Datensätzen nicht wiederherstellbar, entscheiden Sie ihren Standardwert jetzt — zum Beispiel „unbekannte Alt-Kunden erhalten einen Einjahreszeitraum ab Migration” — statt die Lücke mitten im Rollout zu entdecken.

Schritt 2 — Verstehen Sie, warum Sie neu ausstellen müssen (und wer zahlt)

Ein hausgemachter Schlüssel wird von Logik in Ihrer App geprüft: Die App entscheidet, dass ein Schlüssel gültig ist, indem sie seine Form ansieht. Das ist die strukturelle Schwäche, die eine signierte Lizenz behebt — die Autorität wandert zu einem privaten Schlüssel, der nie ausgeliefert wird (wir erklären das Warum in der Anatomie eines signierten Lizenzschlüssels). Die Folge für die Migration ist einfach: Ihre alten Schlüssel können nicht unverändert importiert werden, weil nichts sie signiert hat. Sie müssen für jeden Kunden eine echte, signierte Lizenz prägen.

Die wichtige Umdeutung: Sie stellen sie aus, nicht Ihre Kunden. Niemand fügt etwas ein. Sie übersetzen Ihr Inventar massenhaft in signierte Lizenzen und liefern sie aus. Der einmalige Aufwand ist, das Mapping einmal zu schreiben; die Kosten pro Kunde sind null.

Schritt 3 — Keyright aufstellen und massenhaft aus Ihren Datensätzen ausstellen

Richten Sie Ihren Ausstellungsprozess auf Ihre bestehende Kundentabelle. Stellen Sie für jeden aktiven Datensatz eine signierte Lizenz aus, die die Claims aus Schritt 1 trägt. Aus einem Skript oder einem nächtlichen Job ist das ein Aufruf pro Kunde gegen die Admin-API:

POST /v1/licenses
Authorization: Bearer <admin-token>
Content-Type: application/json

{
  "product":   "acme-suite",
  "tier":      "pro",
  "licensee":  "bestellungen+8831@kunde.example",
  "expiresAt": "2027-01-31",
  "seats":     3,
  "entitlements": { "export": "true", "max-projects": "25" },
  "externalId": "alt-schluessel:4F2A-9C11-...",
  "idempotencyKey": "alt-schluessel:4F2A-9C11-..."
}

Zwei Felder machen ein Massen-Nachfüllen sicher wiederholbar. externalId erfasst, welchen Alt-Schlüssel diese Lizenz ersetzt, also haben Sie eine Prüfspur und können später abgleichen. idempotencyKey bedeutet, dass ein zweimaliges Ausführen des Migrationsjobs keine doppelten Lizenzen prägt — der zweite Versuch gibt die bereits ausgestellte Lizenz zurück. Sie werden ihn mehr als einmal ausführen (eine Charge scheitert auf halbem Weg, einem Datensatz fehlte ein Feld), also backen Sie Idempotenz von der ersten Zeile an ein. Dieselbe Disziplin zählt, wenn Sie die Lizenzauslieferung mit Webhooks automatisieren für Ihre Neuverkäufe.

Schritt 4 — Veröffentlichen Sie einen Client, der beide Formate liest

Das ist das Herz einer bruchfreien Migration. Stellen Sie beide Prüfungen hinter eine einzige Schnittstelle, versuchen Sie zuerst die signierte Lizenz und fallen Sie nur dann auf den Alt-Schlüssel zurück, wenn keine neue Lizenz vorhanden ist:

public sealed class CompositeLicenseSource
{
    private readonly KeyrightClient _keyright;
    private readonly LegacyKeyReader _legacy;

    public LicenseState Resolve()
    {
        // Bevorzugt die echte Lizenz. Validate() ist offline und wirft nie:
        // eine fehlende/abgelaufene/widerrufene Lizenz schlägt geschlossen zu Free fehl.
        LicenseInfo info = _keyright.Validate();
        if (info.IsValid)
            return LicenseState.FromKeyright(info);

        // Noch keine signierte Lizenz — ehre den Alt-Schlüssel während des Übergangs.
        if (_legacy.TryRead(out var legacyKey) && _legacy.IsAccepted(legacyKey))
            return LicenseState.FromLegacy(legacyKey);

        return LicenseState.Unlicensed; // schlägt geschlossen fehl, wie immer
    }
}

Die Reihenfolge zählt: Indem Keyright zuerst geprüft wird, hört ein Kunde, der seine signierte Lizenz erhalten hat, sofort auf, vom Alt-Pfad abzuhängen, auch wenn der alte Schlüssel noch auf der Platte liegt. Der Rückfall trägt die Nachzügler. Jede Aufrufstelle fragt CompositeLicenseSource, statt einen der beiden Leser direkt anzufassen, also ist es, wenn Sie den Rückfall später löschen, eine Änderung in einer einzigen Datei. Das Ganze bleibt offline-zuerst und schlägt geschlossen fehl — genau die Eigenschaften, die Ihre hausgemachte Prüfung wahrscheinlich nie hatte.

Schritt 5 — Ausliefern, umstellen und stilllegen

Jetzt läuft die Migration von selbst. Liefern Sie jede signierte Lizenz so aus, wie Sie jedes Update ausliefern — gebündelt mit der nächsten Version, beim ersten Start abgerufen oder per E-Mail — und der Doppellese-Client nimmt sie auf und gibt den Alt-Pfad still auf. Sequenzieren Sie, um Risiko zu nehmen:

1. Stellen Sie zuerst die Neuverkäufe um. Verdrahten Sie den Checkout so, dass er signierte Lizenzen ausstellt, damit jeder neue Kunde auf dem neuen System geboren wird und das Alt-Format nie berührt.
2. Füllen Sie bestehende Kunden in Chargen nach. Führen Sie den idempotenten Job aus Schritt 3 über Ihre Tabelle aus, die ältesten Aktiven zuerst, achten Sie auf Mapping-Lücken.
3. Behalten Sie den Rückfall einen vollen Erneuerungszyklus. Langsam aktualisierende und abgeschottete (air-gapped) Kunden haben ihre neue Lizenz noch nicht gesehen; der Alt-Pfad hält sie am Laufen, bis sie es tun. Überstürzen Sie das nicht.
4. Löschen Sie den Rückfall. Sobald Erneuerungen oder anonyme Update-Telemetrie zeigen, dass das Alt-Format praktisch ungenutzt ist, entfernen Sie LegacyKeyReader in einer Routineversion. Die Migration ist vorbei, und der einzige verbleibende Code ist der echte.

Zu keinem Zeitpunkt gab es einen Stichtag, eine erzwungene Reaktivierung oder eine „Bitte Schlüssel erneut eingeben”-E-Mail — die drei Dinge, die eine Migration in ein Support-Feuer verwandeln.

Die ehrlichen Vorbehalte

Zwei Dinge sollten Sie klar sehen. Erstens ist der Alt-Rückfall per Definition so schwach, wie Ihr altes Schema war — behandeln Sie das Übergangsfenster also als Frist, nicht als Dauerzustand, und behalten Sie es nur so lange, wie der lange Schwanz es wirklich braucht. Zweitens werden alle Kundentatsachen, die Sie nicht aus Ihren Datensätzen wiederherstellen können, zu Vermutungen; entscheiden Sie diese Standardwerte im Voraus (Schritt 1), damit die Lücken bewusste Politik sind, keine Überraschung. Keines ist ein Grund zu zögern — beide sind Gründe, das Fenster abzustecken und das Mapping sorgfältig zu schreiben.

Wo Keyright hineinpasst

Keyright ist genau für diesen Schritt gebaut: Es stellt die signierten Offline-Lizenzdateien und die kurzlebigen Online-Aktivierungs-Leases aus, die Ihr hausgemachtes Schema nie hatte, setzt Sitze und Node-Locking serverseitig durch, trägt Berechtigungen (Entitlements) und Stufen, damit ein einziges Binary je nach Plan freischaltet, und gibt Ihnen ein gehostetes Kundenportal plus SDKs für .NET, Node, Python und Java, die alle geschlossen fehlschlagen – von Haus aus. Die Admin-API und die Felder externalId/Idempotenz sind genau dafür da, dass ein Massen-Nachfüllen aus Ihren alten Datensätzen sicher wiederholbar ist. Betreiben Sie es auf unserer verwalteten Cloud oder selbst gehostet in Ihrem eigenen Netz — dasselbe signierte Format in beiden Fällen.

Starten Sie mit dem kostenlosen Plan und modellieren Sie Ihre Migration von Ende zu Ende, bevor Sie einen Cent zahlen — sehen Sie die Pläne oder lesen Sie den Einstiegsleitfaden. Wenn Sie noch abwägen, ob Sie überhaupt wechseln, schlüsselt unsere Bauen-vs-Kaufen-Analyse auf, was Sie an dem Tag, an dem Sie umstellen, nicht mehr warten müssen.