Migration vom Hardware-Controller zur Software

Wann Migration die richtige Entscheidung ist

Migration ist nicht kostenlos. Bevor Sie sich festlegen, bestätigen Sie, dass mindestens eines davon zutrifft — wenn keines zutrifft, ist es meist günstiger, den bestehenden Stack über sein natürliches Leben weiterzubetreiben:

• Der Controller hat das EOL erreicht oder nähert sich ihm. Sobald der Hersteller die Firmware-Patches einstellt, ist die Wand ein Sicherheits- und Zuverlässigkeitsrisiko. Christie Phoenix und RGB Spectrum Galileo erreichten Ende 2025 beide EOL-Ankündigungen — Anlagen auf diesen Plattformen laufen gegen die Uhr.
• Die Quellenanzahl ist dem Capture-Karten-Budget entwachsen. Jede neue Baseband-Quelle auf einem Hardware-Controller bedeutet eine weitere Capture-Karte, manchmal einen Chassis-Tausch. Wenn sich die Quellen-Roadmap verdoppelt, ist die lineare Hardware-Kostenkurve der Auslöser.
• Das Angebot für den Fünf-Jahres-Refresh hält der Prüfung nicht stand. Siehe die TCO-Aufschlüsselung — die Refresh-Position ist dort, wo die Lücke zwischen Hardware und Software am größten ist.
• Der Quellenmix ist auf IP umgezogen. Wenn die Feeds nun überwiegend NDI, RTSP und browsergerenderte Dashboards statt Baseband-HDMI/SDI sind, arbeitet die Capture-Karten-Architektur gegen die Bereitstellung.

Das Audit vor der Migration

Migrationsfehler lassen sich fast immer auf ein ausgelassenes Audit zurückführen. Dokumentieren Sie vor jeder Beschaffung vier Dinge:

• Quelleninventar. Jeder Feed auf der Wand heute: Typ (HDMI-Capture, SDI, NDI, RTSP, KVM, Browser), Auflösung, Bildrate und wie er den Controller physisch erreicht. Diese Liste ist die Spezifikation, die der neue Stack erfüllen muss. Die Feeds, die heute nur Baseband sind, sind die, die eine Transportentscheidung brauchen.
• Layout-Inventar. Jede benannte Szene oder Voreinstellung, die Bediener nutzen. Diese müssen auf dem neuen Stack neu aufgebaut werden — Anzahl und Komplexität zu kennen, bemisst den Inbetriebnahme-Aufwand.
• Integrationsinventar. Was heute mit dem Wand-Controller spricht — ein AMX-/Crestron-Steuerungssystem, ein Alarmauslöser, ein Planungssystem. Jeder Integrationspunkt ist eine Migrationsaufgabe.
• Bediener-Workflow-Karte. Wie Bediener die Wand tatsächlich ansteuern — dedizierte Konsole, Touchpanel, Tastaturkürzel. Der neue Stack ändert das, und die Änderung muss geplant werden, nicht am Go-Live-Tag entdeckt.

Zwei Migrationspfade

Pfad A — Parallelbetrieb (empfohlen)

Stellen Sie den softwarebasierten Stack auf neuer Commodity-Hardware neben den bestehenden Hardware-Controller. Beide steuern Inhalte; die Displays lassen sich an der Matrix zwischen ihnen umschalten oder, bei LED-Wänden, durch Neuzuweisung des Controller-Ausgangs. Bediener lernen den neuen Stack nach einem unkritischen Plan, benannte Szenen werden neu aufgebaut und verifiziert, Integrationen getestet — alles, während der alte Controller noch das Produktivsystem ist. Wenn der neue Stack ein Validierungsfenster (typischerweise zwei bis vier Wochen) sauber gelaufen ist, schalten die Displays um, und der alte Controller wird bis zur Außerbetriebnahme zum Hot-Spare.

