Translation pending for DE — the English text below is canonical.

Migration · 13 min read

Migrating from a hardware video wall controller to a software-defined stack

Last updated: 2026-05-15

Most control rooms do not migrate their video wall because the software is bad. They migrate because a hardware controller hit end-of-life, the source mix outgrew the capture cards, or the five-year refresh quote arrived and the number was hard to justify. This guide is for the team that has already decided to move and now needs a plan that does not put the wall dark during a shift. The audit, the two viable migration paths, the phase-by-phase sequence, the risks worth planning for, and what actually changes for operators.

When migration is the right call

Migration is not free. Before committing, confirm at least one of these is true — if none is, keeping the existing stack through its natural life is usually cheaper:

  • The controller hit or is approaching EOL. Once the vendor stops firmware patches, the wall is a security and reliability liability. Christie Phoenix and RGB Spectrum Galileo both reached end-of-life announcements in late 2025 — facilities on those platforms are on the clock.
  • Source count outgrew the capture-card budget. Each new baseband source on a hardware controller means another capture card, sometimes a chassis swap. When the source roadmap doubles, the linear hardware cost is the trigger.
  • The five-year refresh quote does not survive scrutiny. See the TCO breakdown — the refresh line item is where the hardware-vs-software gap is widest.
  • The source mix moved to IP. If feeds are now mostly NDI, RTSP, and browser-rendered dashboards rather than baseband HDMI / SDI, the capture-card architecture is working against the deployment.

The pre-migration audit

Migration failures almost always trace back to a skipped audit. Before any procurement, document four things:

  • Source inventory. Every feed on the wall today: type (HDMI capture, SDI, NDI, RTSP, KVM, browser), resolution, frame rate, and how it physically reaches the controller. This list is the specification the new stack must satisfy. The feeds that are baseband-only today are the ones that need a transport decision.
  • Layout inventory. Every named scene or preset operators use. These have to be rebuilt on the new stack — knowing the count and complexity sizes the commissioning effort.
  • Integration inventory. What talks to the wall controller today — an AMX / Crestron control system, an alarm trigger, a scheduling system. Each integration point is a migration task.
  • Operator workflow map. How operators actually drive the wall — dedicated console, touch panel, keyboard shortcuts. The new stack changes this, and the change needs to be planned, not discovered on go-live day.

Two migration paths

Path A — parallel run (recommended)

Stand up the software-defined stack on new commodity hardware alongside the existing hardware controller. Both drive content; the displays can be switched between them at the matrix or, for LED walls, by reassigning the controller output. Operators learn the new stack on a non-critical schedule, named scenes get rebuilt and verified, integrations get tested — all while the old controller is still the production system. When the new stack has run clean for a validation window (typically two to four weeks), the displays cut over and the old controller becomes the hot spare until decommissioning.

The cost of Path A is running two stacks briefly. The benefit is that the wall is never at risk — at any point before cutover, the fallback is the known-good old system. For a 24/7 NOC or SOC, this is the only responsible path.

Path B — big-bang cutover

Decommission the hardware controller and bring up the software stack in its place during a single planned-downtime window. Viable only when: the wall is not 24/7 critical (a boardroom, a training room, a low-stakes monitoring wall), the downtime window is genuinely available, and the new stack has been fully validated on a bench beforehand. For anything mission-critical, Path B trades an unacceptable amount of risk for a marginal saving on the parallel-run period. Most professional integrators will refuse to big-bang a NOC wall.

The phase-by-phase plan (Path A)

  1. Phase 0 — bench validation. The new stack runs on its commodity server in a lab or staging rack. Every source type from the audit is tested for ingestion. Every integration point is tested. This phase ends when the stack ingests a representative sample of the real source mix without issues.
  2. Phase 1 — parallel install. The validated server is racked next to the existing controller, connected to the same source network, and wired so its output can reach the displays through the matrix or a switch. The wall is still driven by the old controller.
  3. Phase 2 — scene rebuild. Every named layout from the audit is rebuilt on the new stack and verified against the old one. Software-defined stacks make this faster than the original build — scenes are configuration, not cabling.
  4. Phase 3 — operator training. Operators run the new stack on a non-production schedule — a spare display, an off-shift practice window. Browser- based control is a different paradigm from a dedicated console; half a day per operator is the typical learning curve.
  5. Phase 4 — validation window. The new stack runs as a shadow of the production wall for two to four weeks. Any instability surfaces here, with the old controller still carrying production.
  6. Phase 5 — cutover. The displays switch to the new stack. The old controller stays racked and powered as the hot spare for a defined period (commonly 30-90 days).
  7. Phase 6 — decommission. Once the new stack has carried production through the hot-spare period without incident, the old controller is decommissioned. Capture cards and chassis often have residual resale or spares value.

The risks worth planning for

  • Baseband-source transport gap. Feeds that were HDMI / SDI into a capture card need a transport decision on the new stack — an HDMI-to-NDI or HDMI-to-IPMX encoder, or a capture card on the software server. Identify these in the audit; they are the most common migration surprise.
  • Latency expectation mismatch. A hardware controller delivers sub-frame baseband latency. A software stack on IP sources delivers single-frame. For display review this is invisible; for an operator KVM workflow it can be noticeable. Confirm the latency budget in the audit — see IPMX vs ST 2110 vs SDVoE for the transport-tier options.
  • Control-system integration. An existing AMX / Crestron integration written against the old controller's API needs to be re-pointed at the new stack's API. This is integrator work; budget for it explicitly.
  • Operator trust. The first week on a new wall, operators are slower and more cautious. This is normal and temporary, but a cutover scheduled right before a known high-load period (a major event, a seasonal peak) is a planning mistake.

What changes for operators on day one

The honest list of what operators actually notice:

  • Wall control moves from a dedicated console to a browser tab on their existing workstation — usually received well after the initial adjustment, because it removes a physical trip across the room.
  • Adding a source becomes a few clicks instead of a request to the integrator. This is the change operators value most.
  • Named scenes work the same way conceptually but the interface is different. The audit-driven scene rebuild means there are no missing layouts on day one.
  • Multi-operator control — several operators changing the wall from their own keyboards — is usually new and takes a shift or two to become a habit.

Where Craft Wall fits

Craft Wall is a common Path-A migration target — the software-defined stack runs on a commodity Linux server that racks next to the outgoing controller for the parallel-run period, ingests the NDI, RTSP, IP-KVM and browser sources from the audit, and rebuilds named scenes as configuration. The perpetual-licence model (EUR 2,500 per canvas) means the migration is a one-time cost rather than the start of a subscription. For the full economic picture see the TCO breakdown; for vendor-by-vendor migration context, the Craft Wall vs Datapath and Craft Wall vs Matrox comparisons cover the two most common migration-source controllers.

Craft Wall is not the right target for every migration. If the wall has a hard sub-frame-latency requirement on operator KVM, or the procurement needs a Tier 1 vendor with a 15-20 year support horizon, the migration target is more likely another hardware vendor or a hybrid stack — see the eight-platform comparison for where each option fits.

Closing

A video wall migration is a project, not a product swap. The teams that do it cleanly treat the audit as non-negotiable, run parallel rather than big-bang for any critical wall, and schedule the cutover away from known high-load periods. Done that way, the migration is invisible to everyone except the operators — who usually notice the new stack is faster to work with by the end of the first week.

Read next: the TCO breakdown for the economics that justify the migration, the NOC reference architecture for the target-state design, and the interactive TCO calculator to run your own numbers.

Related reading