GamingLiveOpsTelemetry

Live Ops and Map Versioning: Why Arc Raiders Should Keep Old Maps

UUnknown

2026-03-07

10 min read

Preserve old maps: essential for player retention, A/B testing, fast rollback, and telemetry migration in Arc Raiders' 2026 map rollouts.

Keep the Map You Know: Why Arc Raiders Should Never Fully Delete Old Maps

Hook: When Embark rolls out shiny new maps for Arc Raiders in 2026, the instinct from design and ops teams may be to remove legacy maps to reduce complexity. That shortcut risks breaking player retention, invalidating years of telemetry, and removing critical safety nets for rollouts and rollbacks. For live-ops and platform engineers, preserving older maps is not nostalgia — it’s an operational must.

Executive summary (most important first)

Preserving older maps provides four high-value outcomes for a live-service title like Arc Raiders in 2026:

Player retention: Familiar maps anchor players and reduce churn when content updates change meta and pacing.
A/B testing and feature experiments: Comparing behaviours across map versions requires parallel availability.
Rollback and reliability: Fast, low-friction rollback paths require old map assets and server logic to remain deployable.
Telemetry and matchmaking migration: You need historical schemas and versioned match pools to interpret metrics and migrate matchmaking safely.

Context — why this matters in 2026

Live ops in 2026 emphasize rapid iteration plus robust observability. Across late 2025 and early 2026 the industry has doubled down on server-side A/B testing, schema-versioned telemetry, and modular matchmaking (e.g., Open Match derivatives). Game publishers who recycle assets without a version plan face data loss, untestable hypotheses, and longer recovery times from regressions. Embark Studios’ announcement of multiple new Arc Raiders maps for 2026 makes this problem immediate: new map variants will alter player flow, load patterns, and combat pacing — all of which must be measured against the baseline provided by old maps.

"There are going to be multiple maps coming this year — across a spectrum of size to facilitate different gameplay." — Virgil Watkins, Design Lead (GamesRadar, late 2025).

Operational rationale: player retention, community trust, and content cadence

Players invest time learning maps. When a live service removes familiar environments abruptly, two things happen:

Casual players lose a comfortable entry point and may churn when the learning curve rises.
Communities that build guides, speedruns, and content around specific maps lose their investment and vocal advocacy.

Keeping older maps available (even in a reduced rotation) preserves a low-friction onboarding funnel and retains content creators. In practice, studios that maintain legacy maps report better weekly retention curves among returning cohorts, and more predictable engagement after major content drops.

Practical retention tactics

Keep at least one legacy map in the active rotation for every new big-map release.
Offer limited-time events on older maps (reward rediscovery and content creation).
Expose legacy map options in matchmaking settings — let returning players queue for "classic" rotations.

Technical rationale: A/B testing and statistically valid experiments

To prove a new map improves engagement or monetization, you must run controlled experiments where the only variable is the map. That requires:

Coexistence of map versions under the same matchmaking umbrella.
Consistent telemetry across versions to compute lift and regression.
Infrastructure that can route traffic deterministically (or probabilistically) to map variants.

Recommended A/B testing architecture

In 2026, the canonical pattern is server-side feature flags + matchmaker routing. Use a feature-flag system to assign players to cohorts, and the matchmaker reads cohort attributes to select the map pool.

// Example matchmaker pool config (JSON)
{
  "pools": [
    { "id": "classic_pool_v1", "mapVersions": ["stella_v1", "spaceport_v1"], "weight": 50 },
    { "id": "new_map_pool", "mapVersions": ["stella_v2_new"], "weight": 50 }
  ],
  "routing": {
    "cohortKey": "map_experiment_2026",
    "assignment": { "control": "classic_pool_v1", "treatment": "new_map_pool" }
  }
}

That config lets you 1) assign players to control/treatment with a flagging system (LaunchDarkly, Split, or homegrown), and 2) preserve the control experience by maintaining the older map assets in the classic pool.