Der Preis von Pfad A ist der kurzzeitige Betrieb zweier Stacks. Der Vorteil ist, dass die Wand nie gefährdet ist — zu jedem Zeitpunkt vor der Umschaltung ist der Rückfall das bekannt-gute alte System. Für ein 24/7-NOC oder -SOC ist dies der einzige verantwortungsvolle Pfad.

Pfad B — Big-Bang-Umschaltung

Nehmen Sie den Hardware-Controller außer Betrieb und fahren Sie den Software-Stack an seiner Stelle in einem einzigen geplanten Ausfallfenster hoch. Nur gangbar, wenn: die Wand nicht 24/7-kritisch ist (ein Boardroom, ein Schulungsraum, eine Monitoring-Wand mit geringem Einsatz), das Ausfallfenster tatsächlich verfügbar ist und der neue Stack zuvor auf einem Prüfstand vollständig validiert wurde. Für alles Geschäftskritische tauscht Pfad B ein inakzeptables Maß an Risiko gegen eine marginale Einsparung beim Parallelbetrieb. Die meisten professionellen Integratoren weigern sich, eine NOC-Wand per Big-Bang umzustellen.

Der phasenweise Plan (Pfad A)

1. Phase 0 — Prüfstand-Validierung. Der neue Stack läuft auf seinem Commodity-Server in einem Labor- oder Staging-Rack. Jeder Quellentyp aus dem Audit wird auf Aufnahme getestet. Jeder Integrationspunkt wird getestet. Diese Phase endet, wenn der Stack eine repräsentative Stichprobe des realen Quellenmix problemlos aufnimmt.
2. Phase 1 — Parallelinstallation. Der validierte Server wird neben den bestehenden Controller gerackt, an dasselbe Quellennetz angeschlossen und so verkabelt, dass sein Ausgang die Displays über die Matrix oder einen Switch erreichen kann. Die Wand wird weiter vom alten Controller angesteuert.
3. Phase 2 — Szenen-Neuaufbau. Jedes benannte Layout aus dem Audit wird auf dem neuen Stack neu aufgebaut und gegen das alte verifiziert. Softwarebasierte Stacks machen das schneller als den ursprünglichen Aufbau — Szenen sind Konfiguration, keine Verkabelung.
4. Phase 3 — Bediener-Schulung. Bediener betreiben den neuen Stack nach einem nicht-produktiven Plan — ein Ersatzdisplay, ein Übungsfenster außerhalb der Schicht. Browserbasierte Steuerung ist ein anderes Paradigma als eine dedizierte Konsole; ein halber Tag pro Bediener ist die typische Lernkurve.
5. Phase 4 — Validierungsfenster. Der neue Stack läuft zwei bis vier Wochen als Schatten der Produktivwand. Jede Instabilität taucht hier auf, während der alte Controller noch die Produktion trägt.
6. Phase 5 — Umschaltung. Die Displays wechseln auf den neuen Stack. Der alte Controller bleibt für einen definierten Zeitraum (üblich 30-90 Tage) gerackt und betriebsbereit als Hot-Spare.
7. Phase 6 — Außerbetriebnahme. Sobald der neue Stack die Produktion durch den Hot-Spare-Zeitraum ohne Vorfall getragen hat, wird der alte Controller außer Betrieb genommen. Capture-Karten und Chassis haben oft einen Restwert beim Wiederverkauf oder als Ersatzteil.

Die planungswerten Risiken

