Fiona (00:09)
You're listening to unDUBBED the podcast that strips the jargon and talks straight about the real world of data. I'm Fi Crocker.
Sarah (00:17)
and I'm Sarah Burnett. And today we're talking about something that strikes fear into even the bravest data leaders, migration.
Yep, that dreaded move to Tableau Cloud.
Fiona (00:29)
We have all been there, change freezes, lost favorites, broken permissions, and a flood of IT tickets. All that chaos comes with replatforming.
Sarah (00:40)
But what if you didn't have to suffer through that anymore?
Fiona (00:45)
Our guest today is someone who's flipped the migration script, Timothy Vermeiren he is an IronViz champion, certified consultant and architect, and the mastermind behind Tabmove, Biztory's turbocharged Tableau Cloud migration engine.
Sarah (01:00)
Tabmove automates up to 90 % of the work permissions, user schedules, even favorites is done. It's the fastest, cleanest, most scalable way to migrate and it's trusted by big names across Europe and the US.
Fiona (01:18)
And the best part, Dub Dub Data has partnered with Biztory to bring TabMove to Australia, New Zealand, or Singapore, we've got you covered with local expertise and hands-on support.
Sarah (01:29)
So if you're staring down a migration and thinking, not again, this episode's your permission to breathe out.
Fiona (01:39)
But before we get started, smash that like, hit subscribe, and let's chat on how to migrate smarter, not harder with Timothy from Biztory
Sarah (01:47)
Timothy, before we dive into Tab Move, could you give us a short snapshot of your journey? Just the key steps that brought you here today.
Timothy (Biztory) (01:58)
Yeah, of course. Thank you, Sarah, Fi So yes, Timothy Vermeeren here. I've been active in professional life for about 12 years and most of that's been filled with Tableau. I've been a BI consultant since the start, specializing quite quickly in Tableau and I've been an analyst for a long time first.
I do have a technical background. So at some point I started shifting towards Tableau server. I think we've all heard the term.
accidental Tableau server admin. I'm not one of them, but I've worked with many of them. I'm being a server consultant, having that technical background has then led up to me becoming more of a data dev, And it refers to people who develop integrations and automations around Tableau as a platform or with data in general,
that's been the journey, towards me as a Biztory consultant, developing a tool to facilitate migrations that is called TabMove.
Fiona (02:56)
Yeah, it's so amazing to have you here today with us. And I just want to acknowledge, it's been an amazing journey for us over the past few months getting to know you and spending more and more time with you. And you're an absolute inspiration to us and many other community members as well. And we can't wait to share with people down under and in New Zealand, the amazing way to
migrate your Tableau server and essentially take all of those nasty headaches away because of the amazing work you've done by shutting yourself away and taking a look behind the scenes at all those different APIs to get everything sorted.
Timothy (Biztory) (03:37)
very excited as well because Biztory, we are active mainly in Europe and we have clients in the US that we help migrate, but it's such an exciting time to finally be able to broaden that horizon. So I'm thankful that we found you, that we found each other and that we're going to be doing this together.
Fiona (03:53)
So let's kick this off, the case for migration. Why do you think so many organizations are making the switch to Tableau Cloud now?
Timothy (Biztory) (04:03)
that's a good question to start with, right? Before you migrate, you have to be convinced that Tableau Cloud is the platform for you.
I think historically Tableau Cloud has not been around as long as servers. So there's a relatively large portion of Tableau clients that will have started on server and haven't had the opportunity to choose between the two originally. if you will, we're kind of dealing with a backlog of Tableau customers that is continually considering and then moving to Tableau Cloud. But what are these factors that drive them, right?
on one hand, the biggest pet peeve of having server is you also have to provision the infrastructure. You're responsible for hosting Tableau Server. You're responsible for maybe bare metal or virtual infrastructure that involves additional IT teams. And it goes without saying an additional cost as well, because you own and operate that infrastructure and the teams that maintain them.
And then you get to look at the rest of the advantages of cloud pull you over the line. many features that Tableau is releasing do come to Tableau Cloud first. And I think that's for a variety of reasons.
the prime example is Pulse.
That's the biggest feature that has been released in my eyes in the past three or four years. And it was very Tableau cloud only initially. And there was a lot of apprehension with that like, ⁓ Pulse looks very good. We want to use that too. And so many server clients were felt a bit abandoned. again, that got me thinking.
There have to be technical reasons and there were these weren't officially revealed, I think, but conversations with Tableau and they've presented at conferences have indeed suggested that running Pulse on server is a very, very difficult thing to do because it's not just another server process. It's a whole other thing on its own that connects to so many other things. that
relies on resources that you might not have locally. but think of how AI operates nowadays and how you can run a local large language model, but you have to set all of that up. I'm thinking there was something similar with Pulse, unrelated to AI, but the fact that it needed resources that online and on the internet and by hosting this as a service,
were trivial to do and for Tableau to maintain and implement, but were very difficult to port and delegate to a server environment. another example is the VizQL data service,
allows you to directly query published data sources on your Tableau environment. And again, has been available for cloud for, close to a year and just got to server last version, also because of implications of how that has to work with other processes and their dependencies,
To summarize what I've been saying until now, we have infrastructure and total cost of ownership, then the nice things to have are the features that you get with cloud. what you also receive is the guarantee that cloud is a platform with the highest possible level of security and compliance.
I am familiar with the fact that in the US, in Europe, in other regions, there are requirements for different industries. And it almost never, there has been an issue in that part of the conversation when I inquire about that with someone I start working with, with a new customer.
they will be like, yes, but they have this certification. Then a final item that may not be so obvious, once you are able to leave the management of your infrastructure of Tableau server behind you, you will benefit from all of the
automatic scaling and other aspects that normally you would have had to manage very closely, but that just come with Tableau Cloud. So do you want to run more backgrounds, extract refreshes at some point? You don't really have to review your background or see if there's enough capacity, et cetera. That is just going to work. Do you want to release a viz that you know is going to have
a high peak in visitors at some point in time, because maybe there's a press release or something, they'll work. The demand will be handled for you because Tableau Cloud is elastic and scales to do that. It's not unlimited. There are resources assigned to each tenant, but these are designed to facilitate any kind of scenario like this without requiring you to review all kinds of specificities or worry about that. So quite a few advantages, if you ask me.
Sarah (08:22)
Yeah, some really great features there, Timothy. I think one of the ones that I coming from a large corporate background, and the big banking environments. would be that I would no longer be 18 months behind the curve ball with versioning. So that's something that would be.
Fiona (08:38)
yeah.
Sarah (08:42)
Very exciting
Fiona (08:44)
That makes me really excited to hear about, and you're lucky as a bank that you were only 18 months behind. When I was at my bank, it was, many, years behind. So I think that's definitely one of the things, to be much closer to the latest releases definitely helps. some of the other things that cross my mind, also having that large corporate background experience.
I find that corporates don't turn on the licensing server or understanding what licensing is actually being used. And so once you get onto cloud, that's natively integrated and you can manage your licenses much more effectively and that way you're not over purchasing You can potentially be spending that money in different areas that's going to help to drive the adoption as well. So you can do...
a lot of things that actually make it much, much more cost effective.
Sarah (09:36)
So Timothy, from your perspective, what are some of the biggest blockers organizations face when they're trying to migrate manually?
Timothy (Biztory) (09:45)
Yes. So we've heard stories about that when companies feel like they're ready for clouds, they encounter another challenge, which is now get from server to cloud. And if I may point out, ⁓ without any judgment, just in a neutral way, almost everyone we talk to asked us, well, how come this is so difficult? It's Tableau to Tableau, right? How can it be?
A thing that we have to think about how we're going to migrate. How can we not just give Tableau our Tableau server and make that Tableau cloud, which, well, it makes me laugh a little bit because obviously that's a perception I understand. it's A to A it's Tableau to Tableau. So indeed why? Of course, there's so many reasons why the main one being, well, you're going from your own Tableau server environment to a multi-tenant environment that is managed differently.
It's essentially the same software running. It's Tableau server on megasteroids, I suppose. And there's many things that none of us know about how all the inner workings of cloud go. the question is valid. But the answer doesn't change. We cannot take a backup and restore it because, you'd restore over other people's sites. We cannot export a site because that doesn't contain all of the information. It's just, the content.
and then still running that process on cloud would be a weird thing to do. So here we are, we do need to consider our options for migrating. And then indeed, the clients immediately consider option number one, which is let's migrate manually, because that's the most obvious way. We just take our content and we put it back there. And maybe we involve our creators and content owners and we delegate so that they put their content there.
And that's it. That should be it. And we're done. It's just pushing the content to cloud. That's the initial idea. And then maybe they start considering the other aspects. Maybe they even start to then see, actually it's a bit more involved than just moving the content. There's a few other things going on that need to be accounted for. And that's another hurdle that they would encounter because I believe it is possible to do this, to delegate to all of your creators to re-upload their
content that is still current, if that's a reasonable amount, but well, you know, as a person, you have to be able to manage your content on server as well. So ideally you haven't proliferated 1,500 workbooks of your own on there, but that's up to you. But then still many other implications like not every workbook that works on server will work on cloud for a variety of reasons. One obvious one is the connectivity to the data used by the workbook or the data source by extension, which could be on premise.
And then that connectivity needs to be accounted for. Like you do not allow any connection from the internet, from cloud services, from Tableau Cloud to your on-premise database. So what do do with that? ⁓ enter Tableau Bridge, which is a new component in the equation. It's not a...
overly complex one, but it is one that you need to give a lot of thought and you need to architect in your new Tableau Cloud deployment. And Tableau Bridge, just for the background, is what's going to facilitate the connection from Tableau Cloud to Tableau, on-premise databases. So it'll sit in your network and it'll broker the connections from cloud to your databases. And because it's internal to your network, it's a secure way to do so because it's managed there and you have full control over
which connections are allowed to come in, which are obviously only the ones from cloud, they're authenticated, et cetera. But that's not something that, is automatically in place when you manually start migrating your stuff. So that's something you would encounter And so aside from connectivity, I mentioned a workbook might not automatically work on Tableau Cloud. There is the...
potential that you're using older versions of Tableau and the workbook itself, but even the extract inside that can have an impact on whether the workbook does or does not work with Tableau Cloud. It's one of the most common things, by the way, that we surface with Tab Move as we...
automatically migrate the content and we get outputs about the success for publishing workbooks, the most common error is an outdated extract, in the TDE format, which is a legacy format and hasn't been supported since, early 24. And so everyone's always surprised like, no, we have so many old extracts. ⁓ we thought that this content was still being used. Turns out it's not the case.
it's an easy way to surface that, like just throw it to cloud. And if it comes back saying it doesn't work, then you have your legacy extract right there. And then almost always it's like, no, of course you're right. No one did look at this because the data is stale. The data is two and a half years old. We never intended to move this. Fine. But again, things that if you migrate manually, you will run into, have to investigate and then have to identify further.
all those things, they come up, they are unexpected, are intricacies, they are technical specificities that may not have been accounted for. So just migrated manually, it's not as easy as it might sound at first.
Fiona (14:50)
Yes, it certainly sounds like there's some tricky gotchas that are involved in that migration and trying to go about it yourself.
Can you talk us through the hidden costs of sticking with legacy on-prem Tableau server setup?
Timothy (Biztory) (15:05)
Yes. So while we were going through the reasons to move to cloud, we already mentioned cost savings that referred to infrastructure as well as the teams managing that infrastructure. So, whereas that's one thing, maybe it's good to point out that there are hidden savings on the other side of the coin, if you will. if you do free up all of that, your infrastructure teams that are probably looking over internal resources can
focus on things that have to be on site and remain there. Like maybe you're not going to move your database to cloud. So that's something that can still be looked at by those teams. But you do also have your actual Tableau server administrators, at least in large enough organizations. And I believe, and I've seen that they can then free up their time and do, in my opinion, more useful things with it.
Not that managing Tableau server is not useful. I've done it for five years and I've enjoyed all of it because it's a challenging thing and motivating thing to do. Like figure out this TSM command and why that doesn't work. Fantastic. But if you can instead pivot and not worry about that core layer and then TSM, et cetera, all working, then you can get closer to the users and see how they are using Tableau server. You can start working on things that I find even more amusing.
building reporting for them, which you can still do on Tableau Cloud. Build a much better utilization report for all of your workbooks and dashboard. Build a much better permission report so you can audit those permissions, things like that. there's enough to do still. As a Tableau Server admin, you have an endless to-do list, and half of that was infrastructure. Well, drop that, and you can start working on the fun half that wasn't prioritized before.
Sarah (16:52)
upgrading those Tableau administrators into doing more fun stuff. like that. Now, Timothy, Tab Move automates 90 % of the migration. What are some of the tasks it handles that teams usually really hate?
Timothy (Biztory) (17:09)
Yes, it automates 90 % of the migration. And the bulk of that, is uploading the content to Tableau Cloud. So at its core, It automates actions that would otherwise be manual and have to be executed by people and does all of that.
It's not just the upload by the way. So just to give you some insight into how it functions, Tableau Server and Tableau Cloud will both be in place by the time we use Tab Move And is going to connect to both and start by downloading the content and the metadata from Tableau Server and then upload and recreate all of that on Tableau Cloud to ideally end up with two identical environments.
And again, the bulk of that is really workbooks, data sources and flows. It's the tangible assets that need to be downloaded and republished or uploaded. And that's a big chunk of the work. It means that all of your creators and content owners don't have to spend a full week reorganizing their content and re-uploading that. I'm saying a full week as an example for an average migration size, but that's just one thing.
What it will also take care of is some basic testing as it uploads that content. For example, it uploads a published data source that connects to Snowflake. It can do that with the credentials that go with it that were embedded on server. And it will test the connectivity from Tableau Clouds, which is important because
At some point, you may have whitelisted some connection into your Snowflake environment or you may have set up some more restrictive rules and you would then find out, okay, we still need to do that for Tableau Cloud. So that's one example of a thing that come up in the initial testing uploads that we do.
Other basic testing that it does is when it uploads a workbook, it's going to look for the most popular view based on server statistics in that workbook. And it's going to download the image for that dashboard, which is a very simple thing to do. But as an important if the dashboard comes out blank, we can detect that. Then there is a problem. Then maybe it's the connectivity through the data source of the workbook, or it's another problem with compatibility
inherent to Tab Move is these basic tests. So that's...
Another thing that's automated that otherwise you would be finding yourself, coming through workbooks and opening every dashboard, And we can get into more intricate things as well, you normally wouldn't think of as you start migrating manually.
A prime example is you may have URLs in use in your dashboard, URL actions, URLs that point to documentation in the text field, which is all very good practices. But if they point to Tableau Server, they will all be outdated because you will probably have a different URL that is a Tableau Cloud one than you did have with Server. So what do do with that? Well,
If you were migrating manually, you would open a workbook in desktop, look for all those references, and then change those. Or if you're a very technical person, you would say, I'm going to download all my workbooks, unzip all of them, and write a script that goes through them and changes them.
So you could do that for yourself, but we've already built that. So as a workbook is downloaded and then re-uploaded, Tab Move will scan it for references to the old server, even sites that it's on and then change all of those so that URL actions between workbooks, for example, would continue working. Not something you would think of, I believe. In fact, not something I thought of because it was only at the third migration we did that someone was like, wait a minute, my URL actions are broken. thought, ⁓
Fiona (20:32)
Mm.
Timothy (Biztory) (20:41)
Okay, we did not account for that. And actually to be very transparent in the first, don't know, 20 migrations that move grow very organically like this. Only when someone complained about something, we would realize, right, we could account for that as well. And then features like that were being built. another thing that can be automated and that came from a request at some point is the ability to merge.
Fiona (20:41)
You
Timothy (Biztory) (21:05)
server sites into fewer sites on Tableau Cloud. So the background here is on server, you may be used to having unlimited sites as you do, because you can create as many as you want and you can use that for any logical grouping or siloing that you want. But on Tableau Cloud, you're typically
not going to have 70 sites like you had for your 70 teams on Tableau Server. So a question that has started coming up at some point during the migrations we delivered was, well, we have too many sites So what do we do? We were already convinced. We already bought the licenses, but now we have to make it work. Another feature request.
the ability to translate sites into top level projects. We do that by taking the site, their users, the groups that are on there and evaluating what that would be if they were a project and how the permissions would reflect the exact same access for the users that are going share a site. At the end of the day, if you do use this functionality, that means that someone who had access to
Let's say two sites on Tableau server will end up seeing two top level projects on Tableau cloud. And the permissions should be reflecting their capabilities one to one as they were on server through the help of some additional groups that are created, at this point, this does sound very intricate. It is. These are, these are things that we've put a lot of time and effort in because those are common questions with difficult answers, but they're reproducible.
So we invested the time in automating that kind of stuff as well that I think otherwise might give the manual migrators a bit of a headache.
Sarah (22:44)
And I don't know about you, Fi but when Timothy mentioned groups and permissions, I was thinking back to my corporate life and just going, my gosh, the thought of having to migrate people's permissioning really sends shivers down my spine. Is that something that Tab Move can automate?
Fiona (22:50)
Ha.
Timothy (Biztory) (23:06)
It can, and I'll admit it was not the most fun part to develop because it can be incredibly complicated. You have your, locked to projects permissions, but then you have the customizable ones. Then you have your groups and your users and then you have all the capabilities. I think every person who has used Tableau can picture the little screen when you show the permissions and how many values there can be and how they can differ. Turns out the Tableau REST API.
is actually quite good at doing that. So I did mention it wasn't the most fun part, but it's doable. Someone could automate this on their own in a few days if they have some development experience. But there were exceptions to be accounted for. wait, how did you apply permissions there? That's a really weird way to do it. And I don't think we've accounted for that. It's very difficult, but...
It's totally doable and automatable. So yes, we did. We had to, obviously, because if we Tab Move'd all the content, but then said, hey, bye, have fun doing your permissions, then I don't think we would have really, we would not have proven them a service.
Fiona (24:10)
there's so much to unpack in everything that you're saying. first up, it's amazing that you've had an opportunity to prove this out so many times with so many different clients and continue to develop and build on what the art of the possible is within the process. I see it as you're almost like a...
a dog with a bone, ⁓ there's another bone that I need, you know, like, here's another problem that I need fixing or migrating in there. How many clients is it that you've actually migrated so far?
Timothy (Biztory) (24:44)
55 since last week. We have a dashboard that's automatically posted to our Slack and tells us, ⁓ this is the counter
Fiona (24:51)
so totally data driven. And look, you're right. Like there are other ways that people could look at automating some of these processes with the REST API, the migration SDK perhaps, but they will still have to do everything from scratch. And they would have to make all those same discoveries that you've made by proving it out over so many clients as well. when you automate up to
90 % of the migration. What's the 10 % that you don't automate?
Timothy (Biztory) (25:18)
There are things that are even more difficult to migrate than permissions. some things are new and may or may not be facilitated by the REST API yet. I'm thinking about virtual connections. It's a relatively new feature that we had not developed until a certain point in time because it was such a new feature that it was unlikely
that a server client would be using them very extensively and would require us to move them as well. So we'd often be like, you know, the trade-off is we need to spend a few weeks developing that, whereas we know the audience for this is going be relatively limited. So we make decisions about migrating things or not migrating things in that way.
Fiona (25:56)
Hmm.
Timothy (Biztory) (26:01)
Virtual connections we have implemented by now, but it's actually not possible to fully migrate them. So it's an example of the second case as well. There is a very, very specific...
use of virtual connections. depending on whether you're using extracts or not and role level policies or not and another thing or not. ⁓ Then funny thing is you would only be able to republish that virtual connection to cloud as a draft. ⁓
we estimate 90 % just to say, there is going to be some stuff. Comments as well, by the way, not that many people care about migrating to us, but we can objectively not migrate them.
Fiona (26:42)
you're so transparent about the things that really aren't included I believe there are also other things in a migration that you could never automate, like understanding
what is going to be migrated or doing that project planning along the way. Every project that comes along is going to have an aspect of things that aren't actually automated.
Timothy (Biztory) (27:06)
That's actually true. Yeah. And I haven't talked about the project aspect of the migration Tab Move refers to the tool as well as the framework and the project delivery. the actual.
running of Tab Move, the downloading and the uploading is, is but a fraction of the work that we do with the clients. We do have to spend a lot of time understanding the environment and helping them understand what will be their environment on cloud and whether changes could be made to improve. we work with clients that have used Tableau for over a decade and they are very well aware that, well, we have a lot of legacy stuff on here and a project structure and even governance that we started with originally.
is not what we would want to use today if we knew everything we knew now, it's a time to ⁓ pause and to reflect and to say, well, effectively, yes, we're going to change the project structure. We're going to change governance. We're not going to let people do this, but we are going to let themselves serve that aspect. And then you're right in saying that all of that obviously cannot be automated. It's all work that will have to be done, but that we're more than happy to facilitate altogether.
Sarah (28:11)
And you spoke there about, how long they've been with Tableau looking back through my career, there's some that I would definitely not want to just lift and shift, although you can do that with 90%, we'd really want to go through a proper change management governance process to figure out, what we can
get rid of in terms of legacy and tidy up along the way. Now, additional to TabMove, there's also the Tableau's CMT, so the Content Migration Tool. How does that compare to TabMove?
Timothy (Biztory) (28:45)
Excellent and very common question as you would expect because well, if we take a step back, we just mentioned ⁓ people are going to start looking into their options for migrating, option one manual, option two, I'm going to Google and I'm going to see, Tableau has a tool for this. It's called the content migration tool and it's definitely a valid candidate. ⁓ But there are two caveats, with using the CMT, which are A, it's not been designed for migrations per se.
It's been designed for copying or moving content, but in a process related to how you develop your dashboard, maybe with your test and production environments and things like that. So those things it does very well. But that's just a transfer between environments, not a migration from server to cloud. And then B, because it's designed to do that, whereas we were able to boast these 90 % automated, it has not actually been designed to move all the other stuff.
Like it wouldn't do your users in groups. It wouldn't do your data alerts on top of your workbooks, So because it's so content oriented, it will do that extremely well. But if you choose that option, you need to account for all the stuff around it. And there may be more than you think like ⁓ users, groups, schedules, projects.
That's all the stuff you need to put in place before you get to the content. We have this hierarchy we use with Tab Move There is one right order, to migrate And that involves doing those first because they are dependencies of the workbooks and data sources. You need to have those in place. You need your project to put a workbook in, But then there's all the rest coming after that.
Extract Refreshes, Subscriptions, Data Alerts, Collections, Favorites, Custom Views. I'm probably missing a few because there's too many, but all of those things are also at your responsibility if you use the CMT, because again, it's content-oriented and it's stuff that we've put the time into to automate.
Sarah (30:43)
And that's a lot of fiddly stuff.
Timothy (Biztory) (30:47)
It is, most definitely. ⁓ We mentioned a few ⁓ favorites. They're actually doable because there are REST API endpoints for them, but there are some challenges to these as well. ⁓ You cannot get all the favorites on a Tableau site. In fact, you have to get the favorites per user.
So if you have 50,000 users, that's going to be 50,000 API calls you need to do. Not enormously difficult to automate, but also something you need to account for in how you're going to migrate that stuff when, because 50,000 API calls of one second still take a lot of time. So there's all these intricacies. We've developed very recently the ability to do that in parallel with Tab Move for example. So you could do that eight at a time and then move a bit faster,
It might seem simple, like I just need to move my data alerts, but it's actually much more complicated. If you don't mind me elaborating on one more thing there, because I'm going to admit I'm pretty proud of that. We made the choice to also use unsupported APIs of Tableau to facilitate the migration of as much as possible. And these data alerts are specifically one example of that.
Fiona (31:41)
Mm-hmm.
Timothy (Biztory) (31:55)
there were no support at REST API endpoints for data alerts. I don't know if there are any today. I don't think you can do a full migration of a data alert. You can get some information, but you cannot recreate it on the other side. So what we decided to do is let's investigate why Tableau, when you click things in your browser, can create that data alert because...
Obviously there is a way to do this. Your browser is communicating with Tableau server or with Tableau cloud and it's exchanging information that results in that data alert being created. So it has to be possible. We have to be able to recreate those steps and automate them. And that's when you land on the viz portal API. I think many people who have worked with Tableau for a while may be familiar with it. The viz portal API is sometimes referred to as the undocumented API.
or the native API because it's what your browser uses to communicate with Tableau server. It's different from the REST API, which is publicly documented and intended to build integrations and automations. And it's very well prepared for that. It has been designed to be resilient and to accept any kind of input, But it has limited capabilities. So back to the Viz Portal API, it's for internal use only.
And I think that's enough warning, right? It's like, we're not going to help you with it. It's not documented. It can break, et cetera. But so again, we made that choice to inspect that and see, OK, we can actually authenticate as the user in a viz portal session, not just REST API, through some magic that we had to figure out. But that opens up a whole world of possibilities, because then all we had to do was listen in on the browser's conversation with Tableau server.
Fiona (33:27)
You
Timothy (Biztory) (33:34)
look at which endpoints it would address, how it would talk, and then we would just take that information and recreate that. It's a big risk as well because, again, internal, undocumented ⁓ and prone to breaking. So we're making the choice here too to say, well, if Tableau changes something, it's on us to fix that as soon as possible to continue supporting that because if in Tableau Clouds 2026.1,
they change how data alerts are created through the viz portal API, we're going have to adjust our code to do that as well. But that was a trade off we very actively chose to make so that we can cover those 90 or let's maybe say 99 % of things that can be migrated. That was a very conscious decision to do that,
Fiona (34:17)
you
two months ago, we had Matthew Miller from Tableau on the podcast. So he's recently been promoted to VP of product management and he was gushing about how amazing of a job that you've done in terms of going into those undocumented APIs to make the magic happen and to really make this migration so seamless for people. ⁓
removing so much risk for them as well.
Timothy (Biztory) (34:52)
I would be remiss if I didn't admit that one of the drivers behind this was effectively that same person. ⁓ He was at Biztory for a while and he then moved to Salesforce, Tableau. And he definitely planted seeds like, yeah, you're going to want to do this and this maybe in case you want to support that full array of capabilities. And it's like, damn, he's right.
I wish I hadn't heard this. I wish we could just say it's not possible, unfortunately, well, no, of course, fortunately, ⁓ he drove us to do that extra mile and then now, well, Tab Move having the capabilities to have today.
Fiona (35:29)
Yeah, so I think there must be so many amazing customer stories out there. We did a little bit of research and we found we hunted down the Veygo case study. So can you tell us how did a six week migration get cut down to just a few days?
Timothy (Biztory) (35:46)
Yes. So Veygo is a ⁓ UK client that we worked with and the six weeks you're referring to were, the estimates that I ⁓ believe Salesforce or Tableau Professional Services would come up with because they do help you migrate as well, but they use the manpower that they have to facilitate that. And then it's six weeks.
So we use that as a baseline sometimes when we come in to compare and well, it's bit of an unfair comparison because it's apples and oranges, but well, still we cut it down to a few days. That's the essence of the story. So how did that happen? Well, there is obviously all of the automation. ⁓ So being able to get the content and upload it automatically frees up all of our time to then also guide that customer from
⁓ server to cloud because there's all this overhead as well, right? You're introducing these people to a new platform. And if you were doing all of that manually, then the focus would be on the manual work for that period of time. And only then afterwards would you be able to say like, look, here's your content. Does it look right? wait, no, we have to go back and do something else,
We automate but we don't migrate everything in one go. We usually do that incrementally and then have people review content as we do that. So for Veygo that would have been one, we upload a small amount of content, but representative content so that they can start checking that. It's their...
most viewed dashboards, it's dashboards and workbooks that connect to specific data sources that have to be checked. And so that's our starting point. In the next day, we'll just move a bit more of that same stuff. And then maybe in day three and four, we'll look at migrating the bulk, the rest that remains there. And that's automated approach that's incremental, facilitates that to happen much faster to also
⁓ You would say fail faster because we would find out about things not working initially, be able to fix that so that the next days can still continue, as opposed to doing that in a very monotonous, serial way of uploading workbook after workbook manually. so the automation and then the incremental aspect, there they're able to bring down migration time quite significantly.
Fiona (38:03)
Yeah, that's amazing. I mean, it sounds like this process could really make a Tableau administrator or platform owner just look like an absolute rock star because they're making sure that this transformation from on-prem into the cloud is a seamless and easy for everyone, including themselves as well, and no doubt saving on costs.
Timothy (Biztory) (38:29)
Yeah, agreed. We've had a few of those Tableau administrators we worked with be very thankful, obviously, at the end of the migration. ⁓ They are always the point of contact of their whole audience, of all of their creators. And they are the ones being looked at when the word migration is being dropped. So that's a bit daunting.
And imagine, yes, that plan starts getting in motion and ⁓ the admins are going to be responsible for making sure the content gets there. We become part of their team. We do all of that together with them. it is noticeable, like, when you see people just.
sign into Cloud and they're like, yeah, effectively my content is all here. How did you do that? Because creators are well aware of the difficulties very often, like of what it would take to move all that stuff. Then the admins are like, yeah, we did this together with them and we had a good time doing it. Ideally, I suppose usually it is the case. There are challenges, obviously, technicalities to overcome. But at the end of the day, yeah, they're usually quite pleased with the teamwork we can put up to do this.
Fiona (39:22)
Okay.
Sarah (39:35)
not only, the reduction in potential cost and time spent with admin, but also that change freeze time as well, where new Tableau development wouldn't be able to happen. If you're talking about a six plus week migration, right, you're going to have to have a freeze where you're not going to be able to serve your business users as quickly as you would like to. so many additional benefits doing a fast.
migration.
Timothy (Biztory) (40:03)
You're right. I had not mentioned it yet, but it is often a thing that comes up and a freeze in IT terms in case anyone's not familiar with it, but you described it as, don't change anything. Like we're going to be moving your content from that day to that date, but anything you do will be lost. So just don't touch it. And it's correct that
This is very often a bit of a negotiation and a big item on the agenda as well. Like this has to be reduced as much as possible. Six weeks, unacceptable. Other customers we talked to were considering three months, like because of how they had the impression that a manual migration would take that amount of time. Correct impression, obviously, if it is manual, but then being able to reduce that is a very tangible...
way to reduce friction with the business, obviously, because the business is impacted. They do not stand still for three months or six weeks. They do have to adapt their business logic in their dashboard. They do have to produce new content to answer new questions. And reducing that may at first seem just like a different timeline for the project, but has a very real impact on how people use Tableau.
Sarah (41:16)
Hmm, really interesting. Now let's discuss outcomes. How do customers describe the impact once Tab Move is all done and dusted?
Timothy (Biztory) (41:27)
So for those Tableau admins, a relief mostly. again, I would be lying if I didn't admit for us as well, because migrations, even when we automate them and even when you're not on 55 of them, they're still a bit scary. you can use Tableau.
with so many different types of data sources in so many different types of ways, you can build so many different types of analysis dashboards things. And then you can use that in so many different places embedded wherever you want that no migration is ever the same as another one we've done before. And there's always something new. And very often it's like, how is this going turn out
why are they using that authentication type with that data source that has to use Bridge? How is that going to work out? It's always still a bit scary. So everyone's very relieved at some point in time. And I'm really being quite honest here because even when we start the work, there's still a bit of tension like, these guys are promising a lot. Are they going to be able to deliver that?
And this is something that kind of drives me as well. you know, it would be too simple if we figured it all out and we would just click start and it would just do it. And that's every migration ever. Now it's a lot of fun that there are still challenges coming up that we need to address and sometimes need to patch as well. But that's what we do. So that's why relief is prevalent throughout the teams there. ⁓ Then when it's done.
they get the opportunity to start looking at all of the new and shiny things that they have on Tableau Cloud. So that's often something we notice as well. When the migration is finished, it's only a matter of hours or days even before questions start coming in like, ⁓ now we have access to this feature and can you explain us pulse, So things come in really quickly. Obviously, we're a bit more mature and now we try to plan for that.
we will have informed people about what's to come, especially in enterprise environments. This is an absolute requirement. Like they need to know like pixel per pixel, what the new environment is going to be like, because otherwise it's going to throw people off. So there's a lot of preparation going on there, but finally getting access to those things it's an entertaining moment as well. Like seeing people discover new, new possibilities, start thinking about how they'll use them. That's a quite an aha moment as well.
Fiona (43:56)
any project though that a good consultant goes into, there's always relief when it's actually delivered and signed off and everyone's happy because that's the goal that we all want is we want to go in, we want to solve some problems, we want to do it in an elegant way and we really want to knock the socks off and make someone super happy about what they've had delivered. I love the honesty.
in that and I think that anyone would feel the same.
I've heard that you have a three-step delivery model. So what happens after someone raises their hand and says, we want to migrate?
Timothy (Biztory) (44:36)
it starts with the scoping because it is a project and we need to scope what we're going be delivering and how much we're going be migrating ⁓ because we see environments that are.
150 workbooks for 20 total users and 5 gigabytes in total. But we see environments that are 4 terabytes and 10,000 workbooks for 120,000 users. And so we need to know what we're going to be dealing with before we can do anything else. So the key starting point is that scoping that's facilitated through a workbook we provide the customer. It plugs into their Tableau server.
and it surfaces information from the Tableau repository, the database, and it tells us about the volumes and the counts of everything we're going to be migrating. Again, the numbers I mentioned, like 500 workbooks, 20,000 users, 500 gigabytes, all of that is being surfaced. And that's the material we need for our scoping. But it's not everything because volume is one thing and that's going to be
a very important factor to decide how big of a project this is. But there's a lot of things to be said about complexity as well. If a customer has 15,000 workbooks, but they all connect to Snowflake, which is a cloud-based database, and you just can connect directly from Tableau Cloud, that's very simple. We're just going be downloading and uploading stuff and it's just going work. But if they have...
500 workbooks and they connect to 30 different types of data sources of which 25 are on-premise and then there's files on network shares? ⁓ well, it's going work, but it's going require a bit more effort from our end and them together to figure out, ⁓ can we set a bridge so that we can talk to those files on that network share and which type of bridges does it have to be?
are going host it on Windows or Linux, Suddenly, a whole additional component gets added to the project, which we surface during that scoping. We use that workbook, but obviously it's also a conversation, right? So the workbook surfaces summary and basic information like, ⁓ we see you're using SQL Server here. Can you tell us a bit more about that? And we have that conversation to discover, for example,
are you using native authentication for SQL Server or Windows authentication because that's going be a difference as well. And this is going change the size of the project at the end of the day. That's pretty detailed already, but we're starting to gather information that's going to impact our delivery already anyway. yes, step one, scoping call. We have a ton of information. We negotiate with the client and at some point we might ⁓ get to an agreement, but... ⁓
Even before that, we will also commit to going to step two if more convincing is required. And I'm saying that again, I'm going to be maybe a bit too honest here, but maybe we need to be convinced as well. Like it's not just the client needing to be convinced about that move, but we might also want to get a bit closer to the whole thing and to then be able to say, okay, yes, this is as expected. This is, you know, there are no surprises here.
And what I'm referring to is step two is an actual workshop where we come in for a day or two, or if it's a bigger environment, maybe three or four. And we put that move in place and we do a micro migration, if you will. We connect everything, we set everything up, we configure everything, and we just showcase that some of that works. Some of that, because we cannot cover everything if it's a huge environment in a matter of three days, but we can prove, for example, that we can take
that SQL server, Windows authentication workbook and move that and have it work on Tableau Cloud. And being able to prove that that specific technical thing that may have been scaring everyone and then, know, may have been creating a lot of uncertainty, proving that that works goes a long way in both directions. Like we'll feel confident about the offer we're putting on the table and they'll feel confident that we're able to deliver. So.
I've often had a lot of fun in those shorter workshops as well. Same reason as before, like there's a bit of tension, like, hmm, they, these guys, they come in here and they, they're saying that they're going to be able to do this. well, hopefully then we can, we can prove that that's true. but it's, it's a very fun challenge for a few days. Like it's very motivated, motivating and driving.
So that's step two. then assuming that goes well, which is usually the case, we've never had, a client do the workshop and then step back, step back out and say, nah, this is not going work. But that then leads up to step three, which is the delivery. And that is, I've used the term a few times, but the bulk of the work. It's where we're going effectively handle all of the content.
And we may do that in a single migration if the amount of content is reasonable. But depending on that volume, but also depending on the client's desires, like practical aspects or timelines or whatever, we can choose to chop that up in different batches as well.
If it's a very large amount of content, we know that the single action of uploading that content is going to take two days. That's totally possible because it's a lot of gigabytes that we're pushing to Tableau Cloud. Well, then if two days is too much and they want a more controllable and segmentable approach, we will say we can do four uploads of half a day or something like that. And then we can always pause and review and. ⁓
process the feedback we get and then start the next batch once we've completed that. We're quite flexible there. We've done migrations where we did migrate a huge amount in one upload.
So that's phase three.
Sarah (50:33)
Okay.
Timothy (Biztory) (50:34)
But it
could be preceded by the quiz, which I haven't often considered part of the project. It's more of the lead generator, but of course it can be crucial in already evaluating.
Fiona (50:36)
Yes.
Yes.
Sarah (50:45)
really well thought out the process there, Timothy. I really like how you start out with the one hour scoping session and then move through to the one day workshop prior to the delivery, which like you said, is a bulk of the work do you offer ongoing support?
Timothy (Biztory) (51:01)
We do, yeah. It goes without saying that if you've migrated a large amount of content for a large amount of users, ⁓ they'll start exploring that immediately, but they might still encounter things a week or a few weeks after the migration has been done. Again, part of the process is we don't expect everyone to check everything,
People want guarantees, they need to be built in. And we do offer support, which is often up for conversation as well. Like we will say, it was a large migration. So usually within the next 30 days, you should be able to have uncovered everything that might, might still require some attention.
Those are actually minor details very often, like it's someone trying something new and then the results aren't as expected. It's an old workbook that isn't viewed very often, then just comes up and like, yeah, the owner didn't actually check it because it was not that important. But there does need to be some, ongoing guidance at the end of the process. It's not like we close the door and say, bye, thank you. That would be impolite, I think.
Fiona (52:03)
Timothy, if you had 30 seconds to convince a hesitant CTO, what's your pitch for Tab Move?
Timothy (Biztory) (52:12)
Okay, so dear CTO, you have concluded that Tableau Cloud is the right platform for you. So I think the challenge you're facing is moving from Tableau Server to Tableau Cloud. And as a CTO, everyone's going to be looking to you and is going to judge you based on the success of that migration. So do you want to do that as a one-off and try and figure it out yourself or...
Would you like us to come and help you with Tab Move? We've done only 55 of them, but they've always been fully automated. They've been successful and we give you the guarantee with a fixed pricing that we will deliver. So we're going to come up with an agreement and our take is that we're only going to stop when we fully migrated all the content that you need.
Maybe that can help you convince everyone that you were the one driving that successful migration.
Fiona (53:04)
pretty amazing and not many organizations will offer a fixed price on their delivery of things, in particular when something might be super large or complex. As you say, there's lots of different forks in the road as you've experienced with all of the different migrations. so having a CTO be able to say, this is how much it's going to cost us to get from the server into the cloud is an absolutely amazing opportunity.
And I've seen the prices and they are really sharp as well. I couldn't quite believe that that's what they were being offered for.
Timothy (Biztory) (53:44)
I suppose we just, you know, we know we can deliver and we can deliver relatively fast. very often we're able to deliver without many problems and within that timeframe. So we stand behind our offering there.
Sarah (53:58)
and constantly refining the tool as well to improve.
Timothy (Biztory) (54:02)
We are, yeah. I personally find that one of the more fun aspects. So I've delivered out of those 55, a number of migrations. A number has been done by the rest of the team. I'm very involved in the development and I'm secretly a bit happy when they come up and say, hey, this isn't working yet. I'm like, ooh, yeah, some new puzzle to figure out. And they still come up. They're smaller and smaller details or they're big new features, but yeah, there's always something we can do to improve too.
Fiona (54:30)
Well, at DubDubData, we're really excited to be able to bring TabMove to the region. We actually have a short quiz that Tableau administrators or platform owners can take and scope out their size and give a bit of an estimation of how much effort it may take
so if you're excited to learn what the price might be for you to go from server to cloud, hit up the show notes and take the quiz. And then we can look at booking in a one hour scoping session to look at your particular environment as well.
Massive thanks to Timothy for joining us and for showing us that Tableau migrations don't have to be slow, expensive or risky.
Sarah (55:15)
So if you're still stuck in server purgatory, this is your sign. Hit tab move, book the free discovery call and start building in the cloud tomorrow, not next quarter.
Fiona (55:29)
Don't forget to like and subscribe and share this episode with your favorite data nerd or overworked admin. You'll be their hero. And thank you so much, Timothy, for joining us today. It's been absolutely amazing.
Timothy (Biztory) (55:42)
Thank you. It has been a pleasure for me as well.
Sarah (55:45)
So until next time, stay curious, stay cloud ready and stay undubbed.
