Migration guide
Running your KPI dashboard alongside Primer
Your KPI dashboard is reporting. Primer is committing.
Respecting the system you already run
KPI dashboards are the most common starting point in operationally-run companies, and for good reason: they answer the question 'are we on track right now?' with a single glance. This guide does not ask you to throw yours away. It shows how to take the KPIs you already watch and let Primer add the three things dashboards never quite gave you, explicit weight, five-tier rubric, and a target-setting negotiation that ends in a commitment.
Translating KPI-dashboard concepts into Primer
The vocabulary is almost unchanged. KPIs become metrics; targets become thresholds; the review cadence becomes per metric cadence.
| Source concept | Primer equivalent | Translation note |
|---|---|---|
| KPI | metric in the quintile stack | The name, unit, and owner map one-to-one. |
| Flat target (e.g. 95% uptime) | five-tier thresholds (alarm → optimized) | Flat target becomes the effective or optimized threshold; you add the three lower bands. |
| Review cadence (weekly dashboard) | per metric cadence (weekly, monthly, quarterly, or annual) | Per-metric, not per-dashboard, fast and slow KPIs can share a stack. |
| Red / yellow / green flag | alarm / concern / content + effective / optimized tier | Your three flags become five named bands; the top two reward performance above the target, not just meeting it. |
| Dashboard owner | metric origin + goal owner | Origin tells you *why* the KPI exists (regulatory, board, assigned, self-defined). |
Three ways to try Primer alongside what you already run
None of these ask you to give anything up. Pick the lowest cost option you can get away with. Your own data will tell you what fits.
Path 1: Concurrent
Run Primer concurrently
Do not touch your existing dashboard. Mirror the same KPIs into Primer as metrics, set tiered thresholds, and commit them through the resolution workflow. For one quarter, let your existing dashboard and Primer both report on the same numbers. Compare what each view surfaces to leadership.
Path 2: Combine
Combine inside Primer
If the Primer view is clearer, retire the standalone dashboard and fold every KPI into the stack. The underlying data pipeline stays the same, only the presentation layer changes. Your BI queries continue to work; Primer is a consumer of the same warehouse.
Path 3: A/B test
A/B test the review meeting
Run your Monday operations meeting with the old dashboard one week and the Primer tier view the next. Ask which meeting was shorter, clearer, and produced faster decisions. The answer tends to be the same after two or three cycles.
What Primer contributes beyond a standard KPI dashboard
Dashboards were designed to report. Primer is designed to commit. Here is what that means in practice.
Explicit weight, summing to 100
Most KPI dashboards show every metric at equal visual weight. Primer makes priorities a declared number, the KPI that matters most is the one with the largest weight value, and the composite score reflects that.
Five tiers instead of red / yellow / green
Dashboards collapse every state into three buckets. Primer's alarm / concern / content / effective / optimized scale separates 'meeting target' from 'exceeding it', and rewards the latter.
Per-metric cadence
per metric cadence from weekly to annual lets a weekly uptime KPI coexist with an annual customer-NPS metric on the same stack. Dashboards almost always impose a single refresh cycle.
Commitment workflow
the resolution workflow (draft, aligned, leader accepted, superior accepted, committed) turns target-setting from a manager's decision into a two-party negotiation. You get the same number at the end, but with buy-in and an audit trail.
lead or lag typing, leading vs lagging vs health
A KPI dashboard treats every number the same. Primer marks each metric as leading, lagging, or health, so leadership can read which way the business is moving, not only where it is.
Customization suggestions, code you may want to modify
You have the source. These are the changes KPI-first teams most often make to make Primer feel like the dashboard they already had, plus the new bits.
Wire your warehouse to the current metric value
Add a scheduled ingest that reads from your BI warehouse and updates the current value on each metric.
Dashboard-style layout on the metrics page
Add a grid variant on the metric stack component that renders every metric as a tile rather than a row. Your Monday meeting keeps its dashboard muscle memory.
Sparkline per metric
Inline a small time-series chart next to each metric's current tier by reading metric history.
Red / yellow / green compatibility view
If leadership will not let go of three-color flags, add a mapping: alarm + concern → red, content → yellow, effective + optimized → green. Keep the five-tier data underneath untouched.
Alert fan-out on tier drop
Extend the alerts module to post to Slack or PagerDuty whenever a committed metric drops a tier. Matches how most teams already wire their existing dashboard.
You bought a perpetual source license. Every part of Primer is yours to change. These are suggestions, not requirements.
Let your team discover what fits
Run one quarter with the old dashboard and Primer both live. Ask which one leadership opens on Monday morning after two cycles. That answer is the one that counts.
Try it on one KPI first
Pick one metric your team already watches. Put it into Primer with five tiers and a weight. See if leadership reads it faster.