When it comes to reporting, more isn’t always better — better is better. As you move from legacy reports into the new Paradox Analytics experience, this guide is here to help you focus on what actually matters: the views your teams rely on to make decisions every day.

Instead of doing a one‑to‑one copy of every old report, we’ll walk you through how to identify the right reports to rebuild, how to take advantage of our new templates and data model, and how to turn “data dumps” into clear, visual stories your leaders and recruiters can act on with confidence.

1. Start with the audience, not the data

Legacy reports were often “data dumps.” The new tool is better suited for stories and decision‑making.

For each legacy report, ask:

• Who is the primary audience?
  Recruiters, hiring managers, TA leaders, HR ops, execs?
• What question are they trying to answer?
  “Are we hitting our hiring goals?”, “Where are candidates dropping out?”, “Which locations are struggling?”

Then design the new version accordingly:

• Tables for detail/extraction or audit use cases.
• Charts (bar, line) for comparisons and trends over time.
• Scorecards for top‑level KPIs that leaders want to see at a glance.

Outcome: Reports and dashboards that are designed for real decisions, not just data storage.

2. Use the migration as a moment to simplify

This is the best opportunity you’ll have to clean house.

Consolidate:

• Redundant or overlapping legacy reports that tell essentially the same story.
• Multiple slightly different versions of the same report for different audiences (replace with one core dashboard + views/filters where possible).

Standardize:

• Naming conventions, for example:
  [Team] – [Metric/Topic] – [Cadence]
  (e.g., TA – Weekly Hires by Location – Weekly)
• A small set of shared templates and dashboards for leadership, recruiters, and ops, instead of everyone building their own from scratch.

Outcome: A reporting layer that’s leaner, easier to maintain, and much clearer for your users.

3. Use the migration as a moment to simplify

Don’t try to rebuild everything 1:1.

Identify must‑have reports:

• What’s used in QBRs, exec decks, recurring ops reviews?
• Which reports actually trigger decisions or actions?

De‑prioritize:

• One‑off or “just in case” reports no one has opened in months.
• Old, slightly different versions of the same report.

If you track status in your legacy environment, you can even tag reports as “[Not Migrating]” so you have a clear backlog.

Outcome: A short, prioritized list of reports/dashboard views to recreate first, instead of dragging legacy clutter into the new world.

4. Align on metrics and definitions

Legacy reports sometimes hide inconsistent definitions.

Confirm your definitions for key metrics:

• “Hire”, “Offer Sent”, “Time to Hire”, “Conversion”, “Time in Stage”, etc.

Compare legacy vs. new:

• Did legacy reports use certain filters or date fields that created a special version of a metric
  (e.g., only internal hires, only specific brands/locations)?

Use the new model to standardize:

• Decide which definition is the source of truth, and apply it consistently across reports and dashboards.

Outcome: Less “Why doesn’t this match my old report?” and more confidence that everyone is looking at the same numbers.

5. Map old reports to new templates

Start from templates whenever you can.

For each legacy report, ask:

• Which of the standard templates gets me 80% of the way there?
  (e.g., Candidates, Job Current / Job History, Interviews, Journey Status, Talent Community, Campaigns, etc.)

Then decide:

• Which legacy reports can be recreated directly from a template with minor tweaks (add/remove fields, update filters)?
• Which truly require a from-scratch build because they span multiple categories or have unique logic?

Outcome: Faster rebuilds and more consistent structures, versus completely free‑form recreations for every report.

6. Re-evaluate filters, segments, and timeframes

Legacy filters often grew organically and can be confusing.

Check your legacy setup:

• Did the old report have hidden filters?
  (e.g., “only US,” “exclude brand X,” “only internal hires”)
• Were timeframes mostly fixed (e.g., “YTD”) when a rolling window (“last 3 months”) might be better?

In the new builder:

• Use Filters and the Timeframe selector to recreate what’s actually important, not every nuance that got added over years.
• Standardize on a few core views where possible:
  • Last 30 days
  • Last quarter
  • Last 12 months

Outcome: Cleaner, more understandable reports that are easier to reuse and maintain.

7. Check permissions and data visibility

New Analytics strictly respects CEM permissions, which can expose differences from legacy behavior.

Make sure:

• The right roles have Reports access (full vs. view).
• Admins understand that users only see data they’re allowed to see.

When scheduling or sharing:

• Email deliveries typically filter by each recipient’s permissions, so each person only sees their allowed data.
• Larger recipient lists or SFTP deliveries may be filtered by the creator’s access instead, depending on configuration.

Outcome: No surprises when someone opens a new report and sees “less” or “more” than they expected.

8. Re-think scheduling and delivery patterns

Migration is a great time to clean up how reports are delivered, not just what they show.

Audit your legacy behavior:

• Which reports are being emailed out but rarely opened?
• Where could a live dashboard or in‑app view replace a large email distribution list?

In the new tool:

• Use scheduling for genuinely recurring needs (e.g., weekly leadership snapshot, monthly KPI pack).
• Use live dashboards for teams who prefer to self‑serve and explore data on demand.
• Use file delivery (email attachments/links, SFTP) mainly when:
  • Another system or vendor needs the file, or
  • A data team regularly pulls files into a warehouse.

Outcome: Less email noise, fewer “set and forget” jobs, and more intentional reporting flows.

9. Validate numbers before moving off legacy

Side‑by‑side comparison builds trust.

For each high‑value report you migrate:

1. Run the legacy version and the new version for the same timeframe.
2. Compare a few key numbers:
   • Total candidates
   • Total hires
   • Conversion percentages
   • Time‑to‑X metrics

If there are differences:

• Check filters, date fields, and included segments first.
• Use this as an opportunity to fix old inconsistencies (e.g., mismatched filters or duplicated logic), not copy them forward.

Outcome: Stakeholders feel confident that the new report is correct before any legacy report is removed or deprecated.

10. Plan change management, not just configuration

Moving tools is as much about people and habits as it is about features.

Decide:

• Who needs live training vs. a recording?
• Who will be your internal Analytics “champions” in each region, function, or business line?

Communicate clearly:

• The timeline (GA, any 60–90 day window, and eventual legacy cutoff date once finalized).

Where to go for help:

• Help site articles
• Pendo in‑app guides
• Olivia / in‑app support
• Your Paradox CSM

Outcome: Fewer surprises, more adoption, and less last‑minute scrambling when legacy reporting is eventually retired.