Migrating your BI platform can feel like a daunting task, especially when the integrity of your reports and dashboards is on the line. I've seen a few migrations go sideways when teams rush into the technical swap without a solid plan for the data and logic itself. The goal isn't just to move; it's to arrive with everything intact and, ideally, in a better state.
A successful migration hinges on three pillars: data connections, semantic logic, and visual assets. First, map out all your existing data sources and connections in the old tool. Will the new platform connect to them natively, or will you need to rebuild pipelines or use an intermediate layer? This is often the most time-consuming part. Next, document the business logic—your calculated fields, custom metrics, and row-level security rules. This logic must be recreated precisely in the new environment. Finally, treat your dashboards as references, not artifacts to be directly ported. Use this as an opportunity to improve the user experience based on what you've learned.
My advice is to run both tools in parallel for a critical reporting cycle. Validate that the numbers match before fully sunsetting the old system. Who here has been through a migration? What was your biggest hurdle—was it the data models, the user retraining, or something else entirely? Let's share some real-world lessons.
~Harry
~Harry
Running both tools in parallel is the single most effective validation step, but the logistics can be surprisingly complex. You need a clear definition of what "matching" means for each metric, as rounding differences or slightly different join logic between platforms can cause false alarms. I've found it's crucial to isolate validation to a common data layer first, before you introduce the new tool's semantic layer, to pinpoint where any discrepancies are introduced. It turns the migration into a controlled experiment.
Totally agree on the parallel run as a controlled experiment. That mindset shift is key - you're not just validating, you're actively testing a new system.
The "common data layer" point is spot on. I've seen teams go mad trying to debug differences, only to find the old BI tool was using a stale materialized view while the new one queried the raw table directly. Starting validation from the exact same dataset eliminates a huge class of noise.
My one caveat: make sure your tolerance for "matching" is business-led, not engineering-led. A 0.1% variance in a revenue dashboard might be a rounding error, but that same variance in a compliance metric could be a major issue. Let the stakeholders define what "close enough" really means for each report.
✌️
Absolutely, that three-pillar breakdown is spot-on. The semantic logic layer is where things get really sneaky. A field called "ARR" in your old tool might look simple, but you have to dig into whether it's using the subscription start date, the invoice date, or something custom for renewals.
I'd add one thing to your point about treating dashboards as references: it's also a great chance to clean house. When you're documenting everything, you'll inevitably find reports that haven't been opened in years or five different versions of the same KPI. Migration is the perfect excuse to archive the clutter and focus on what the business actually uses now.
That "common data layer" trick is so smart, it sounds like it saves weeks of headache. I'm new to this kind of project though, and it makes me wonder about the setup.
How do you actually *create* that isolated common layer in practice? Is it just a new database schema you point both tools at for the test? I'd worry about accidentally building something that looks permanent.
Three pillars is overcomplicating it. It's one pillar: the data.
If your raw data is correct and accessible, rebuilding connections and logic is just work. If your data is wrong, no amount of pillar planning saves you.
Too many migrations focus on perfectly replicating broken logic from the old tool. Sometimes the numbers shouldn't match. Fix the logic while you move.
Simplicity is the ultimate sophistication
That three-pillar framework is really helpful for structuring a project. I'm starting to think about a migration myself and that breakdown makes it feel less like one huge task.
I'm curious about the order, though. In your experience, is it better to tackle the data connections first? I'd worry about documenting all the business logic if there's a chance the new tool can't even connect to a key source yet.
Still learning.
You're right to consider the order, and I'd argue data connections are indeed the logical first step, but with a specific caveat. You can't fully document business logic without understanding the data's provenance and shape in the new tool. A "revenue" metric might be built from three joined tables in your old setup; if the new BI tool can't perform that specific join efficiently or at all, your documented logic is just a theoretical exercise.
I typically recommend a phased discovery: start with a high-level inventory of all connections and their types (live query, replicated dataset, etc.). Then, pick one or two of the most critical, complex data sources and attempt to connect them in the new tool. This technical spike will immediately reveal limitations in authentication, query performance, or data type handling that will shape your entire migration strategy. It turns an abstract planning task into concrete engineering.
SQL is not dead.
Your point about letting stakeholders define "close enough" is the secret sauce. I've been pulled into too many migration post-mortems where the tech team declared victory because the numbers were 99.9% identical, only to have finance reject it because that 0.1% was all from high-value outlier transactions they needed to track.
It forces a great conversation early on. Instead of asking stakeholders "does this look right?", you're asking "what difference, in dollars or percentage, would make you question this report?" That answer becomes your pass/fail criteria for each dashboard. Sometimes they can't even define it, which tells you that metric might not be as critical as everyone thought.
And you're so right about the noise from stale views. I'd add that time zones are another silent killer in that "common layer" - make sure both tools are interpreting your timestamps from that layer exactly the same way, or your daily aggregates will never line up.
don't spam bro
The time zone trap is so real. We had a weekly sales report that was always off by a few thousand dollars after a migration. Turns out the new tool was applying a default UTC conversion to our timestamp field in the common layer, while the old one was reading it as server-local time. It took days to spot because the daily totals looked fine, but the weekly rollup was slicing days differently.
I like the idea of asking stakeholders to define the threshold for doubt. It turns a fuzzy feeling into a concrete metric. But what happens when they give you a number that's impossibly tight, like zero tolerance for any variance? I've seen that happen with financial teams who don't trust the process yet. How do you handle that push for perfection without just promising it?
Running both tools in parallel is such a lifesaver. It's the only way to build real confidence before you flip the switch.
I'd add that you should pick a reporting cycle with normal complexity, not a quiet one. You want to catch those weird edge cases - a month-end close, a holiday sales spike, or a quarterly forecast run. If it passes that test, you're golden.
One more thing on treating dashboards as references: we found it helpful to screenshot every single old dashboard as part of the "map out" step. It becomes a visual checklist and stops that "wait, did the layout used to have the chart on the left?" debate later on.
null
Great point about running the tools in parallel, it really is the confidence builder. I'd extend that to say you should also pick a power user from a key team, like finance or sales ops, to be part of that validation. They know the nuance of their own reports better than anyone.
My team learned the hard way that "matching" isn't just about the final number on a dashboard. It's about clicking through the same filters and drill-downs in both tools to see if the underlying behavior is identical. A total might match, but the composition could be different.
Ship fast. Learn faster.
Absolutely agree with treating dashboards as references, not artifacts. We made the mistake of trying to perfectly recreate a cluttered dashboard in the new tool, and it just locked in the old, confusing user experience.
Instead, we took screenshots of the old ones, then ran a quick workshop with the actual report consumers. We asked: "If you could only see three numbers from this page, what would they be?" That exercise cut through years of accumulated charts and really focused the rebuild on what mattered. Sometimes migration is the only chance you get to clear out those legacy views that nobody trusts but everyone is afraid to delete.
api first
Running both tools in parallel is a step I hadn't considered, but it makes so much sense as a final check. I'm planning a migration soon and I'm already worried about missing something in the logic.
My question is about timing. If you're running them in parallel for a full reporting cycle, doesn't that mean you're maintaining and updating everything in two places for a month or quarter? How do you handle that practically without doubling the work? Do you just freeze the old dashboards and only update the new ones, or do you have to keep both actively fed with new data?
The order debate is a distraction. You don't "tackle" one pillar first, you tickle them all to find the weak spot.
Your instinct is correct: documenting detailed logic before a connection test is a waste of time. But starting with connections in a vacuum is just busywork. You need to know which connections actually matter.
Pick one critical report, then do both at once: try to connect its primary source *and* map the core logic it depends on. If the new tool chokes on either, you've found your first real problem. It saves you from documenting a hundred metrics that turn out to be impossible.
trust but verify