This blog post is Human-Centered Content: Written by humans for humans.

Some words can mean more than they are supposed to. Let’s say we are working with tool X right now. There are four major scenarios:

1. Stay and optimize X.
2. Expand X.
3. Migrate from X to Y.
4. Let X and Y coexist (on purpose).

Afterwards we dive into When NOT to Migrate, Change Management and a handy Checklist.

In case you haven’t wondered before: These are not the first questions to ask, but the first questions that need to have an answer. If they don’t, chaos may emerge.

So, let’s break it down.

Four Change Scenarios

Scenario 1: Stay and Optimize

We are not adding, we are improving. An analytics tool like Tableau or Power BI might be limited by a very slow database, Snowflake might be limited by a missing governance, Atlan might be limited by not yet upskilled users. All tools would work fine, if…

This scenario should be our default. Whenever anything is not working to the full extent of its possibilities, we should check if everything is set up correctly, if it follows best practices and if the adoption rate is high enough. That includes upskilling employees, if necessary. It might be, that features still need to be discovered by certain colleagues.

Scenario 2: Expand

Use what your platform already ships. This is also an expansion of “Stay and Optimize,” which, again, should always happen first. Expanding is a kind of convergence option. Data platforms (think Databricks) offer more and more analytics options right within the tool. Snowflake’s Streamlit Apps for Analytics, Salesforce’s Data Cloud feeding Tableau Next and quite a few more. Databricks even managed to get listed on the Gartner Magic Quadrant for BI (including Analytics) for 2026.

This is an option, but please, give it the proper evaluation. Especially when it comes to expansion ideas, we need to be aware, that the marked for AI is shifting and not yet consolidated (as of July 2026). New tools, but also data platforms release feature after feature. Those parts are theoretically ready for production. Practically, they need a bit more time to prove themselves.

If we decide to expand, we need to plan out upskilling. Most features that we are interested in are only known to a smaller number of people. Also, we need to make the quite vast decision, to let way more people onto our data platform than before. Evaluations should consider that.

Scenario 3: Migrate

Replace tool X with tool Y, decommission X. That means the full program: Triage, moving, rebuilding, retraining and much more. For all the evaluation points, see the follow-up articles to this one.

Scenario 4: Coexist

It might be worth to have two tools that have similar capabilities. Naturally, they shouldn’t do the exact same things, otherwise we would just pay two tools without need.

On the good side: You don’t have migration costs and the entry cost for tool Y is smaller than a migration from X to Y, but it creates a coexistence architecture, and temporary introductions have a way of becoming permanent.

When would we introduce an additional tool, instead of a replacement? There are a few reasons:

• We have a wide group of people using tool X, but there is a way smaller group with needs, that X doesn’t meet. Ergo, we reduce our licenses and usage of X for that smaller group and give them the alternative Y.
• We are in the middle of an evaluation and need a test run. Of course, we cannot only test it in lab conditions, any tool needs to be tested out with real data at some point.
• We use a freshly introduced tool as negotiation leverage. Let’s say, the license fees for some platform goes not just up the usual amount, but doubles or triples. Maybe the people who negotiated our previous discounts all left. Then introducing a new tool before and testing it out before going into a license negotiation can certainly help.

And Don’t Drift!

If none of those 4 scenarios applies, then I bet you find yourself in one of two situations:

1. You keep tool X and do nothing. It’s basically the “nothing changes at all” option.
2. You introduce tool Y without a plan. At some point it either dies out, takes something else over or establishes itself as a coexisting solution. Only, without a plan.

We don’t want that. Let’s make a deliberate decision on what to do and not just drift along and let those tools decide for us what happens.

When NOT to Migrate

Some problems tend to survive tool or platform changes, mostly, because they never were tool or platform problems. So, a few pointers to what we should think of when considering change, even before we go into evaluations. If you don’t solve those, the migration is probably not worth it, as it will produce more costs than can be returned later on.

A: Solve Contested Data Models

Example: If two departments’ Tableau dashboards disagree today, the two Power BI dashboards after the migration will disagree, too. Maybe even more so early on, when employees are still learning. Solve data problems before migrating analytics tools. Or as a wider statement: Don’t migrate downstream, when there’s a mess upstream.

B: Ownership

With that I don’t mean migration ownership, but current ownership of:

• Data
• Content or content quality
• Governance or permission rules
• Adoption or upskilling.

If all that doesn’t exist before a migration, it won’t exist afterwards.

C: Cultural Blockers

If the reason to migrate is that tool X is not used enough, then tool Y will need to have an amazing UX improvement, otherwise people will also not use tool Y. If everyone is using Excel, then migrating from Qliksense to Sigma won’t do very much. (Well, with Sigma, maybe, as it’s very tight with spreadsheets, but the point still stands.)

D: Missing Skills

Upskilling, enablement, literacy – all that needs a plan. If we don’t plan for that, people will need use a new tool, but won’t know how. And nothing drives adoption less then missing tool knowledge.

All four points need to be solved.

Change (Management)

Everything we talked about here, we summarize under Change Management. Of course, there are many dozens of definitions of Change Management around, but I don’t care too much. For me it is just our way to accompany change. Which might be a migration.

One thing we should never do: Make headless decisions. That sounds way harsher than I mean to. I’ve seen headlessness in businesses, but that’s not the rule. And if you, dear reader, read this article, you are definitely not headless.

What I mean is: The James Webb Space Telescope had 344 SPOFs (Single Points of Failure), meaning any single one of them could have sabotaged the whole endeavour. With tool or platform migrations, we are not talking about so many, as most problems can be fixed. Luckily, our platforms are down on earth (for the most part). But there still are a few SPOFs, that we discuss in this mini-series. My message here is this: Identify them and do your best to manage them.