Telemetry versioning: migrating schema without losing history

Telemetry is the single most important tool for evaluating new maps. In 2026 the best practice is to treat telemetry as a forward- and backward-compatible API. When adding map-specific events or changing event payloads during a map update, follow schema evolution rules (Avro/Protobuf/JSON Schema) so consumers can read both old and new events.

Schema evolution pattern (practical)

Assign an explicit event_version in each telemetry event.
Use additive-only changes where possible (new optional fields with defaults).
Maintain a registry (Confluent Schema Registry or similar) and enforce producer/consumer compatibility checks in CI.

// Example telemetry (pseudo-Avro/JSON) - v1
{
  "event_type": "match_end",
  "event_version": 1,
  "player_id": "abc",
  "map_id": "stella_v1",
  "outcome": "win"
}

// v2 adds optional paced_metrics
{
  "event_type": "match_end",
  "event_version": 2,
  "player_id": "abc",
  "map_id": "stella_v2_new",
  "outcome": "win",
  "paced_metrics": { "avg_engagement": 4.2 }
}

Design consumers to branch on event_version where necessary, and write migration queries that can interpret both versions. Preserving old maps but removing event_version support will make historical comparisons impossible.

Matchmaking migration: rolling the player base safely

Matchmaking changes are high-risk. A typical mistake is to change map IDs in-place and expect match queues to adapt. Instead, use explicit map versions and map meta that the matchmaker can use to keep queues separate while still allowing cross-version matching when desired.

Matchmaker migration playbook

Introduce new map IDs (e.g., stella_v2) without deleting old IDs.
Start a canary rollout: route 1–5% of traffic to the new map pool.
Monitor matchmaking latency, fill times, and abandonment for both pools.
Gradually increase traffic while running automated quality gates.
Only when metrics validate, increase rotation weight; still keep old maps as a failover.

Open Match and similar frameworks support pool-based routing; extend match keys with cohort and map_version to maintain clarity in logs and incident traces.

Rollback: make it fast, automated, and low-cost

Rollback is not a rare luxury — it’s a realistic part of every live ops lifecycle. The fastest rollback is a config flip that returns players to legacy maps. To achieve that, preserve both the assets and the server-side logic required to run them.

Rollback checklist

Keep build artifacts for old maps accessible in artifact storage (immutable hashes).
Keep server code paths intact and behind feature flags — avoid destructive database-only migrations that block revert.
Automate the rollback path in CI/CD pipelines (a single-button rollback to previous map pool config).
Maintain health checks and synthetic players to validate the rollback within minutes.

When teams delete old maps from storage, they also delete the shortest path to a safe rollback — increasing MTTR dramatically.

Cost trade-offs and storage patterns

There is a real cost to storing legacy map assets and keeping backwards-compatible server logic. In 2026, edge CDNs and delta-patching tools make that cost manageable:

Store compressed map assets (content-addressed) in object storage and push deltas to CDNs.
Use on-demand asset streaming for low-usage legacy maps to avoid hot-cdn costs.
Archive maps into a warm tier with fast reinstatement APIs instead of cold-delete.

Operational teams should measure the cost of storage versus the cost of outage and churn. For most live services, a small storage bill is trivial compared to a rollback that takes days.

Case study: Arc Raiders (hypothetical operational runbook)

Scenario: Embark deploys two new Arc Raiders maps (one smaller, one larger) in Q1 2026. Here’s a practical runbook for keeping older maps and implementing a safe rollout.

Phase 0 — Preparation (pre-deploy)

Ensure old map artifacts are tagged (e.g., stella_v1) and archived in object storage.
Create match pools: classic_pool_v1 and new_map_pool_v2. Do not change existing map IDs.
Update telemetry producers to add event_version and map_version fields. Register new schemas in the schema registry.

Phase 1 — Canary rollout (deploy day)

