Migrating Legacy Platforms to Tableau: Modernize Your Analytics
The Data-Driven Community Meetup holds monthly webinars on business analytics and big data. Webinars are held on the second Wednesday of the month at noon (12:00 PM) central time via Zoom Webinars and will cover topics related to enterprise data management. Our goal with each webinar is to provide meaningful insights and actionable takeaways to simplify analytics so you can make better decisions.
The topics we cover include data strategy, data management, data warehousing, BI modernization, embedded analytics, and cloud migration and strategy. Learn how to build reporting solutions that drive your business demand based on your needs.
About the Topic
President at XeoMatrix, Chris Monahon, and Client Success Manager, Stuart Tinsley, recently held a meetup titled “Modernize Your Analytics: Migrating Legacy Platforms to Tableau” to showcase how to modernize stagnant legacy analytics platforms and start planning for a migration to Tableau.
The event aimed to offer attendees an insightful presentation on how best to craft a migration strategy for your organization. You’ll learn about various migration approaches, best practices, tips & tricks.
This article includes a recording, transcript, and written overview of the Modernize Your Analytics: Migrating Legacy Platforms to Tableau presentation.
Presentation Video
Summarized Presentation
Discover the key steps to revitalize your outdated analytics platform by migrating to Tableau, the leading data visualization tool. XeoMatrix, a trusted partner of Tableau, provided valuable insights on crafting an effective migration strategy for your organization. This presentation explored different migration approaches, shared best practices, and offered practical tips and tricks to ensure a successful transition to Tableau.
The session provided information on how to modernize your analytics capabilities and unlock the full potential of your data with this informative session.
Presentation Outline
- What is BI Modernization?
- Legacy BI vs. Tableau
- Choosing the Right Strategy
- The Migration Process
- Best Practices & Recommendations
Transcript
>> CHRIS MONAHON: All right, everyone. Welcome to our DDC event, our data-driven community, where we meet monthly with folks that are like-minded and love data, and we discuss all topics around data. So thank you for joining us. If you haven’t been to one of our past events, we have a great event planned for you today. Here’s today’s agenda. We’re going to be doing just some general housekeeping announcements and then we’ll jump straight to the presentation. I’ll be presenting.
My name is Chris Monahon, president of Xeomatrix, and I’ll be presenting on Modernizing Your Analytics and migrating from legacy platforms over to Tableau. And Stuart will be my co-host, and he’s our client success manager over at Xeomatrix. So we’ll be going through our presentation, and as we do, we’ll have a Q and A panel discussion at the very end. So if you have any questions, please go ahead and put those in the chat.
So our meeting format today is a webinar meeting, so it is 100% virtual. Please observe customary Zoom webinar etiquette. Of course, if you want to participate, please put any comments in the chat window. We’d love to hear from you guys and answer any questions or if you have any comments. Again, as I mentioned, we will be having a Q and A session at the end, and this will all be recorded. So any content or information that we share here will be sent out later to you via email.
I do want to just announce some of our upcoming future DDC events. Next month, we’re going to have a very interesting presentation on how to simplify your migration to Tableau Cloud. This is something that we get a lot of requests on. A lot of people who currently host their own Tableau servers are looking at how to reduce some of their administration costs and also get some better SLA up-times. And so they’re moving or considering moving to Tableau Cloud. And we have a whole presentation on what that process is like and what you can expect. So please stay tuned for that presentation.
We have some other DDC events coming up. We have one in June as well. Sorry, that is the June one. I have a typo there. And then we’re taking a break in July for the summer break, and then we’ll return back in August with another exciting event. So that’s our events coming up.
If you guys were able to catch Tableau conference last week in person or attended it virtually, all the sessions I do want to mention are online now, so I have the URL there. If you weren’t able to catch some of the sessions, they’re all recorded, you definitely want to go back and watch them. They’re all online and available, so please take some time and check them out.
So with that, let’s jump to our featured presentation and it’s, “Modernize your analytics. Migrating from legacy platforms over to Tableau.” As I mentioned, we have Stuart Tinsley, who is our client success manager at Xeomatrix. He has over eight years of experience with Tableau, and he previously worked at Tableau as well.
I myself have 20 years of data analytics experience, and I previously worked at Micro Strategy. So together we’ve both done a lot of these legacy BI migrations, and we have a lot of experience dealing with these. So we wanted to do this presentation today to sort of share our experiences and answer any questions you guys might have around both the reasons to do a migration from a legacy platform over to Tableau or maybe questions around what that process might look like or how to get prepared for that migration process.
So our agenda, we’re going to start off by talking about what is BI modernization. And then we’re going to jump into, “How does legacy BI compare to Tableau?” And then we’ll discuss sort of when you’re talking about doing a migration, “What is the right migration strategy to use based on where you are as an organization and maybe even the size or footprint of your organization or the legacy footprint within your organization?” We’ll jump into the migration process and what that looks like, and we’ll share some tips and best practices that we picked up over the years and how they might help you.
So let’s talk about BI modernization. What is that? BI modernization is really the transition from more traditional legacy applications to what’s more of a modern platform so that you can make better, quicker decisions in order to better serve your business. And it’s more than just better visualizations. On the left, I have more of your standard grid-based reporting. It’s very cross-tabular, and you think of modern BI as visual.
Well, that’s one of the benefits. But what you tend to see is that you get a lot of savings with modern BI because you’re getting quicker insights and you’re able to build things faster and develop them faster so it’s quicker time to market. With legacy BI, it’s traditionally longer development times, and a lot of times things are siloed. Development is siloed. And modern BI is all about democratizing your data and creating a data-driven culture for everyone.
So that’s what we’ve seen when we’ve noticed organizations moving from legacy BI over to modern BI. That’s where we see all the benefits. So as I mentioned, with modern Bi you’re going to get happy users, happy adoption. Probably, the first thing we notice right out the gate, is that there is a huge uptick in adoption. It’s new, it’s refreshing, and people are getting the insights they need versus having to go back maybe to IT or someone else to create the reports for them.
It enables this self-service reporting and they are getting the insights they need at their fingertips. And as I mentioned, that just fosters this data-driven culture and really brings the organization together to making powerful decisions based on data.
Another key benefit of BI modernization on the IT side of the house is that it’s going to be less maintenance. It’s going to be easier to support. IT doesn’t become that report factory anymore, creating all the reports for the business. They are the stewards of the data and they are going ahead and providing the infrastructure for the analytics versus having to be involved in the day-to-day report generation. And that overall leads to lower total cost of ownership and definitely a higher return on investment.
Another key benefit of modernizing or moving from legacy BI to a modern BI platform is that a lot of times this process can be pretty smooth. It can align really well with maybe what your IT department already has in mind. So there are a lot of initiatives out right now where people are moving to the cloud infrastructures, AWS, Azure, they’re also moving their data warehouses to the cloud. And so if you’re having to go through this process already as an organization, it might be time for you to evaluate making a move over to a more Modern BI platform like Tableau.
So here’s a couple of examples that we have. These are just some visualizations to show vaginosisbacteriana.org some of the analytics that you can do. This is an executive retail analytics dashboard. We have some supply chain insights here, but it’s not mainly just business dashboards. You can get really fancy with it and have more complex designs and pack a lot of information into one spot.
The other great use cases that we’ve seen is that you can do analytics, embedded analytics, and provide analytics to your clients, your customers, your partners, or vendors. This is a really powerful feature that you get with modern BI. Tableau has a very robust SDK that allows you to embed it inside of every application. And with that, with this API, you can go ahead and put it within your portals, your vendor portals, your customer portals, or within your actual products themselves. So this is a very powerful use case we’ve seen.
And then lastly, modern BI doesn’t just stop with dashboards. AI is coming and NLP features are there. And so if you checked out Tableau conference last week, you saw that Tableau launched some really exciting features around Tableau GPT and something that’s powered by that called Tableau Pulse, which allows you to use NLP to create visualizations on the fly using just text.
And so it’s very powerful in that it’s going to change the way not only we visualize our data or create our dashboards, but how we consume the data too. It’s not necessarily something that we’re going to be going out and viewing dashboards. That data and information will come to us and all that is provided through modern BI stacks like Tableau.
So there’s sort of three types of approaches that you might take when you’re doing a migration. And there are sort of three general buckets. There’s the total migration, which is, you’re going to replace your legacy platform. This is across the entire organization, and this is ideal for obviously smaller footprints or organizations, but it’s also a good fit for large organizations if you do it in phases. And so we’ve seen this done successfully many times. If you’re not looking to maybe bite off quite a huge endeavor, the partial migration does make sense. And that’s where you’re going more at a department level and identifying groups that maybe aren’t satisfied with their current legacy application and really want to just start making that move now versus waiting for you to do a company-wide migration. And so this is great for large organizations because then you can break things into phases.
And then lastly, if your organization maybe you don’t have a set of users that you’ve identified that are looking to modernize or move off those legacy platforms, you can introduce a new tool within a new department, maybe they’re still using Excel. This is a perfect way to start that process and start that path or journey down using a modern platform within your organization. So those are sort of the three different approaches we have.
>> Stuart TINSLEY: Chris, I have a question. Where do we see most clients start? Where is the best place to start?
>> CHRIS: Yes, that’s a good question, Stuart. I think for most of our clients, I would say they go with either the total or the partial. The partial has a lot of advantages in that you can evaluate and migrate one department at a time, and that way you can come up with a better strategy as you start migrating other departments.
So I would say probably a lot of people start with a partial migration and then do a total takeout there. That’s what we see within larger organizations. With smaller ones, it does tend to be number one, just the total migration. So that’s a great question.
All right, before we talk about some of these approaches and which ones might be good for your organization, let’s talk about legacy BI versus Tableau. So I’ve been talking a lot about legacy platforms and legacy BI and what names come to mind when you say that. You got your Cognosis, maybe your Microsoft SSRS or Click or Micro Strategy. There’s a whole list of them out there and a lot of these are still around today. We’ve seen some implementations where legacy platforms have been around for 15-20 years, and the question always is, why are they still there?
I think a lot of them got their starts, first of all, way back in the day. So back in the late 90s, and early 2000s, these were the only tools that were available for doing data analytics. And at the time, they might have been good applications, but over the years, they haven’t aged very well. I would say most of the time, they are ingrained into your business processes and maybe those processes are out of date now and it’s time for a better, more modern platform.
And so that’s what we’ve seen. They’re usually there because people have to use them because it’s part of their job, but from what we’ve seen, they’re really good at what they do. Like, for example, maybe exporting a lot of data. But we all know nowadays that’s not the approach to do. We don’t want to have people exporting and dumping their data and doing analysis elsewhere. We want them to share that and collaborate and sort of spread that across the organization. So that’s why we still see legacy BI still ingrained in a lot of places.
The challenge with legacy BI is that there’s definitely a higher total cost of ownership. The licensing can tend to be expensive. The development times, as I mentioned, often are longer as well and require teams to do it. It requires more IT and higher administration and training as well. A lot of times folks aren’t trained in some of these older applications, and so it takes months to get people up to speed.
Some of the other challenges too are that the usability is poor, so you don’t see a lot of adoption. And so there isn’t a lot of self-service that goes on, and that of course leads again to longer development times where people aren’t creating their reports and they need assistance to do that. So that’s typically what we see.
>> Stuart: Yes. It’s also worth mentioning, like in the slide you have on older technologies like Excel. Excel falls into that legacy category. Excel across the organization, or custom applications you might be using, maybe that’s for embedded purposes. All of those still apply here for the challenges and fall into that legacy business intelligence category, I think.
CHRIS: Yes, that’s true. I mean, everybody forgets about the original legacy platform which is Excel, and so we still run into pockets of whole departments running off Excel still. So I think we’ve all been there. That’s a good point. That’s a good point, Stuart.
So what we’ve seen now is a movement. A lot of folks moving from these legacy platforms over to Tableau and modernizing with Tableau and right out the gate, they want to see that increase in user adoption. If you’ve ever used Tableau, you understand the simplicity and power of it and the usability of it for people to just quickly get up and running and getting insights.
The self-service aspect is there. With Tableau, we see a lot higher adoption and more self-service and they get shorter development times, which of course reduces your cost of development. So with Tableau, we’re seeing organizations that make the move, see a lower TCO and definitely start building more of a data-driven culture than they would have seen with legacy BI applications.
So here are a couple of case studies, just a couple of migration use cases that we’ve done over the past. This particular organization, they do a lot of reporting and build solutions for healthcare, and they had six-plus years of Micro Strategy. So this was a Micro Strategy Tableau migration and it was really stagnant. There was not a lot of new analysis going on, it was very expensive to maintain. And the development times, as I mentioned, were pretty long for any report. It required a lot of IT intervention and what they called report factory.
What we did was we went in and helped them develop a migration strategy and a project plan and helped them reimagine their reporting in Tableau. And what they saw right out the gate was a 15% increase in user adoption in the first month, which is amazing, just amazing. There were more people using the system than they had on Micro Strategy. And then, coincidentally, there was also an immediate ROI that came out of this that they identified $2 million in revenue from unmarked claims. And the irony of this is that the same report existed in Micro Strategy. It’s just that no one was using the application, no one was doing the discovery and analysis, but yet with a modern platform, people were engaged, people were using it, and right away they recognized that immediate ROI.
So that’s a really interesting use case. I like that one there. The other one that we have is Cognos to Tableau migration. This was actually an embedded use case, which I mentioned earlier in the presentation. This organization provides software and services for state and local public sector. So they had built a solution over the web that they provided to public safety departments for accident and ticket information. And it was using legacy Cognos, which was very grid-based and there was zero self-service.
So we helped them conduct a full evaluation and built a POC for them and then trained their development team on how to do that and help build out the Tableau data sources and dashboarding. And they were able to immediately see the value in that. They offered some of the newer features that are in Tableau, such as Dashboards and the filtering to their users as a value add. But then they in turn also created a new revenue stream that they were able to monetize their data by adding this self-service feature now that they could upcharge their clients for.
So this is a super cool use case in that they were able to see a way not only to do the migration but to supplement, that migration cost by monetizing their data. So that’s a very interesting use case.
And then lastly, I’ll close with, there’s a large supermarket chain that we’ve worked with, and they had over 14 years of legacy Micro strategy development, and they were finding it very difficult to even find reports, long development cycles and again, they had a lot of report factories. A lot of the store reporting was done by one team.
We helped them with their strategy and planning and outlined sort of a change management strategy, as well, on how their organization could shift over from Micro Strategy over to Tableau. And right away, they saw a 20% increase in self-service analytics at first store reporting and they reduced their administration costs considerably. So those are just three use cases that we’ve seen in the past, and so I wanted to share those with you.
All right, so let’s talk about how to choose the right strategy. Now that we’ve gone through all that, we’ve talked about what is BI modernization. What is legacy? What is BI? What are some of the disadvantages of that and why you might want to move to modern BI? Here are three approaches again, the total migration, the partial migration, and the new implementation.
In order to identify a strategy, there’s three steps I like to walk through. First of all, one would be to perform an assessment. So before you start the process of even considering a migration, you need to understand what are some of the challenges you have today. So listen to some of the common pain points you have. Are you hearing the word lack of adoption, difficult to use.
Maybe you have a lot of shelfware people are even using it. Maybe you have those report factories I mentioned, and maybe your business is always dependent on IT. These are all keywords for probably understanding that it’s time to make a change. And so this is the process we use to identify what’s the business justification here for making a move. And then once you’re pretty sure that it is time to make a move, start your planning.
So understand and talk to your business and understand what are the highest pain points right now. And that will help you also build the business justification there on justifying the costs and the time to do the migration from your legacy platform over to Tableau.
You want to understand, what are some of the usability challenges they’re having. Are you having adoption problems? What are some of the biggest pain points and what is the impact on the organization if you don’t make this change? That’s also critical. If you’re lagging behind and your competitors are a more modern platform, then that’s something to definitely consider as an investment.
You also want to identify what departments or user groups are your first target audience. Who are maybe some of those early adopters that are willing to make this change and then understand your timelines?
And then lastly, and I’ll touch on this later, you want to perform an object inventory assessment. You need to understand on your legacy platform how many reports or dashboards are we talking about moving. That way you can start wrapping your head around on what that scope might be.
And after you’ve done that, the last step is again revisiting this strategy and understanding how are we going to tackle this based on the information we have and maybe the size of our organization or where we are as far as what is the footprint of our current legacy platform. Go ahead and choose one of these three options.
For the total migration, again, we typically see this definitely with smaller organizations. They usually go for option number one, but it’s also for large organizations. We’ve seen some very large organizations, like 20,000 users that have done a total migration and really it’s because of that first bullet there. They’ve seen poor companywide adoption and they know it’s time to make a change. So they’re going ahead and making that decision now.
Then the second is they’re wanting to create a corporate BI standard and wanting to modernize it. And as I mentioned, when you’re considering a total migration, you could marry this up with other IT initiatives that are going on. So if you’re moving to the cloud or there’s maybe a big license maintenance renewal coming up on your legacy BI platform, that could be a reason to do a total migration versus waiting and doing a piecemeal as a partial migration. Those are some of the main things or reasons we see people do a total migration.
So that’s the strategy I would take. For the partial migration, definitely, we see larger organizations try this out as well. They’re wanting maybe to do more of a phased approach because they know it’s going to take time and there’s a lot of change of management around the migration process. But when you’re doing this, you want to identify what are those early adopter departments and work with them to understand which ones want to migrate.
And then again, and as I mentioned, the last resort would be, to find a new place just to introduce Tableau. So that might be a group, as Stuart mentioned, that it’s just using Excel. Or maybe it’s a smaller footprint of a different BI application. Maybe it’s a small click implementation or something like that. You could totally introduce Tableau and get your organization started toward a more modern platform. So those are the three types of strategies that I would use.
Now let’s talk about the migration process in general. This isn’t super technical, but it’ll give you an understanding of what the migration process is and how we go about preparing for that. So there are five objectives we want to do with a migration. First of all, you want to make sure that you’re simplifying the migration to Tableau. This should be an easy process.
Secondly, you want to make sure that you’re improving or reimagining analytics using Tableau. We don’t want to do maybe a lift and shift and just provide the same types of reporting. So we want to reimagine analytics using Tableau. Third, we want to make sure that we’re training our subject matter experts and our end users, as well as our developers.
After we’ve done the migration, we want to make sure that it’s successful and that we’re seeing that adoption that we like to see with Tableau. And then we want to make sure that at the end we’re supporting the internal BI team. You want to make sure that the BI team has all the information they need to be successful.
Let’s look at a hypothetical migration. In this use case, we’re migrating from legacy platform X and we’re targeting a four-month migration. So we want to roll this out across a couple of phases, and the first step we want to do is perform that object inventory assessment that I mentioned. We want to identify and prioritize the objects that are moving and then we want to go ahead and set up a migration roadmap.
We like to do things in two phases. So what we do is we identify phase one being any critical or high-priority objects, and then phase two is going to be that lower-hanging fruit, so all things that maybe just aren’t higher priority. And we’ll touch on why that is in a second.
And then to wrap up the implementation plan, we’re going to do a heavy focus on training and enablement to make sure that our developers, our subject matter experts, and our end users are all up to speed on best practices with Tableau. And then lastly, we’re going to promote Tableau to see that adoption through lunch and learns or Tableau days or maybe even a center of excellence.
So let’s start with the object inventory assessment and how you might go about doing that. So every legacy BI application has some sort of metadata repository of some sort. It could be a database, flat files, or some sort of information that you can either connect to via API or you can connect to directly through ODBC connection. Or the third option is that they also offer reporting or analytics through some sort of admin tool that they have.
The process you should take a look at is gathering that information in order to understand how many total objects you are looking to migrate, and how many data sources first of all. What types of data sources? Are you connecting to more internal applications like Oracle or DB Two or are you going more to a redshift or a snowflake?
So understand the data sources you’re connecting to. And then also take an inventory of how many reports or dashboards that you’re wanting to migrate. Once you have that total number, analyze and filter out any redundancy.
So there are going to be a lot of reports out there that are duplicates, that are test, let’s say temp or junk or you’d be surprised what you see out there. It’s like cleaning out a closet. But you want to filter those out and take out any anomalies as well, and then identify any must-have critical reports as well.
So our process is once we have the inventory list, we cleanse it and then we go ahead and break the reports out into either subject areas or by department. And then we meet with the different groups that are responsible for those reports to understand if we’ve missed any. And then are there any critical ones that definitely need to be included?
Now, when you’re doing this analysis to identify what falls into phase one, a very common approach is to do it based on the number of executions. That’s a great assumption because things that are usually executed the most are probably the highest priority.
As we all know, some things are just based… A lot of legacy platforms do a lot of bursting. They do a lot of bursting of reports, scheduled reports, and things like that, so that can be misleading sometimes. When you look at the number of executions, that is important, yes, but that is not the end all, be all, that can be misleading in some ways, and so that’s not necessarily all the critical reports you need.
The other is to look at it based on user usage and which users are using those reports. So we have a lot of end-of-year reports that are used by finance and those always, almost always get missed if we’re looking at it by execution. So that’s a little tip. I would say as you’re doing your object inventory assessment, as you go through this process, to make sure you’re including everything in your final assessment.
And then once you do, you prioritize them and understand which ones are going to be phase one. And then everything else is really phase two. And phase two is really the low-hanging fruit. Phase one is really your official launch and phase two should just be anything you might have missed in phase one.
So this is what a process looks like, or the methodology. So we start off, of course as I mentioned, understanding the requirements, doing the object inventory assessment, and then you do your project planning and design and understanding what is phase one and phase two. Now, you might not just have one application that you’re migrating, or I should say a project that you’re migrating.
So if your application, for example, has multiple projects in it, you’re going to probably do a lot of these work streams in parallel. So you might migrate project one while another team is migrating project two. And then you’ll keep iterating on this either by subject area or by project, by creating the data sources, migrating the reports and dashboards, doing the unit function testing, and then UAT and then launching.
So that way you can do things in parallel and still launch different projects or sets of reports without having some sort of sequential waterfall approach. It’s very more agile in development.
So that would be my recommendation. And then post-launch, you of course want to meet with everybody and make sure everybody understands how to support the application. And then you want to promote user adoption. So this is what it looks like visually. On the far left, we call it the initialized phase. This is where you’re gathering that information, doing the object inventory assessment and really preparing for the migration.
All the while you introduce Tableau training to your developers. So they’re coming up to speed on Tableau. For a lot of them, it might be new to them and so it’s a little bit of a paradigm shift. They’re going to have to understand how to do things differently. Start that training early and that way by the time you’re done with that initialized phase and the planning phase, you can jump straight into the migration with your development team.
And then you start that migration. And that’s going to be of course, building out the data sources, building out the back end, maybe possibly aggregate tables in your data warehouse to support the data sources, and then doing the dashboard development too. And then toward the end of your migration, you’re going to want to do your subject matter training and then your end-user testing and then support that with lunch and learns.
All the while you want to have change management and communicating the process to your end users what is coming down the pipe. And we’ll touch on change management in a second. And then once you’ve launched, it’s really just support. And then, as I mentioned, migrating anything that’s left over in a small dot release for phase two.
So here are some recommendations I would make based on my experience doing a lot of these. You’d be surprised, but about 60% to 80% of the reports and dashboards don’t need to be migrated. It’s a crazy high number. You’ll find that a lot of the objects you have in your existing systems just don’t need to be migrated. As I mentioned, they’re test or junk or they’re just old or they’re stagnant, so you just don’t need to move them. When it comes to personal reports, the number is even higher.
A lot of times, a little pro tip we have is during the user acceptance testing. As part of the training, we have end users actually build out those personal reports. I think that’s a good way to reinforce some of the training. So any personal reports that they want to move, they migrate themselves and that seems to be a really good approach that we’ve seen work. So that’d be a recommendation I make.
I can’t stress the next bullet enough. Do avoid a total lift and shift strategy. It seems like that would be the best way to go. I have a lot of stuff I could totally automate that, and move everything over. But it’s important that you want to reimagine things in a more modern way using the new advanced features that you just have in Tableau now.
I use the analogy of if you’re moving from one house to the other, you don’t just throw everything into a box and move it to your new house. You want to make sure that you’re prepared and clean things out. And then when you move to your new house, everything is what it needs to be, not just all your junk.
If you’re just doing a lift and shift, you might as well stay on your old legacy platform because you’re only going to be providing the same functionality or offering analytic capabilities that your users have today. There will be some lift and shift, don’t get me wrong. Sometimes there’s some low-hanging fruit that just needs to be moved over. These are typically operational grid reports that some business still needs. That is fine, but try to avoid an overall lift and shift.
As I mentioned, I recommend doing it in two phases. We’ve seen people try to do everything at once, identifying everything at once. You’re not going to flag everything. So it just does make sense to do it in phases and do what’s highest priority first and then everything else second. And the other advantage is that you get that benefit of migrating and seeing the benefits of that migration earlier versus waiting to do maybe a six-month or a year-long migration. So try to get that out the door first.
I would focus on performance and scalability. When everyone moves to a new platform, they want to make sure that it’s blazing fast and perception is everything, so it’s always good to make a first good impression. So if you can afford it, have a high availability multi-node server infrastructure, or you can move to Tableau Cloud, which I highly recommend. Also make use of caching strategies in Tableau, so that you can use extracts to make sure things are performant.
And then at the end, of course, don’t forget about change management. I think that’s a very important part to the success of this. And with change management, it’s important to communicate throughout the entire migration process. You want to meet with the business teams frequently to explain to them what some of the upcoming changes are. And the reason you’re doing that is you want to minimize any sort of risk to the business and understand the impact of what this migration might have on them.
So you want to meet frequently with them and also communicate what some of the changes are going to be. Show them some sneak peeks of what some of the new features are. Get them excited. Because change is something that is a process and people of course react to it differently and so we need to help the business to understand that their processes will change but for the better and it’ll make their lives a lot easier. So rather than being data poolers, they can actually do analysis.
This is something I can’t stress more than enough. Please focus on change management. If you have any questions, please reach out, we can help you with that. I will close with just a couple of bullets on some things to consider as you start down your journey maybe considering doing a migration from your Legacy BI platform. When you’re ready to make this move to Tableau, identify your Tableau champion. If you’re going to be doing a migration and building a business use case around that, you need an executive sponsor, so identify that person within your organization.
I would conduct a proof of concept to evaluate Tableau. We do this a lot for a lot of clients. It doesn’t have to be long. It could be one to two weeks, sometimes three. Identify some current and future use cases and make sure it’s a good fit for those departments that are looking to make that switch.
And then definitely perform TCO ROI analysis and then prepare a thorough migration plan. Do that object inventory, understand what needs to be moved, and how long this is going to take, and meet with both the business and IT to get signed off on that. And once you’ve done your migration timing, you want to make sure that you plan when this is going to happen.
So one common thing we see is that a lot of folks aren’t really aware of when their maintenance renewal is on their legacy application. It’s good to sort of work backward from that so you understand how long you might have before you sunset your legacy application, or if you do want to run them in parallel for a period of time, how long that’s going to be so you can reduce that cost.
And again, just to close, I want to stress; avoid that lift and shift strategy. It is definitely best to reimagine reports in Tableau. So if there’s only one takeaway from this, I would recommend that. So if you have any questions, please let us know. Feel free to reach out to myself or to Stuart Tinsley and we can be happy to answer any questions that you have. So, Stuart, I’ll go ahead and turn it over to you. I don’t know if we have any questions from the audience.
>> Stuart: Yes, no questions that came in, but I know one that we get and we talk through a lot, which would be probably a good topic to address is what is the typical length of a migration? If you could talk through that maybe.
>> CHRIS: Yes, that’s a great question. Of course, everybody gives the, “It depends”. But I would say for an average-size migration, we would say that three months is typically what a migration might be. Now, for smaller organizations, that might be quicker. For very larger organizations, three months might be a phase for development.
But we try to keep the total time around three months to do a migration and that typically works out pretty well. And that includes start to end. That little diagram that I showed, so includes the preparation, the training, as well as the rollout.
>> Stuart: What about the people that need to be involved? What business groups are we typically seeing are involved in the migration process?
Chis: Yes. So again, you need to have that executive sponsor for sure. I think when it comes to business involvement for the migrations, we always see the subject matter experts and the head of the departments that are really involved in identifying not only what needs to be migrated, but when it needs to be migrated and how to get their teams trained up on Tableau. So those are the way that we see the business involved.
From our side when we do these migrations, if you were to staff a team to do this, I think the team that would need to be organized in order to perform a migration, you need a PM or some sort of delivery manager, you definitely need a trainer and then you’d need a team lead with probably one or two consultants. That’s a typical team that we would use for development. So hopefully that gives an idea of the IT side as well.
>> Stuart: Yes. A question came from Jim. Who is doing the data engineering and what tools are your people using?
>> CHRIS: Well, that’s a great question. I guess when it comes to data engineering, it sort of depends on the platform you’re using. We’ve seen a lot of people that are moving now to more modern platforms, so a lot of Snowflake out there, a lot of Big Query, Redshift, and Data bricks as well. I would say in most instances, there’s the migration team and then there’s the data team that does the data engineering. We don’t usually see it together, so there’s usually working in collaboration because the data engineering team really wants to own the processes and the naming conventions and everything like that.
Now sometimes, they’ll give us permission to create that kind of stuff for them. But a lot of data engineering is done in collaboration with the migration team. And I think what we typically do is we will meet with them and assess the model and understand what the data sources are and then talk to them how we can maybe build some aggregates or things that can make Tableau more performant. So that’s usually how that collaboration works with data engineering. As far as the tools go, we’ve seen people use different types of things. There’s a lot of DBTE, for sure.
>> Stuart: DBTE. Yes.
CHRIS: I would say we’ve seen people use third party. I don’t see as much prep, I would say, or Alteryx or anything like that. It’s more on the other side of the house, less prep or Alteryx. We have seen some folks do Denodo. So to build that sort of abstraction layer there, that’s another approach that we’ve seen people take as well. And that has other benefits which we won’t go into in this presentation, but that way you don’t have to necessarily know what the data sources are. Any other questions Stuart?
>> Stuart: Let me take a look. I mean, I know one that comes up as well is we talked about the time frame, the typical time frame for migration. But are there ways to speed that up? What’s maybe the approach if customers needed to speed up their migration?
>> CHRIS: Yes, that’s a good question. I think there are two places where you can speed up the migration. One is more on the assessment side. So we have some in-house tools that we use, some accelerators, we call them that can speed up migration assessments by 3x, because we’ve worked with various legacy platforms.
And so I think if you can speed up the process there, that’ll save a lot of time and understanding what is critical to move. Out of that, by understanding better what needs to move, you’re inherently just shortening your development time too. So that’s a nice side effect.
On the development side, you can of course script some of the migration as well. And I say that with an asterisk, I don’t think scripting everything – I’m not promoting that – is a good consideration because, again, we want to reimagine things in Tableau and use all the full capabilities.
And you might approach your old challenge that you had or use case that you had, you might approach it totally differently with Tableau. So why would you script something that took this dashboard here and moved it into a Tableau dashboard here when you’re like, “Wow, maybe this is a great use case for Tableau polls.” So scripting we use mainly for the low-hanging fruit type stuff like grid reports, things like that.
>> Stuart: A question came in. “Do we find many companies that use an ERP application doing this type of move to Tableau reporting?”
>> CHRIS: Yes, yes.
>> Stuart: I would say yes for sure.
>> CHRIS: Yes. I think Stuart, we have a lot of clients with ERP systems that are doing this.
>> Stuart: Yes, definitely. Yes, it’s really common for sure. Yes, all of the above. All of the ERP systems out there, we’ve worked on and helped in some capacity. Typically, the reporting layer inside those ERP systems can be dated or not as flexible. So Tableau has been a great shift for companies. They typically will move that data from ERPs into a data lake and have Tableau extract and run queries against the data lake for reporting. That’s been a successful approach that we’ve seen.
CHRIS: All right.
>> Stuart: Good question.
>> CHRIS: Yes, great questions. Well, if you do have any further questions, everyone, again, please reach out to myself or Stuart. We’d be happy to field any questions that you have about this process. It is a journey. It’s not something you want to just jump into. You want to understand all the different steps that go into something like this. So if you have any questions, please reach out.
With that, we’ll wrap up and we hope to see you all at our next DDC event next month, which is going to be around Tableau Cloud Migration. So please, it’s really cool. Please check that out. So you guys have a great day. Talk to you later.
>> Stuart: Bye everyone.