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.
Dry your eyes and pour some coffee. For your BI migration to go well, you’ve got to get down to business.
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:
So really, you've got seven months...assuming no other major crises come up.
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.
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.
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.
Before you start a migration, you need to come up with a game plan. Here’s how to get started:
First and foremost, you need to figure out how your current BI tool is being used. For example:
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.
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.
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:
In general, there are two ways to go when you’re making these kinds of improvements:
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.
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:
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.
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.
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:
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.