Die meisten Leitstände migrieren ihre Videowand nicht, weil die Software schlecht ist. Sie migrieren, weil ein Hardware-Controller das End-of-Life erreicht hat, der Quellenmix den Capture-Karten entwachsen ist oder das Angebot für den Fünf-Jahres-Refresh eintraf und die Zahl schwer zu rechtfertigen war. Dieser Leitfaden ist für das Team, das den Umzug bereits beschlossen hat und nun einen Plan braucht, der die Wand während einer Schicht nicht dunkel werden lässt. Das Audit, die zwei gangbaren Migrationspfade, die phasenweise Abfolge, die planungswerten Risiken und was sich für Bediener tatsächlich ändert.
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)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 Canvas) 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.
Häufig gestellte Fragen
Wann ist der richtige Zeitpunkt, von einem Hardware-Videowand-Controller zu migrieren?
Migration ist sinnvoll, wenn mindestens eines zutrifft: (1) der bestehende Controller hat das EOL erreicht oder nähert sich ihm — Christie Phoenix und RGB Spectrum Galileo erreichten Ende 2025 beide EOL-Ankündigungen; (2) die Quellenanzahl ist dem Capture-Karten-Budget entwachsen — jede neue Baseband-Quelle braucht eine weitere Karte; (3) das Angebot für den 5-Jahres-Refresh hält der Prüfung nicht stand; (4) der Quellenmix ist auf IP umgezogen (NDI, RTSP, Browser-Dashboards) — die Capture-Karten-Architektur arbeitet gegen die Bereitstellung.
Was sind die zwei gangbaren Migrationspfade?
Pfad 1 — Parallelmigration: beide Stacks 4-8 Wochen gleichzeitig betreiben, Bediener lernen die neue UI, während der alte Stack als Rückfall bleibt, schrittweise Umschaltung pro Schicht. Geringeres Risiko, höhere Kosten (parallele BOM). Pfad 2 — Umschalt-Migration: Wechsel in einer Schicht mit dokumentiertem Rollback-Plan, der alte Stack bleibt kalt archiviert. Geringere Kosten, höheres Risiko, falls der Rollback ausgelöst wird. Pfad 1 ist die Vorgabe für 24/7-kritische Infrastruktur; Pfad 2 passt zu nicht geschäftskritischen AV-Bereitstellungen.
Wie lange dauert eine typische Migration von Hardware zu Software?
End-to-end für ein 16-Display-NOC: 6-10 Wochen. Aufschlüsselung: 1-2 Wochen Audit vor der Migration (Quelleninventar, Integrations-Mapping, Erfassung der Bediener-Workflows), 2-3 Wochen Parallelbereitstellung und Bediener-Schulung, 1-2 Wochen Umschaltung und Schattenbetrieb, 2-3 Wochen Stabilisierung nach der Umschaltung. Für größere Wände (32+ Displays) rechnen Sie 2-4 Wochen pro zusätzlichem Canvas hinzu. Beim Audit unterschätzen die meisten Projekte den Umfang.
Was ist das größte Risiko bei der Migration einer 24/7-NOC-Wand?
Bediener-Alarmmüdigkeit in der Parallelphase. Wenn beide Stacks dieselbe Quelle anzeigen, der neue Stack aber Anomalien fängt, die der alte übersah (oder umgekehrt), sehen Bediener doppelte Alarme und beginnen, sie abzuweisen — auch die echten. Gegenmaßnahme: Alarm-Deduplizierung über einen einzigen SIEM-Kanal während der Parallelphase, wobei beide Stacks in ein Bediener-Postfach einspeisen. Zweitgrößtes Risiko: Drift der Integrations-Zugangsdaten — die Service-Accounts auf dem neuen Stack müssen exakt das replizieren, was der alte Stack hatte, sonst verschwinden Quellen nach der Umschaltung.
Was ändert sich für Bediener am ersten Tag des neuen Stacks?
Übertragung des UI-Muskelgedächtnisses — die größte Reibung am ersten Tag. Bediener, die an physischen Panels von Hardware-Controllern geschult sind, nutzen plötzlich eine Maus-/Touch-UI; Bediener, die an einem Windows-Controller geschult sind, nutzen plötzlich einen Browser. Gegenmaßnahme: 2-tägige formale Schulung vor der Umschaltung plus die ersten 1-2 Wochen Schattenbetrieb mit einem Hersteller-Ingenieur vor Ort. Die Quellenbenennung sollte exakt mit dem alten Stack übereinstimmen (verbessern Sie sie nicht während der Migration — das ist ein separater Änderungssatz).
Weiterführende Artikel
- Software vs. Hardware-Videowand: 5-Jahres-TCO im Detail
- NOC-Videowand: Design für Network Operations Center
- Beste Videowand-Software 2026: Leitstand- und NOC-Vergleich
- IPMX vs. ST 2110 vs. SDVoE: AV-over-IP-Standard 2026
- Datapath Fx4 Alternative — Craft Wall vs WallControl 10
- Matrox Alternative — Craft Wall vs Matrox Mura
- Videowand-Controller