How to Approach Your Chartio Migration

Last Friday, Chartio announced today that they’re joining Atlassian and that Chartio won't be usable as a BI tool outside of Atlassian starting on March 1, 2022.

And all across the land, data analysts who use Chartio said unto themselves, 

In the next few weeks, there will be a blizzard of articles called something like, "856 BI Tools You Can Use Instead of Chartio" or "How to Choose A New BI Tool Now That Chartio Is Going Away."

These articles will have a lot of great advice about which BI tool you should choose if you need to replace yours. (I'd also like to suggest our BI tool roundup, which lays out the key features of major BI tools and gives some timely advice on how to choose the best option for your business.) But while choosing a new BI tool is really important, it's only one step on the road to recovery

In this article, I'll give you a handy map of the rest of the road you'll need to travel to swiftly and safely switch BI tools.

What you need to do right away

Dry your eyes and pour some coffee. For your BI migration to go well, you’ve got to get down to business.

Step 1. Figure out how much time you've got

The first thing you need to do is figure out how much time you actually have before you need to stop using your old BI tool.

For example, you might think, Chartio is going away in March of next year, it's early March now, so I've got about a year. But really, you don't:

  • You do not want to be spending February of next year in a frantic rush to finish getting off of Chartio.
  • January is when a lot of initiatives get launched; you don't have a whole lot of control over your schedule then.
  • December is when you get your biggest rush of requests for end of year analysis and planning for next year.
  • October is when you get your second biggest rush of requests because everyone is scrambling for a big industry conference.
  • Your boss just told you that sometime in the next 4 to 6 weeks your company is going to make a big pivot and to expect a ton of work that's going to eat up your schedule for 2 months

So really, you've got seven months...assuming no other major crises come up.

Step 2. Tell your boss and start pushing to make this a priority

And that's why as soon as you have a rough idea of how much time you've got to work with, you need to talk with your boss about making the switchover a priority.

Even if you follow best practices for getting high-level buy-in, there's a decent chance you won't convince them; there's just too much going on. That's okay. At the very least you can bargain down to getting started more quickly than if you weren't pushing.  

Whatever you do, walk in with a sense of what kind of time you've got to work with so you can impress upon them that no, a year really isn't all that long for this kind of project.

Step 3. Start communicating with stakeholders ASAP

You should also discuss with your boss what to tell other folks. Some people like to wait until they have a full-blown plan before they communicate anything. My two cents: when you're dealing with an event that's been publicly announced, it's better to give at least key stakeholders a heads up that you know about it and that you're on it.

When it comes to BI, you might also want to get ahead of the news simply because reporting and dashboards touch so many different departments, roles, and people at your company. Proactively communicating with those folks could help to alleviate their fears that their reporting is about to disappear...and could turn them into advocates for your switchover project.

Step 4. Start working on a quick and dirty assessment

Finally, it's time to figure out what the scope of the project really looks like. But don’t wait until you choose a new BI tool to start planning the project.  

If you have the time soon, do a full-blown assessment. But if you don't, at least do a quick and dirty assessment ASAP so you and your boss can figure out how much time you will need and when you will need it. Even if you can't make the assessment a priority right now, start carving out bits and pieces of time to at least get a 50,000 foot view of the landscape.

What to do during an assessment

Before you start a migration, you need to come up with a game plan. Here’s how to get started:

Step 1. Figure out what currently exists & what people actually use

First and foremost, you need to figure out how your current BI tool is being used. For example:

  • How many teams are using it, and roughly how many reports and dashboards do they have?
  • Which reports are actually being used, how often are they used, and how critical are they to a team's work?

At many companies, old reporting never dies, it just lingers in the guts of your BI tool. Teams get used to avoiding outdated dashboards and as long as everyone’s on the same page, it’s usually no big deal. 

But when you’re talking about a migration, knowing which reports you can ignore can mean the difference between an efficient (and satisfyingly tidy!) switch and a never ending slog that just perpetuates the problem. 

Step 2. Get stakeholders involved

Switching to a new BI tool is not something you want to do solo. You'll want to have at least some of your stakeholders involved. So, you need to figure out who should be involved and to what extent.

You can even involve some folks in the process of choosing the new BI tool by having a bake-off. Getting hands-on help evaluating tools not only ensures the new option will work for key use cases, it can also help to create goodwill among stakeholders who’d otherwise be annoyed by the change.

Step 3. Decide whether to refactor or re-architect

One of the tricky things about this project is that switching BI tools presents an opportunity to improve how you use them, but the more you try to improve, the longer your timeline will be

Depending on what BI tool you're going to switch to and what shape your current BI tool usage is in, there are a number of actions you might take to end up with a cleaner system. Here are some moves you can make that will pay off in the long run:

  • Consolidate where you can. Are there a number of reports that are basically the same or very similar that you could turn into one or just a handful of reports? Could adding some strategically chosen filters cut some of your dashboard cruft? A migration is a great time to make those improvements.
  • Push business logic into a view. As you crank out one report or dashboard after another, it's easy to end up putting more business logic than is ideal into the BI tool (e.g., customer segmentation). Since you're switching anyway, now might be a good time to move some of that business logic into a view—something you can start working on even before you have chosen your new BI tool.
  • Implement data viz best practices.  If you have to migrate all of your BI reports, it may be worth spending some time cleaning up their look and feel. Even if you don’t make them all brand colors, you can at least ensure that they're more effective in conveying information to users (aka, get rid of those truly awful, unintelligible pie charts that one team—you know the one—keeps requesting). 

In general, there are two ways to go when you’re making these kinds of improvements:

  • Re-architect: Make major changes that will have a big impact. The advantage of doing a major redesign of your approach to using the BI tool is that you can end up with a much cleaner, easier to maintain system overall. But if you’re up against a hard deadline, it can also be riskier
  • Refactor: Iteratively make lots of small changes. If you aren't sure how much time you'll have or how many other priorities will bump into this project, a steady stream of small, incremental changes can significantly improve how your business uses the new BI tool without derailing your timeline.

There’s no simple rule for deciding which way to go. But one rule of thumb is that if you're really not convinced that doing a major redesign is going to pay off or that you will have the time to do it, go with refactoring.

Step 4. Consider leveling up your data stack

If you’re already making big changes, it could be a good time to address the infrastructure issues you’ve been avoiding. For example, adding storage to your stack is an easy way to ensure that your new BI tool will run efficiently and can get your company closer to the single source of truth you’ve been dreaming of.

As with the previous step, don't go down this path lightly. In fact, I'd only recommend optimizing your data stack in two cases: 

  1. If you've been plugging you data straight into your BI tool
  2. If you've been pushing GA into Postgres and need a more sustainable solution

The reality is that you're probably going to have to rebuild quite a few of your queries (and reports and dashboards) as part of the migration. So while you're at it, adding a plug-and-play syncing and storage solution like Panoply could help future-proof your stack.

But—and I can't stress this strongly enough—be very careful about how much you take on during a BI migration project. Optimization is great, but committing to a DIY ETL or data warehouse buildout would be downright insane and even smaller value-adds like this one can be risky if you have to juggle other major priorities at the same time.

Step 5. Build a quick and dirty product backlog

Now that you have a rough idea of what you're going to try to accomplish and how you're going to do it, start building a simple product backlog. In general, the best way to go is to start with the most mission-critical reporting and then build outward from there.

But because you are switching to a new tool, you should also prioritize at least a few of your more complex reports so you can test out early how the tool handles your must-have edge cases. If it turns out there are some important reports that will be far trickier to do in the new BI tool, you want to know earlier rather than later.

Step 6. Plan for people and process

Even the best-laid plans can only do so much. As you’re working on your assessment, make sure to leave room for things like: 

  • Bandwidth. Can you handle all of the additional work on your own—and even if you can, should you? Given that you're going to need to keep the old and new tool running at the same time for at least part of the migration, consider bringing in an expert in the new tool who can help get the job done.
  • Communication plan. Communication with your users, their managers, and the Higher Ups is critical to a smooth migration. Take a few minutes to figure out roughly when and how you will communicate with folks.
  • Training. Most of your team will need to learn how to use the new product—and even seasoned analysts have to figure out where certain buttons/features live and get comfortable with the new tool's quirks. So you will need to plan to spend time training folks as well as creating cheat sheets, running brown bags, etc.
  • Increased support. Any time you roll out a new tool, odds are you'll have a bump in support requests. Factor it into your timeline, both in regard to how much time analysts will need to spend helping their colleagues and in regard to when you can comfortably sunset your old BI tool. 

Step 7. Create your timeline and get going

Once you've sketched out what you're up against, come up with a timeline and put together a plan. Short and sweet plans are fine. It’s better to quickly get down in a Google Doc the critical things you need to remember to do and get sign-off for than to feel overwhelmed and not get organized. Whatever you do, just make sure that you set up some drop dead dates for certain phases of the project so that if your timeline keeps slipping, you'll know when it's time to start pushing back hard.

Then get going! And remember, when you've got a hard deadline, a week that slips by at the beginning of the project is the same amount of time as a week spent frantically near the end of the project. The difference is that when it happens early, you might have a prayer of making it up. Later on? Not so much.


Having to switch tools because your beloved BI is going away is nobody's idea of a good time. But with a little planning and some urgency at the beginning of your unexpected project, odds are you can pull off a relatively smooth transition. And if you do it right, there's a good chance that your business will come out a little bit stronger and a lot more confident in how it uses data to drive towards success.

Get a free consultation with a data architect to see how to build a data warehouse in minutes.
Request Demo
Read more in:
Share this post:

Work smarter, better, and faster with monthly tips and how-tos.