Migration Checklist and Next Steps

Use this checklist as your go/no-go reference before canceling the old tool's subscription. The items are organized by phase: setup, parallel validation, go-live, and post-migration. Check off each section in order rather than working through it all at once — the parallel validation phase in particular benefits from running for at least a week before declaring go-live.

Phase 1 — Setup

This phase is complete when the new environment is functional and populated with the priority content, but before any users beyond the initial testing group have been migrated.

• Static IP added to all database allowlists and firewall rules
• All data sources connected and returning correct results
• ODBC drivers installed and DSNs configured (if applicable)
• Priority Apps (semantic layer) built with correct table relationships and field definitions
• Top-priority reports rebuilt and validated — numbers match the old tool
• Library folder structure created with correct group permissions
• Groups created in Settings → Security → Groups
• Row-level security configured via Data Tags (if applicable) — tested with affected user accounts
• Custom domain configured (if applicable)
• Branding setup complete — logo, colors, login page (if applicable)
• Admin accounts confirmed and billing admin assigned
• SMTP gateway configured for scheduled report delivery

Phase 2 — Parallel Validation

Run both tools against the same data for at least one full business cycle — one week minimum, longer if your most important reports are monthly. This phase is for catching discrepancies, not just confirming the tool works.

• Priority reports validated by the people who use them (not just the person who built them)
• Report results match old tool output on the same date range — discrepancies investigated and resolved
• Scheduled reports running and delivering to correct recipients with correct data
• External-facing scheduled reports (client delivery, executive distributions) confirmed specifically
• Embedded dashboards updated to DashboardFox embed URLs where applicable
• Power user group (phase 1 users) is comfortable and has raised issues that have been resolved
• Secondary reports rebuilt for frequently accessed content beyond the initial priority set
• Dashboard filters behaving as expected — default views set, locked mode configured where needed

Phase 3 — Go-Live

This phase covers the broader user rollout and the transition from parallel mode to DashboardFox as the primary tool.

• All active users provisioned with accounts and correct group assignments
• User communication sent — what changed, where to find their reports, who to contact with questions
• Power users identified as internal point of contact for their respective teams
• Display mode / unattended screens updated to DashboardFox (if applicable)
• SSO integration configured if using header-rewrite or DoLogin API (if applicable)
• Guest Library configured for any public-view reports (if applicable)
• Onboarding resources shared with new builders — DashboardFox onboarding tab in admin is a useful starting point

Phase 4 — Post-Migration

These items can be handled in the weeks after go-live rather than blocking the cutover, but shouldn't be forgotten.

• Old tool subscription canceled (after confirming no outstanding reports or embeds still depend on it)
• Report usage monitored — inactive reports in the old library that weren't migrated should be archived or formally closed out
• Remaining report library rebuilt for occasionally-used content beyond the initial priority set
• App Builder expanded as new report types or use cases emerge
• Audit logging reviewed to confirm user activity is as expected
• Add-on users or plan upgrade evaluated based on actual MAU after go-live

What Good Looks Like After Migration

A successful migration isn't just a tool replacement. It's an opportunity to end up in a better position than you were before — better organized library, cleaner data access model, broader self-service capability across the team. The indicators that the migration went well are practical ones: scheduled reports run without manual intervention, new report requests from the business get handled by the team instead of queued for an analyst, and the monthly BI bill reflects actual usage rather than a provisioned roster.

If any part of the migration raised questions about feature setup, the DashboardFox knowledge base covers configuration in detail, and the support team is available to help with specific setup questions. The team that builds DashboardFox handles support — not an offshore tier.