Assign 2% of daily active users to the treatment using server-side flags.
Route treatment cohort to new_map_pool_v2 while others remain in classic pools.
Monitor: match latency, abandonment, player session length, deaths-per-minute, and crash rate.

Phase 2 — Scale and compare (24–72 hours)

Run statistical tests on retention and engagement cohorts with at least 95% confidence thresholds.
Run targeted surveys + telemetry hooks for qualitative context (difficulty spikes, sightline issues).
If negative signals appear, flip the treatment traffic back to classic_pool_v1 instantly.

Phase 3 — Rotate and maintain

Gradually increase the new map’s rotation weight. Always keep at least one well-known legacy map in the rotation.
Keep legacy maps in warm storage for at least 3 months after full rollout to satisfy rollback and community requests.

Telemetry migration example: concrete steps

When adding a new map you often add new telemetry fields (e.g., new environmental triggers). Follow these concrete steps:

Add a new event_version for the enriched event (e.g., match_end v2).
Make new fields optional, and provide default values for old-version consumers.
Deploy producers first (maps and clients) in canary; keep consumers compatible.
Deploy consumer upgrades after producers have generated sufficient v2 data.
Run backfill jobs that tag historical matches with inferred fields where possible.

These steps avoid the common pitfall of a schema mismatch that breaks dashboards or long-running join jobs.

KPIs and dashboards to create before rollout

Match fill time by pool and map_version
Session length / retention (D1/D7/D28) per map_version
Competitive metrics: kills/deaths, average match score, time-to-first-engagement
Stability metrics: server crash rate, client crash rate, connection dropouts
Community signals: creator uploads, guide views, social sentiment score

Automation, CI/CD and testing

Automation reduces human error. Key practices for map versioning in 2026:

Package maps as immutable artifacts that CI can redeploy.
Run integration tests that validate matchmaking and telemetry correctness for each map version.
Automate schema compatibility checks in PR pipelines (fail if breaking change without explicit migration plan).

Community and governance considerations

Keeping old maps also has governance and legal benefits. Some tournaments, speedrun categories, or community-driven events require legacy maps. Removing them can break contractual obligations or damage brand trust. Maintain a policy for map deprecation that includes notice periods, archival guarantees, and restoration SLAs. This transparency reduces backlash and preserves goodwill.

Common pitfalls and how to avoid them

Deleting assets too early: Keep artifacts until you complete long-term cohort analysis (usually 90–180 days).
Schema-only upgrades: Don’t migrate telemetry schemas without consumer upgrades and backfill plans.
Implicit map ID changes: Always create new versioned IDs for new maps; avoid in-place edits to existing IDs.
Lack of rollback tests: Test rollbacks in staging with synthetic traffic monthly.

Actionable takeaways — what your team should do this week

Audit your map artifact store: tag, archive, and ensure retrieval API exists for legacy maps.
Implement event_version on match and map events and register the schemas.
Create a matchmaker pool that explicitly includes classic maps and instrument fill-time metrics by pool.
Add a one-click rollback to your deployment dashboard that swaps map_pool config and validates health checks.
Draft a public deprecation policy for maps and share a timeline with community channels.

Final thoughts: maps are data, not disposable assets

For Arc Raiders and other live-service shooters in 2026, maps are both game design and operational data. Treat them as part of your product’s critical surface: version them, instrument them, and preserve the ability to run previous versions in production. The cost of storage and a bit of extra orchestration is tiny compared to the cost of lost retention, irrecoverable telemetry, and prolonged downtime after a failed rollout.

Call to action

If you run live-ops for Arc Raiders or another live service, start by implementing the four pillars above this week: versioned maps, schema-versioned telemetry, pool-based matchmaker routing, and automated rollback. Need a migration checklist or a sample matchmaker config to kickstart your implementation? Download our Arc Raiders Map Versioning toolkit or reach out with your architecture; we’ll review it and suggest concrete next steps.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.