• Transportlücke bei Baseband-Quellen. Feeds, die als HDMI/SDI in eine Capture-Karte gingen, brauchen auf dem neuen Stack eine Transportentscheidung — einen HDMI-zu-NDI- oder HDMI-zu-IPMX-Encoder oder eine Capture-Karte im Software-Server. Identifizieren Sie diese im Audit; sie sind die häufigste Migrationsüberraschung.
• Nicht passende Latenzerwartung. Ein Hardware-Controller liefert Sub-Frame-Baseband-Latenz. Ein Software-Stack auf IP-Quellen liefert Einzelframe. Für die Anzeigeprüfung ist das unsichtbar; für einen Bediener-KVM-Workflow kann es bemerkbar sein. Bestätigen Sie das Latenzbudget im Audit — siehe IPMX vs. ST 2110 vs. SDVoE für die Transport-Stufen-Optionen.
• Steuerungssystem-Integration. Eine bestehende AMX-/Crestron-Integration, die gegen die API des alten Controllers geschrieben wurde, muss auf die API des neuen Stacks umgelenkt werden. Das ist Integrator-Arbeit; budgetieren Sie sie ausdrücklich.
• Bedienervertrauen. In der ersten Woche auf einer neuen Wand sind Bediener langsamer und vorsichtiger. Das ist normal und vorübergehend, aber eine Umschaltung direkt vor einer bekannten Hochlastphase (ein großes Ereignis, eine saisonale Spitze) ist ein Planungsfehler.

Was sich für Bediener am ersten Tag ändert

Die ehrliche Liste dessen, was Bediener tatsächlich bemerken:

• Die Wand-Steuerung wandert von einer dedizierten Konsole zu einem Browser-Tab auf ihrem bestehenden Arbeitsplatz — nach der anfänglichen Umstellung meist gut aufgenommen, weil sie einen physischen Gang durch den Raum beseitigt.
• Eine Quelle hinzuzufügen wird zu ein paar Klicks statt zu einer Anfrage an den Integrator. Das ist die Änderung, die Bediener am meisten schätzen.
• Benannte Szenen funktionieren konzeptuell gleich, aber die Oberfläche ist anders. Der audit-gestützte Szenen-Neuaufbau bedeutet, dass am ersten Tag keine Layouts fehlen.
• Mehrfach-Bediener-Steuerung — mehrere Bediener ändern die Wand von ihren eigenen Tastaturen — ist meist neu und braucht ein oder zwei Schichten, um zur Gewohnheit zu werden.

Wo Craft Wall passt

Craft Wall ist ein häufiges Pfad-A-Migrationsziel — der softwarebasierte Stack läuft auf einem Commodity-Linux-Server, der für den Parallelbetrieb neben den ausscheidenden Controller gerackt wird, die NDI-, RTSP-, IP-KVM- und Browser-Quellen aus dem Audit aufnimmt und benannte Szenen als Konfiguration neu aufbaut. Das Dauerlizenz-Modell (2.500 EUR pro Server) bedeutet, dass die Migration einmalige Kosten verursacht statt des Beginns einer Subscription. Für das vollständige wirtschaftliche Bild siehe die TCO-Aufschlüsselung; für den herstellerspezifischen Migrationskontext decken die Vergleiche Craft Wall vs. Datapath und Craft Wall vs. Matrox die zwei häufigsten Migrations-Quell-Controller ab.

Craft Wall ist nicht für jede Migration das richtige Ziel. Hat die Wand eine harte Sub-Frame-Latenz-Anforderung am Bediener-KVM, oder braucht die Beschaffung einen Tier-1-Hersteller mit einem 15-20-jährigen Support-Horizont, ist das Migrationsziel eher ein anderer Hardware-Hersteller oder ein hybrider Stack — siehe den Vergleich der acht Plattformen dazu, wo jede Option passt.

Fazit

Eine Videowand-Migration ist ein Projekt, kein Produkttausch. Die Teams, die es sauber machen, behandeln das Audit als nicht verhandelbar, fahren bei jeder kritischen Wand Parallelbetrieb statt Big-Bang und legen die Umschaltung abseits bekannter Hochlastphasen. So gemacht, ist die Migration für alle unsichtbar außer für die Bediener — die meist bis zum Ende der ersten Woche bemerken, dass sich mit dem neuen Stack schneller arbeiten lässt.

Weiterlesen: die TCO-Aufschlüsselung für die Wirtschaftlichkeit, die die Migration rechtfertigt, die NOC-Referenzarchitektur für das Ziel-Design, und der interaktive TCO-Rechner, um Ihre eigenen Zahlen zu rechnen.