In short

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 ended Phoenix production on 1 October 2022, and RGB Spectrum now lists Galileo as a legacy product — 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. For a NOC wall, plan the parallel run instead.

The phase-by-phase plan (Path A)

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.
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.
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.
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.
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.
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).
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 adds encoding, network and decoding delay that depends on the source format. 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 fits a Path-A migration — the software-defined stack runs on a standard Linux server with an NVIDIA GPU that racks next to the outgoing controller for the parallel-run period, ingests the NDI, RTSP, HDMI/SDI capture, RDP/VNC remote-desktop and browser sources from the audit, and rebuilds named scenes as configuration. The perpetual-licence model (EUR 2,500 per server) 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 two widely installed hardware controller lines.

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, whose adjustment period the training and the shadow window are there to absorb.

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.

Frequently asked questions

When is the right time to migrate from a hardware video wall controller?

Migration makes sense when at least one of: (1) the existing controller has hit or is approaching EOL — Christie ended Phoenix production on 1 October 2022, and RGB Spectrum now lists Galileo as a legacy product; (2) source count outgrew the capture-card budget — every new baseband source needs another card; (3) the 5-year refresh quote does not survive scrutiny; (4) source mix moved to IP (NDI, RTSP, browser dashboards) — capture-card architecture works against the deployment.

What are the two viable migration paths?

Path A — parallel run (recommended): the new stack runs alongside the existing controller while operators learn it, scenes are rebuilt and integrations are tested; after a validation window of typically two to four weeks the displays cut over, and the old controller stays racked as a hot spare for a defined period (commonly 30-90 days) before decommissioning. Lower risk, higher cost (two stacks run briefly). Path B — big-bang cutover: the hardware controller is decommissioned and the software stack, fully validated on a bench beforehand, is brought up in its place during a single planned-downtime window. Lower cost, higher risk. Path A is the only responsible path for 24/7 critical infrastructure; Path B fits walls that are not 24/7 critical, such as boardrooms or training rooms.

How long does a typical hardware-to-software migration take?

The schedule is agreed for each project, because it depends on what the audit finds: the number of sources, scenes and integrations and the operator training plan. The sequence follows the phased plan: pre-migration audit (source inventory, integration mapping, operator workflow capture), bench validation, parallel install and scene rebuild, operator training, a validation window in which the new stack shadows production (typically two to four weeks), cutover, and a hot-spare period before decommissioning. The audit is where most projects underestimate scope.

What's the biggest risk in migrating a 24/7 NOC wall?

The most common surprise is the baseband-source transport gap: feeds that reached the old controller as HDMI / SDI into capture cards need a transport decision on the new stack — an HDMI-to-NDI or HDMI-to-IPMX encoder, or a capture card in the software server — so identify them in the audit. The other risks to plan for are a latency mismatch on operator KVM workflows, AMX / Crestron integrations that must be re-pointed at the new stack's API, and operator trust in the first week, which is why the cutover should not land right before a known high-load period. The parallel run keeps the old controller carrying production until the new stack has passed its validation window.

What changes for operators on day one of the new stack?

UI muscle memory transfer — the biggest day-one friction. Operators trained on hardware-controller physical panels suddenly use mouse / touch UI; operators trained on Windows controller suddenly use browser. Mitigation: hands-on training before cutover (half a day per operator is the typical learning curve) plus the two-to-four-week shadow operation, in which operators work on the new stack while the old controller still carries production. Source naming should match the old stack exactly (do not 'improve' it during migration — that's a separate change set).