The things that cause migrations to stall are almost never the reports themselves. They're the dependencies nobody thought to document: the scheduled email that sends to a distribution list someone forgot about, the embedded dashboard that's iframed into an internal portal, the database credentials that exist only in one person's head. The inventory step is where you surface those before they surface themselves at the wrong moment.
Run this audit before you start building anything in the new tool. It takes a few hours and will save you from rediscovering critical pieces mid-migration.
Data Connections and Credentials
Document every data source your current BI tool connects to. For each one, record the connection type (direct database, ODBC, API, uploaded file), the server address or endpoint, the database name, and the credentials used. Note whether the connection uses a service account or individual credentials — service accounts need to be preserved and their passwords documented somewhere secure. Note any VPN or network requirements: if access to a database requires a specific network path, that same requirement will apply to the new tool.
For SQL databases, also note which databases require firewall allowlisting. DashboardFox connects from a static egress IP on all plans — you'll need to whitelist that IP on any database that restricts inbound connections. Getting this sorted in advance prevents the most common first-day blocker.
Reports and Dashboards — With Usage Data
Export a full list of reports and dashboards from your current tool. Most BI platforms have admin views that show all content with last-accessed dates. The last-accessed date is the most important column: sort by it and you'll immediately see that a large portion of your report library hasn't been touched in six months or more.
Categorize each report as: actively used (accessed in the last 30 days), occasionally used (accessed in the last 90 days), or stale (not accessed in 90+ days). You are rebuilding the actively and occasionally used reports. The stale reports are candidates for archiving rather than rebuilding — don't carry them forward by default.
For reports you will rebuild, document: the data source it connects to, the key fields and calculations, any filters or parameters, whether it's used as a standalone report or as a dashboard widget, and who owns or maintains it.
User List and Access Levels
Export your full user list with roles and group memberships. Note any users who have elevated permissions — report builders, admins, users with access to specific sensitive data sets. Also note users who are on the roster but inactive (covered in the usage audit): these don't need to be provisioned immediately in the new tool.
If you've implemented row-level security in your current tool, document the logic: which users see which data, how that's defined (by user attribute, by group, by explicit assignment), and what the data filter rules are. This design transfers as organizational knowledge even if the implementation mechanism is different.
Most BI environments accumulate clutter — stale reports, inactive users, redundant data connections. Migration is the natural moment to clean house. Provisioning only active users in the new tool, rebuilding only reports that get used, and rationalizing data connections is easier to do now than six months after you've gone live on the new platform.
Scheduled Reports and Email Delivery
Scheduled reports are the most commonly forgotten migration item, because they run in the background without anyone actively managing them. Go through your current tool's scheduler and export the full list of scheduled jobs. For each one, document: the report it sends, the schedule (daily, weekly, monthly), the format (PDF, Excel, image), and the recipient list or distribution list.
Pay particular attention to scheduled reports that go to external recipients — clients, stakeholders outside your organization, executive distribution lists. These need to be operational in the new tool before you turn off the old one, because the recipients are unlikely to report a missing email until something important was expected and didn't arrive.
Embedded Reports and External Integrations
If any of your reports or dashboards are embedded in external-facing applications, internal portals, or websites via iframe, document each embed: where it's embedded, what report it shows, who controls the surrounding page, and what the security model is (public view, authenticated user, token-based). Embedded reports require specific configuration in the new tool before the embed destination stops showing a broken iframe.
Also document any API integrations: tools or processes that pull data from your current BI platform's API, any SSO or authentication integrations, and any display-mode screens (lobby displays, dashboards on monitors) that run unattended.
Custom Code and Non-Standard Configurations
If anyone has written custom scripts, macros, or automation around your current BI tool — refresh triggers, export automation, data preparation scripts that feed the BI platform — document those too. They're often undocumented institutional knowledge owned by a single person.
With the full inventory in hand, you have a realistic scope for the migration: a specific count of connections to recreate, reports to rebuild, users to provision, and schedules to reconfigure. The next chapter covers the first step of the actual build: connecting your data sources.
