If your organization (college, non-profit, corporation, or other type of organization) is planning a major technology transition—switching to a new reporting tool, migrating to a cloud-based data warehouse, implementing a new ERP or CRM, or re-architecting your system integrations—you are likely sitting on one of the most powerful and time-limited opportunities to transform your data governance / data intelligence program. And yet, for most organizations, that opportunity passes by unrecognized, leaving teams as blind in the new system as they were in the old one. This post focuses specifically on one of the most common—and most disruptive—types of technology – switching to a new Analytics, Reporting or Business Intelligence (BI) tool. Whether you’re moving from SSRS to Tableau, from Crystal Reports to Power BI, or from any legacy reporting stack to a modern cloud-based solution, the challenge is fundamentally the same: hundreds of reports need to be evaluated, prioritized, documented, redesigned, and validated, often on an aggressive timeline.
The good news is that a well-structured approach—one that intentionally weaves data governance into the migration process itself—can dramatically reduce rework, accelerate report development, improve accuracy, and leave your organization with a rich, living knowledge base long after go-live. What follows are steps for doing exactly that.
One of the most common traps organizations fall into when facing a major technology project is viewing data governance as a separate initiative—something to tackle “after we get through the implementation.” The reasoning sounds logical: “We’re too busy with this project to also focus on data governance.” But this thinking is analogous to saying, “I’m too busy making dinner to fix the oven.” The two are not competing priorities—they’re the same priority.
A reporting or BI tool migration is, at its core, a data governance project. Every decision you make—which reports to keep, what each metric means, where data lives in the new system, how calculations should be performed, who owns which data elements—is a data governance decision. The question is not whether you’ll make these decisions. You will. The question is whether you’ll capture them.
When teams work through migrations without an intentional data governance structure, the organizational knowledge generated during that process—the “why” behind every choice—evaporates. Three years later, someone asks, “Why is customer retention rate calculated this way?” and no one remembers. The new system becomes just as opaque as the old one.
A migration is a rare moment when your organization will touch virtually all of its data—evaluating, rethinking, and rebuilding. Capturing knowledge as you build it requires only marginal additional effort compared to the enormous effort required to reconstruct that knowledge retrospectively. This is where the magic happens.
Before diving into the twelve steps, it helps to understand the pitfalls that plague most reporting migrations. Recognizing these challenges is the first step to designing a process that avoids them.
All of these challenges have the same root cause: the absence of a structured, documented process that integrates data governance thinking from the start.
To illustrate this framework in concrete terms, consider the following example scenario: your organization is transitioning from a legacy on-premise CRM system with SSRS reports running against a SQL Server database to a SaaS-based CRM with data pushed to a cloud-based data warehouse, and you’re adopting Tableau as the new reporting platform. You have six months before go-live. Here is how to manage the reporting migration.
Begin by compiling a comprehensive list of every report in the current system—in this case, every SSRS report running against the legacy CRM. This inventory should capture several key attributes for each report: the functional domain it belongs to (sales, marketing, finance, operations), a usability or certification rating indicating whether the report is known to be accurate, flagged as having issues, or simply unvalidated, and the usability scope—whether it serves the whole organization, a single department, or individual users.
If your organization already has a knowledge base with a report catalog, this inventory may already exist. If not, now is the time to build it. This initial inventory is the foundation upon which all subsequent steps depend.
Not all reports are equal, and not all of them need to be recreated at the same time—or at all. Once your inventory is complete, assign a priority level to each report. Prioritization can be time-based (must be ready at go-live, within 30 days post-launch, within 90 days, etc.) or simply sequential (work through the list from highest to lowest priority until time runs out).
Prioritization criteria should include organizational impact, frequency of use, and the report’s certification status. High-priority reports are those that are widely used, organizationally critical, and known to be accurate. Lower-priority reports, especially those used by only one or two individuals or flagged as potentially inaccurate, can be deferred or eliminated altogether.
This is perhaps the most underappreciated step in any migration project. Many reports that exist in legacy systems exist simply because no one ever deleted them, not because they serve an ongoing business need. Migrating every existing report by default is a significant waste of developer time and introduces unnecessary complexity into the new environment.
Apply clear elimination criteria: reports with known data quality issues and no active stakeholder, reports used by individuals who are no longer with the organization, reports that duplicate other higher-priority reports, and reports with no known business purpose. The filtered list that remains should represent only the reports that your organization genuinely needs in the new system.
With your prioritized and filtered list in hand—let’s say it’s 22 reports out of an original inventory of 60—import or create entries for all these reports in your report catalog or knowledge base. A tool like the Data Cookbook is designed for exactly this purpose, but even a well-structured set of shared documents can serve as a starting point if a dedicated tool is not yet in place.
The goal of this step is to create a single, accessible, authoritative record for every report that will be migrated. This record will be built out progressively over the remaining steps. Getting it into the report recatalog now ensures that all subsequent work is tracked, versioned, and visible to the full project team.
This is the step where data governance begins to generate compounding value. For each existing report in your catalog, document its purpose, description, and the specific data elements it contains. But do not simply label those data elements—create formal business glossary entries for them.
Take, for example, a “Customer Retention and Churn Rate Report.” As you document this report, you identify the key metrics it contains: Customer Retention Rate, Customer Churn Rate, Active Customer Count, New Customer Count, and Lost Customer Count. Each of these becomes a glossary entry with a functional definition (e.g., “Customer Retention Rate: the percentage of customers retained over a specific period”) and, optionally, a technical definition pointing to where and how this value is calculated in the legacy system.
This is what practitioners call “emergent content”—knowledge generated as a byproduct of documentation that extends beyond the single artifact being documented. Once Customer Retention Rate is defined as a glossary term, that definition is available to every subsequent report that includes the same metric. You only define it once, but you benefit from that definition dozens of times.
Once an existing report has been documented, create a corresponding new report entry in the catalog—the Tableau version that will replace the SSRS version. This new entry inherits the same purpose and description as its predecessor and shares the same glossary terms already defined in Step 5. What it does not yet have is the technical definition pointing to where those glossary terms live in the new system.
This approach creates a clear, auditable bridge between the old report and the new one—both represented in the catalog, both linked through shared glossary terms, and the new entry ready to receive technical specification as development proceeds.
With catalog entries in place for both old and new reports, you can now assign each new report to a developer for build-out. The developer’s primary documentation task—beyond actually building the report—is to fill in the technical definitions for each glossary term in the context of the new data system.
This is where the compounding value of the glossary becomes especially clear. If the developer building a Customer Retention report finds that Customer Retention Rate has already been technically defined by a colleague who worked on a different report earlier in the sprint, they inherit that definition rather than researching it from scratch. In a migration involving hundreds of reports with significant metric overlap, this kind of reuse can save dozens of hours of redundant investigation—and, more importantly, ensures consistent calculation logic across all reports.
Major migration projects generate a constant stream of data questions that need expert input: “What exactly does ‘active customer’ mean in this context?” “Which codes map to which statuses in the new system?” “Who owns the definition of churn rate for the marketing team?” Without a structured process for routing these questions, they pile up in email threads, get tabled for weekly meetings full of people who don’t need to be there, or simply go unresolved.
A data request process allows these questions to be routed asynchronously to the right subject matter expert (data steward) based on functional domain and content type. The expert can respond on their own time, their answer is captured in the knowledge base, and the workflow moves forward without requiring a synchronous meeting. This approach supports just-in-time expert involvement, structured escalation paths for unresolved disputes, and empowered data stewards who can self-approve within their domains.
For migration projects specifically, workflows may need to be streamlined compared to standard data governance processes—prioritizing speed of content capture over multi-level approval chains. Consider creating project-specific workflow templates with optional approval steps and lower friction for routine decisions, reserving full approval workflows for high-stakes definitional choices.
It is tempting, when implementing a new system, to only document the new one. Resist this temptation. Documenting both the legacy system and the new system in your knowledge base serves several important purposes.
The first year after a major system migration is typically characterized by elevated data quality issues, unexpected values, broken integrations, entry errors driven by unfamiliar workflows, and reconciliation headaches caused by incomplete data migration. These issues are far easier to detect and resolve if you have documented data quality rules in place before go-live.
As you document the new system and its reports, define data quality rules for critical data elements: expected value ranges, valid lookup values, required fields, and consistency checks across related data points. These rules, stored in your knowledge base, serve as the baseline for automated monitoring, issue reporting, and resolution workflows after launch. Getting this documentation in place during the migration project—when you are already examining every data element—is far more efficient than attempting to build it after the fact.
As each new report is completed, it should go through a defined review and approval process, the scope of which can be adapted based on the report’s business criticality. At a minimum, the report owner and a domain data steward should validate that the report matches its documented specification and that the output data is accurate relative to an agreed-upon baseline.
Once approved, the new report should be linked directly to its report catalog documentation. This can be accomplished through embedded documentation within the BI tool itself (many modern tools support this via API or embedded links), or simply by making the catalog URL accessible from the report’s metadata or distribution page. The goal is to ensure that any user of the report can immediately access its purpose, description, data definitions, and ownership information without having to hunt for it.
The final step—and in many ways the most strategically important—is to convert the momentum of the migration project into lasting organizational change. This requires two things: securing buy-in from the project team and leadership and translating the project’s stakeholder structure into an ongoing data governance program.
On the buy-in front, the most effective approach is not to pitch data governance as an add-on burden. Instead, frame it as what it actually is: a mechanism for helping the project team move faster, produce more accurate results, reduce rework, and get to go-live on time and on budget. When developers and analysts understand that the glossary they’re building saves them hours of redundant research, they become advocates rather than resistors.
On the data stewardship front, the working groups and functional leads assembled for the migration project are an almost perfect approximation of the data steward structure you need for ongoing data governance. The finance lead who validated all the financial report definitions during the migration? That is your Finance data steward. The IT architect who documented every integration mapping? That is your Data Systems steward. Formalize these roles before the project closes, define their ongoing responsibilities, and you will have a functioning data governance program—with real organizational knowledge—already in place on day one of the new system.
The business case for integrating data governance into your migration is not merely philosophical, it is practical and measurable. Organizations that follow a structured, catalog-supported migration process consistently report several categories of tangible benefit.
Reduced development time: When glossary terms are defined once and reused across dozens of reports, developers spend significantly less time on independent research and definitional debates. In large migrations with high metric overlap across reports—commonly 50 to 60 percent, this reuse can cut development time substantially.
Improved accuracy and consistency: When all reports drawing on the same metric reference a single, agreed-upon definition and technical specification, the risk of inconsistent calculation logic across reports is dramatically reduced. Users who see the same number in two different reports can trust that it means the same thing.
Faster user adoption: A new system with well-documented reports is a system that users can trust and understand. Transparency about how numbers are calculated, what fields mean, and who owns which data directly addresses the primary cause of new system skepticism. Users who understand the data are users who use the system.
A durable knowledge foundation: Perhaps most importantly, the data governance knowledge base built during the migration continues to provide value indefinitely. Every new employee who needs to understand the CRM data, every future report request, every data quality investigation—all of these benefit from the catalog content created during the migration.
A reporting or BI tool migration is, without question, a significant organizational undertaking. It demands careful planning, strong project management, and sustained team effort over months. But it is also, if approached correctly, one of the most valuable opportunities your data organization will ever have.
Every report you evaluate, every metric you define, every mapping decision you document is an act of data governance. The only question is whether you capture that work in a way that persists and compounds—or whether it disappears the moment the project closes and the team disperses.
The steps described here is not about adding work to an already demanding project. It is about doing the work you are already doing in a way that captures its full value—for the project, for the new system’s users, and for your organization’s data literacy for years to come. The measure-twice, cut-once principle applies here with force: a modest investment in structured documentation during your migration pays dividends that far outweigh the cost of a poorly documented system that no one fully trusts or understands.
Hope this blog post was of assistance to you and your organization. All our data governance and data intelligence resources (blog posts, videos, and recorded webinars) can be accessed from our data governance resources page. IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
Image Credit: StockSnap_PQASJKOCU7_ReportBirdMigration_BP #B1312