Your OKVIZ Synoptic Panel Broke? Diagnose, Recover, and Replace It (2026)

Before you migrate anything, make sure you are fixing the right problem. A blank or errored Synoptic Panel has a few possible causes, and only one of them is the retirement.

- **"This visual is not available" / a gray placeholder box where the map used to be.** This is the classic retirement symptom. Prior to April 10, 2026 you would have seen a warning triangle on the visual in Desktop and Service edit mode; after retirement the visual stops rendering entirely. - **A red error banner inside an otherwise-present visual** ("Can't display this visual"). This is usually a data problem, not the retirement — a missing category field, a renamed column, or a measure that now returns blank. Check the field wells first. - **The map renders but no areas are colored.** That is a binding mismatch: your category values no longer match the area ids in the SVG (a renamed room, a changed case). The visual is fine; the data lineage changed.

If you have the gray "not available" placeholder, you are on the retirement path and the rest of this guide applies. If it is either of the other two, fix the binding or the field well first — you may not need to migrate at all yet.

Give OKVIZ its due here: Synoptic Panel v1 was free, was one of the most-downloaded custom visuals in AppSource history, and made data-driven imagery accessible to people who would never write a line of D3. Its retirement is not a cash grab — OKVIZ rewrote the visual from scratch to sit on the current Power BI APIs, which is exactly the responsible thing to do with a decade-old codebase.

What "retired" means in practice: v1 receives no more updates or security fixes, and past the retirement date Power BI stops loading it. Nothing was deleted from your report — the map definition, the field bindings, and your data are all still inside the .pbix. The container that used to draw them is simply gone. That distinction matters, because it means recovery is possible: the pieces are there, you just need a new visual to render them.

For the full background on the v1-to-v2 transition and the v2 licensing model, see our deep dive linked at the bottom. This guide stays focused on getting a broken report working again.

Do this first, even if you already know which replacement you want. Your SVG map — the traced regions and their ids — is the expensive artifact. Someone spent an afternoon in Synoptic Designer clicking around every room. You do not want to redraw it.

Two recovery routes, depending on whether the visual still opens at all:

1. **If you can still open the visual's settings** (on a machine where a cached v1 still loads, or in an older report copy), export the map from the visual's own map/SVG settings and save the .svg file somewhere safe. 2. **If the visual is fully dead**, use the **Synoptic Panel Toolbox** (OKVIZ publishes it on GitHub). It extracts the embedded SVG maps out of a .pbix that used v1, so you can recover the geometry even when the visual no longer renders. Keep the extracted .svg — it is portable and feeds every option below.

While you have the map open, write down the **area ids** and the **category values** they were bound to. That mapping is what actually breaks in a migration, and having it on paper turns a guessing game into a checklist:

The most direct migration is to OKVIZ's own successor. Your existing SVG maps carry over, which is the whole reason Step 1 matters.

The steps OKVIZ documents:

1. **Install Synoptic Panel v2** (or Synoptic Panel Lite) from AppSource or okviz.com. Note that v2 and Lite are different downloads with different licensing. 2. **Add the new visual alongside the old one** on the page and load your recovered SVG map into it. You cannot swap v1 for v2 in place — settings do not transfer automatically, so you reconfigure the field wells and formatting. 3. **Rebind category + measure**, using the area-id audit from Step 1 to make the ids line up. 4. **Delete the dead v1 visual** once the v2 copy matches.

Two things to price in before you standardize on it:

- **Certification.** The **full v2 edition is not Microsoft-certified** and can use external services — certified-only tenants will block it. **Synoptic Panel Lite is certified** and runs locally, but with a reduced feature set. Check your tenant policy before you pick an edition. - **The free-tier cap.** v2's free tier is limited to **15 data points and one map per visual**. A 20-room floor plan already exceeds it, which puts you into per-user, per-month subscription pricing that scales with how many people open the report.

If your map is small, your tenant allows the edition you need, and you are happy staying on a vendor's lifecycle, Option A is the shortest path back to a working report.

The other route removes the vendor lifecycle from the equation entirely: regenerate the map as a custom visual you own outright. In VizForge Synoptic Studio the workflow is:

1. **Upload the image** — your recovered SVG, the original floor plan, or even a screenshot of the old map (PNG, JPEG, or WebP). 2. **AI segments and names the areas** — Claude Vision outlines each region and labels it from the text it reads ("Lobby", "Office A", "Line 3"), with a confidence score per area, in about a minute for a labeled plan. 3. **Refine and match your ids** — rename areas, edit binding ids so they match the category values from your Step 1 audit, drag vertices, draw any area the AI missed, and preview with sample data. 4. **Download a .pbiviz you own** — import it through the Visualizations pane, bind the same category and measure, done. You get the compiled visual and its full TypeScript source.

The ids match your data the way synoptic veterans expect: every area carries a binding id, matched case-sensitively against your category column — the same model v1 used, so your existing lineage transfers cleanly.

The commercial model is the real contrast with a subscription: a synoptic map is **15 credits, a one-time credit spend** — no per-viewer licensing, no 15-data-point cap, no lifecycle clock. Credits come from one-time packs (a Pro pack is 30 credits for $24.99, covering roughly two maps), credits never expire, and a failed generation is auto-refunded. Once the .pbiviz exists it keeps working whether or not you ever spend another credit, because you own the source.

Both are valid. Pick on three questions:

**1. How big is the map?** Under 15 data points and one map per visual, v2's free tier may cover you at no cost — reinstall. Bigger than that and you are paying either way, so weigh a recurring subscription against a one-time credit spend.

**2. What does your tenant allow?** If you are locked to certified visuals, your OKVIZ option is Lite (certified, reduced features); the full v2 edition is blocked. A generated .pbiviz is uncertified too — you import it directly or ship it as an organizational visual with admin approval. Know your policy before you commit.

**3. Who do you want holding the code?** Reinstalling keeps you on OKVIZ's roadmap and their next lifecycle decision. Rebuilding as an owned .pbiviz means the deprecation that just broke your report cannot happen again from a vendor's side — the trade is that maintenance becomes yours.

There is no wrong answer. A small, certified-tenant, low-effort fix points at v2 Lite. A large map, a per-viewer cost you want gone, or a "never again" reaction to the retirement points at an owned rebuild.

The lesson of the v1 retirement is not "OKVIZ let me down" — it is that any visual you do not control is a dependency with someone else's lifecycle attached. Two habits make the next deprecation a non-event:

- **Keep the source artifact.** Always export and archive the .svg map (and, for any critical custom visual, the .pbiviz file itself). A visual can be retired; a file you saved cannot. - **Prefer ownership for load-bearing reports.** For a one-off internal chart, a free marketplace visual is the right call. For a synoptic panel your operations team looks at every morning, owning the .pbiviz and its source removes the single point of failure that just cost you a working report.

Whichever route you take today, do the binding-id audit from Step 1 first. In synoptic migrations the drawing is rarely the problem — the id-to-category matching is where reports actually break.