Parallel deployment

If you already run a signage system — Tightrope, Carousel, BrightSign, NoviSign, a homegrown build, etc. — you don't have to flip everything to DisplaySync at once. Most teams that adopt DisplaySync do it gradually: a hall, a venue, a region. This page is the playbook for the parallel period.

When to do parallel vs. cutover

Cutover (replace everything at once) is the right answer when:

• The old system is failing badly enough that "stay on it longer" is more risk than "switch right now"
• The fleet is small enough (under a dozen signs) that a single event is a reasonable test
• You've already done a parallel test in lower-stakes settings and feel confident

Parallel is the right answer when:

• The old system mostly works and you're switching for specific reasons (cost, capabilities, support)
• The fleet is large enough that a full cutover is multi-event work
• Stakeholders need to see DisplaySync running before they're comfortable retiring the old system
• Your team isn't yet fluent enough with DisplaySync to bet a tier-1 event on it

Most successful adoptions go: demo → small event parallel → larger event parallel → cutover. Each step takes one or two events.

What "parallel" actually means

Parallel deployments take a few shapes:

Shape 1 — Same event, different walls

Some walls drive content from the old system; some from DisplaySync.

• Pros: lowest risk. The old walls are your safety net. Direct comparison.
• Cons: content authoring is doubled — every change has to land on both systems. Keep this short.
• Good for: first parallel test. Pick 2-3 lower-stakes walls (registration desk, hallway wayfinding) for DisplaySync. Keep keynote / sponsor walls on the old system.

Shape 2 — Same network, different walls

Like Shape 1 but the parallel period spans multiple events. The old system stays on its existing infrastructure; DisplaySync gets its own.

• Pros: cleaner separation. You can tune DisplaySync's network posture independently.
• Cons: two infrastructures to maintain.
• Good for: a multi-event quarter where you're rolling DisplaySync forward by venue or region.

Shape 3 — Same content, hot standby

Both systems display the same content. DisplaySync is "shadow mode" — running and reporting to the dashboard, but not necessarily on the wall.

• Pros: lets you exercise the operations workflow (claim, monitor, troubleshoot) without putting DisplaySync content in front of attendees.
• Cons: you don't actually use DisplaySync, so you don't learn what doesn't work until you switch.
• Good for: dry-run before the first real parallel deployment, or for stakeholders who need to see metrics from DisplaySync before approval.

Network segmentation

If both systems live on the same venue network, separate them as much as possible:

• Different VLANs if venue IT can give them. DisplaySync's outbound allowlist is documented in Network requirements; the old system will have its own.
• Different SSIDs if Wi-Fi (separate AP groups if available).
• Distinct hostnames so kiosks are obviously identifiable on the network. lobby-east-displaysync vs lobby-east-legacy.
• Don't share the same display. Don't run an HDMI switcher with one input from the old system and one from DisplaySync. Pick one per wall.

Content parity

If the rule for the parallel period is "both systems show the same content," the integration point is your CMS, not your signage system:

• Build content in your CMS at a stable URL. https://signage.example.com/lobby/east.
• Old system loads that URL (or pulls images from it).
• DisplaySync loads the same URL.
• Updates land in the CMS and propagate to both systems.

This is the content design pattern that already makes DisplaySync deployments simpler. It also makes parallel periods straightforward — you're not authoring twice, just rendering twice.

If your old system uses native scheduling or playlists that don't have a webpage equivalent, parallel content parity is harder. Common path: rebuild the most-shown content as a webpage, run that on both systems during the parallel period, treat the rebuild as part of the migration cost.

Operational discipline during parallel

A few rules that make the parallel period less painful:

Run-of-show shows both

Your event run-of-show document needs to identify which walls are on which system. "Hall B keynote — DisplaySync" vs "Hall A overflow — legacy." Otherwise techs reach for the wrong dashboard when something breaks.

One on-call for each

Don't have one tech responsible for both systems mid-event. They will pattern-match — fixing the old system's issues using DisplaySync techniques and vice versa. Either separate on-calls, or one tech with a clear "stop, check which system this is" reflex.

Track failures by system

Keep a parallel-period incident log: what failed, on which system, what was the fix. After 2-3 events you'll have data to make the cutover decision based on outcomes, not vibes.

Don't decommission the old system early

The temptation is strong: "DisplaySync is working great, let's pull the old system." Resist for at least one full event after you'd otherwise be confident. The first full-pressure event without a fallback is when surprises surface.

Cutover criteria

You're ready to retire the old system when:

• DisplaySync has run a full event of equivalent scope without issues you couldn't have caught and fixed.
• Your team is fluent in claim, content assignment, remote control, and troubleshooting workflows without referring to docs mid-event.
• Stakeholders approve — content authors, AV team, event organizers all comfortable with the transition.
• Off-cycle period available. Don't cut over the day before a tier-1 event. Give yourself a quiet quarter to absorb any post-cutover surprises.

Cutover checklist

When the parallel period ends and you're going DisplaySync-only:

1. Final image-build pass — capture the production-tagged image incorporating any tweaks from the parallel period
2. Migrate content to its final URLs — if you'd been using temporary URLs for parallel testing, stabilize them
3. Update event run-of-show — single system going forward
4. Decommission old system in stages — don't unrack everything in one day; pull walls in event-natural batches
5. Archive old system's assets — keep them for at least 12 months in case a customer asks for a look-back

Don't archive the old system into deletion. Many teams keep a documented "if DisplaySync has a bad day, here's how we'd fall back" plan for at least the first six months post-cutover. It rarely gets used; having it written down keeps the team calm.

See also

• Live event checklist — pre-event prep that pairs with parallel deployments
• Stability over features — why staged adoption is the right pattern
• Content design → URL stability — the pattern that makes content parity tractable
• Post-event teardown — applies to both systems during parallel