Simplify Your Migration to Tableau
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, Patrick Landis, Lead Solution Architect, and Client Success Manager, Stuart Tinsley, recently held a meetup titled “Simplify Your Migration to Tableau Cloud” to showcase how organizations how to perform a successful migration from Tableau Servers to Tableau Cloud.
Moving Tableau from on-prem to the Cloud can be challenging. There are many variables to consider, and having a well-thought-out plan is key to the success of the migration project.
Learn how we successfully leveraged a tried and true process to migrate Tableau to the Cloud for multiple clients. The team shares tips for an effective strategic planning process, a step-by-step approach to migrating data sources, dashboards, and extract refreshes, as well as shared client success stories.
This article includes a recording, transcript, and written overview of the Simplify Your Migration to Tableau Cloud presentation.
The event focused on providing attendees with knowledge of Tableau’s best deployment, training, and adoption practices. The session included live demos of Tableau in action, tailored to executive reporting, operations, and sales, to show attendees what’s possible with the software.
Additionally, the session provided insights on how to quickly implement powerful features that can be rolled out to teams.
The session follows this outline.
Simplify Your Migration to Tableau Cloud
- Tableau Cloud Overview: Architect Options and Tableau Bridge
- Creating a Migration Plan
- The Migration Process: Content Migration Tool
- Best Practices and Recommendations
Tableau Cloud Overview
What is Tableau Cloud
Tableau Cloud is a fully hosted cloud-based Software-as-a-Service (SaaS) solution provided by Tableau. Essentially, it can be considered a hosted version of Tableau Server. The major advantage of Tableau Cloud lies in its cloud-based nature, which eliminates the need for server maintenance, administration, and manual upgrades. These tasks are handled automatically without requiring any interaction from the user’s side.
Initially, the product was known as Tableau Online, but it has now been rebranded as Tableau Cloud to align with other cloud options available within the Salesforce ecosystem. In essence, Tableau Cloud and Tableau Online are one and the same; it’s just a change in name to reflect the broader Salesforce cloud offerings.
Tableau Cloud vs. Tableau Server
Tableau Cloud is a fully hosted solution that does not require extensive administration. The advantage of Tableau Cloud lies in its simplicity and convenience, as it eliminates the need for manual setup and management tasks.
In certain cases, organizations may have specific requirements, often related to legal or compliance issues, that necessitate tighter control over settings and governance. In such instances, staying on Tableau Server might be the preferred option.
However, it is worth noting that Tableau Cloud is certified for various compliance standards, including SOX (Sarbanes-Oxley Act) and HIPAA (Health Insurance Portability and Accountability Act). This means that even organizations with stringent compliance needs can confidently transition to Tableau Cloud.
While Tableau Server remains a viable choice for organizations with specific requirements, Tableau Cloud offers a compelling solution that enables streamlined operations, automatic upgrades, and hassle-free maintenance for most organizations, even those with stringent compliance needs.
Tableau Cloud Key Benefits
One of the major advantages is the reduced administration workload. With Tableau Cloud, there is no need to manage Tableau Servers, whether it involves dealing with Linux environments or installing Windows patches. This streamlined approach eliminates the administrative tasks associated with server management.
Tableau Cloud offers improved performance and scalability. As Tableau manages these servers, they have optimized them to scale effectively and fine-tuned the product accordingly. Consequently, users can expect better overall performance when utilizing Tableau Cloud.
Additionally, automatic upgrades are a significant advantage. Tableau Cloud is promptly updated whenever new features or version releases become available. This ensures that users have access to the latest features and enhancements even before they are released to the general public.
Tableau Server users often struggle to keep up with frequent upgrades. Some users only perform upgrades once a year, resulting in them falling behind on the latest features and advancements. This highlights the benefit of Tableau Cloud, which guarantees automatic upgrades, enabling users to stay up-to-date with the latest and most exciting functionalities.
Another aspect that should not be overlooked is the simplified license management offered by Tableau Cloud. With this solution, there is no need to manually enter or share license keys via email. The entire license management process is seamlessly handled within the Tableau Cloud environment. Consequently, organizations can reduce their IT resources dedicated to license management, leading to a lower total cost of ownership (TCO).
Tableau Cloud Architecture Options
The architecture of Tableau Cloud varies depending on how data is connected, and this aspect should be considered in migration planning. There are two main types of data sources involved: cloud-based data sources and internal data sources.
Cloud-based data sources are located in the cloud, external to the company’s network, and outside the firewall. These sources are typically configured in the public cloud. Examples of cloud-based data sources include Snowflake, Redshift, Databricks, Salesforce, and Google Drive. While there may be some gray areas where these sources may technically fall within the network configuration, they are generally accessible from the outside world.
On the other hand, internal data sources are situated on the network and behind the company’s firewall. These sources can include SQL Server, Postgres, Oracle, Hortonworks, and others. Internal data sources are accessible only within the organization’s network. The specific data source being connected to will determine the migration strategy.
For those utilizing internal data sources, an additional component called Tableau Bridge is required. Tableau Bridge is a client application that facilitates the connection to internal data sources. It acts as a bridge between the Tableau Cloud environment and the internal network, enabling seamless access to internal data sources.
Tableau Bridge is a lightweight application client that plays a crucial role in connecting Tableau Cloud with internal data sources. The installation process for Tableau Bridge is quick, taking approximately a minute. It is installed on a server within the organization’s firewall.
The purpose of Tableau Bridge is to act as a proxy, facilitating communication and relaying queries and data requests between the internal network and the connected data sources, ultimately passing the retrieved data back to Tableau Cloud. This lightweight proxy solution allows Tableau Cloud to access internal data sources that are behind the firewall. It is a commonly used practice by many organizations.
Tableau Bridge is specifically required when connecting to internal data sources. In contrast, when connecting to external data sources like Snowflake or Databricks, Tableau Cloud can establish a direct connection, and there is no need for Tableau Bridge. In such cases, organizations can whitelist Tableau Cloud and establish the connection directly.
Cloud Data Architecture
When considering the data architecture for Tableau Cloud, there are different scenarios depending on the type of data sources being connected. If you are connecting to cloud-based data sources, such as Snowflake, Databricks, or Google Drive, the connection is established directly from Tableau Cloud to these sources. It allows for seamless connectivity and data retrieval.
For security purposes, it is advisable to whitelist specific IP addresses associated with Tableau Cloud within the respective cloud data sources. For instance, in Snowflake, you can whitelist the Tableau Cloud IP address, ensuring that only Tableau Cloud can securely connect to your Snowflake instance or any other cloud-based data source you are utilizing.
This type of data architecture represents the simplest and most straightforward migration scenario. If you are transitioning from Tableau Server and your data sources are already in the cloud, moving to Tableau Cloud becomes relatively easy and requires minimal effort. It is considered an ideal scenario due to its simplicity and efficiency in migration.
Internal Data Architecture
When connecting to internal data sources, the data architecture becomes more complex than cloud-based data sources. In this scenario, the implementation of Tableau Bridge is necessary to facilitate communication between the internal data sources and Tableau Cloud. Tableau Bridge acts as a proxy, relaying data and queries between these sources.
Currently, Tableau Bridge is only supported on the Windows operating system. However, it is worth noting that Linux support is expected to be available soon. This information is important to consider, especially when discussing the migration plans with the IT department.
The implementation of Tableau Bridge introduces a server that needs to be managed. The requirements for Tableau Bridge are typically less demanding in terms of size, memory, and processing power compared to a full Tableau Server deployment. Additionally, the maintenance overhead and administration costs associated with Tableau Bridge are minimal compared to those of Tableau Server.
Although there is still a server to manage in the form of Tableau Bridge, the overall burden and administration requirements are significantly reduced. The implementation of Tableau Bridge provides an efficient means of connecting internal data sources to Tableau Cloud, enabling organizations to leverage the benefits of cloud-based analytics with minimal additional server management.
Hybrid Data Architecture
Another option that organizations often encounter is a hybrid approach, which involves a combination of cloud data sources and internal data sources. This scenario arises when a large organization utilizes both types of data sources simultaneously. In such cases, Tableau Bridge is still required to connect the internal data sources to Tableau Cloud. This allows for seamless communication and data exchange between the two environments.
>> STUART TINSLEY: In today’s topic, we’ll be talking about how you can simplify your migration to Tableau Cloud.
Just a reminder, our Data Driven Community, we want to bring relevant content to you every month.
Chris, how many sessions is this for us today?
>> CHRIS MONAHON: This is number four, I believe.
>> STUART: Number four. Awesome. Middle of the month, every month, we will be bringing new and relevant data topics, mostly revolving around Tableau, but just generally different topics around data. We’re really excited for today’s session.
Today’s agenda will look like this. We’ll talk about the meeting format, upcoming events that we have.
Today, our featured speakers are going to range from Chris Monahon, our president at XeoMatrix, a 20-year veteran in the analytics and data space, with myself. I’ll be your emcee today. I’m Stuart Tinsley. I’ve been in Tableau right about 10 years. I used to work for Tableau back in the day.
We also have a special guest, Patrick Landis [phonetic]. He’s our lead solution architect. He’s got many, many years in the data space, a very technical individuals. I’m so excited for him to be joining us today.
In our presentation, we’re going to be talking about how to simplify your migration to Tableau Cloud. And like all of our sessions, we’ll end with a Q&A and a panel of discussion, so you can ask any questions that you have.
Just a reminder, this is a Zoom meeting, so please observe customary zoom webinar etiquette. We would love for you to participate; and if you want, please make comments and send questions in the chat window. We will address any and all questions at the end. We’ll have 10 to 15 minutes for Q&A at the end of our presentation. And then of course, we will record and send out the session for today and all future sessions that we have, and we’ll also have a short follow-up survey.
We always want to improve our events, so any feedback that you have is always welcome. It’s something that we take very seriously into heart.
For our upcoming events, we are taking a summer break for July. Most of us are probably taking summer vacations, so we will be off in July. We will not have any events. But the next event that we will hold will be on August 9th. We’re going to be talking about data lakes and data pipelines. This will be a really good content here to talk about how you can source data within your organization and get that to the clouds. How you can centralize, maybe, multiple data sources, make it easier for analytics. So that’s our next session on August 9th.
Following that, September 13th, we will have other Data Driven Community events kicking off.
Also, we just wanted to mention that on Thursday, June 15th, Tableau is hosting their Data Dev Day. This is a really good event. It’s more of a technical deep dive that the Tableau developers will hold. We just want to call that to folks on the call, their attention, that this is coming up on June 15th.
Without further ado, I will stop talking. I will pass it to Chris Monahon, our president. You will be starting the presentation here about how you can simplify your migration to Tableau Cloud.
>> CHRIS: All right. Thanks, Stuart. Welcome, everyone. Thank you for joining us today.
Before I get things kicked off, just want to introduce our team again. Myself, Chris Monahon, President of XeoMatrix, I’ve been doing data analytics for about 20-plus years, so I got a lot of experience in this space. Stuart will be emceeing today as well, but he’s done a lot of activity on migrations as well. And then Patrick Landis, who’s our lead solution architect, who has a lot of years with Tableau, a lot of experience with Tableau Server and cloud. So he’s our expert today, and he’s going to be walking you through the migration process. So we got a great panel here.
Our team has done a lot of these Tableau Cloud migrations. They’re really popular right now. A lot of people are looking to reduce their infrastructure costs, reduce their administration costs. So they’re looking to migrate their Tableau Servers over to Tableau Cloud. And today in our presentation, we going to share some of those best practices, and lay out an outline on what type of approach you might want to consider for your organization.
As Stuart mentioned, we’ll have a Q&A panel at the end, so please put your questions in the chat window and we’ll address them then.
Here’s our agenda. These are the topics I’ll be covering. First, an overview of Tableau Cloud, talk about some of the architecture options, and address something called Tableau Bridge. You all might have heard about it. Now you’ll learn a little bit more about it.
We’ll also talk about how you go about creating a migration plan for your organization, then we’ll jump into what is the migration process, and that’s where Patrick will be giving a live demonstration of the content migration tool, which helps automate the migration process from Tableau Server, Tableau Cloud. It’s really cool. You’ll want to stay for that. And then at the end, we’ll wrap up with best practices and recommendations.
So a little bit overview on Tableau Cloud. What is Tableau Cloud? Tableau Cloud is a fully hosted cloud-based SaaS solution that Tableau provides. Think of it like a hosted version of Tableau Server. The upside is that because it’s in the cloud, like all things cloud, you don’t have to maintain a server, there’s no administration, and upgrades happen automatically. No interaction involved from your side.
You all might wonder, is this a new product? What is it? It used to be called Tableau Online, but now it’s called Tableau Cloud, to align with some of the other Salesforce cloud options out there. So Tableau Cloud is formerly called Tableau Online.
Now, you might wonder, what’s the difference between Tableau Cloud and Tableau Server? As I mentioned, Tableau Cloud is fully hosted. You don’t really have that administration with it.
People might wonder, “Well, I’m on Tableau Server now, so why even consider moving to Cloud?” Well, you might want to stay on Tableau Server, if your organization really has specific requirements. Usually, they’re around legal or compliance issues, where they might want to keep tighter control on settings and governance. So if that’s something that you want to do, then maybe staying on Tableau Server is a good option for you. But from what we’ve seen, the trend is, most organizations, even ones with, SOX compliance, HIPAA compliance, all Tableau Cloud is certified. You can go ahead and move over to Tableau Cloud. A lot of organizations are doing that.
What are the key benefits? Again, not to harp on it more, but it’s less administration. If you’re not excited about that, I don’t know what will be. No more managing Tableau Servers; whether it’s on Linux, or putting Windows patches, no more of that.
It’s also, in our experience, we’ve seen a lot better performance and scalability. Tableau, since they are managing these servers, they have optimized these servers to scale, and they know how to tune the product. So you’re going to see better performance overall on Tableau Cloud. You’re going to get those automatic upgrades. So whenever a new feature or version release comes out, all that happens on Tableau Cloud first. So even before the products get released to the general public, Tableau Cloud is going to get updated. So you’re always going to get automatic upgrades and access to the latest features.
One of the things we see with a lot of folks that are on Tableau Server, they aren’t keeping up with the upgrades as often. They might only do one a year. Well, then you’re definitely going to be behind on some of the latest and coolest stuff. So that’s one of the cool benefits.
Another thing that sometimes gets overlooked too is that license management is easier. You’re not going to have to put keys, paste keys, send keys or email keys to other people. All that is going to be done seamlessly through Tableau Cloud. And therefore, you’re going to have less IT resources for managing, and then you’re going to definitely have, overall, lower TCO. So those are the benefits we hear from clients that are looking to move over to Tableau Cloud.
Here’s one case study we did. It’s a bit smaller implementation. They had about 1100 users. And if you look at the object counts that they had, they had about 1000 data sources and 400 workbooks. Now, that is something to note, and I’ll touch on why that’s important later in the presentation. But the number of objects and what type of objects they are really is critical in determining what the length and scope of the project is going to be.
So in this case, they also had 150 prep flows too, which added to some of the migration time. But we worked with them to do an object inventory assessment, and we help them come up with a migration strategy and a project plan, and then successfully migrated all of their content over, and worked with their business to do the change management and to roll out Tableau Cloud across their organization.
So this is a really cool case study. And the immediate ROI for them was that they got the stability that they weren’t getting with Tableau Server. And they were a couple versions behind, but they have the latest and greatest features now. Overall, their business was a lot more happy and excited about it. So that’s a little bit about Tableau Cloud.
You might be asking, what’s the architecture of Tableau Cloud? How does it work? What does it look like? It really depends on how you’re connecting your data, and this will play into your migration planning as well.
There’s really two data sources. There’s your cloud-based data sources, which, for those that aren’t familiar with what that might mean, these are in the cloud, meaning external to your company’s network, and they’re outside the firewall. So these are sort of configured more in the public cloud.
Examples of this might be Snowflake, Redshift, Databricks, Salesforce, Google Drive, things like that. Now, there’s a grey area. They might technically fall into your network, how you’ve configured it, but in general they are accessible from the outside world.
Then you have your internal data sources. They’re on the network and behind your firewall. So things like that might be SQL Server, Postgres, Oracle, Hortonworks. So some of these data sources are going to be internal to your network. And depending on which one you’re connecting to, again, will determine on your migration strategy.
If you’re using internal data sources, you will require something that’s called Tableau Bridge. Tableau Bridge is a little client that you would use to help connect to your internal data sources. Tableau Bridge is, like I said, a very lightweight application client. It takes about a minute to install. You install it on a server that’s inside your firewall. So if you have internal data sources, Tableau Cloud out of the box can’t talk to them, because they’re behind your firewall. So what you want to do is have this little proxy that can communicate and relay queries and requests data between your internal network, and connect to the data sources, and pass that back to Tableau Cloud. So it’s a little lightweight proxy that sits inside your firewall. It’s common practice to use. A lot of organizations use that.
Again, if you’re connecting to internal data sources, you would need that. If it’s external, then you can whitelist Tableau Cloud and connect it directly to those data sources, like Snowflake or Databricks.
One comment about Tableau Bridge that I will make is that, Tableau Bridge, the way it works is that when you are scheduling any sort of extract or refreshes, or doing any live queries, the data sources that you’re connecting to in Tableau, those data definitions, those data sources that you have in Tableau need to be published separately. They need to be published data sources. They can be embedded in the workbook. If they are, then they won’t automatically refresh through Tableau Bridge. So there’s a part of the migration process where you separate that out and republish them as separate data sources, and then they’ll refresh accordingly.
So little caveat there. It’s just a step in the process that needs to be done, but I wanted to call that out.
So what does the data architectures look like? As I mentioned, if you’re connecting to cloud data, you’re going to connect directly from Tableau Cloud to your cloud data sources, be it Snowflake or Databricks or even Google Drive. Some of these, you might want to whitelist for security reasons. So if you have a Snowflake environment set up, you would whitelist Tableau Cloud, which has an IP address for your Tableau Cloud site. You can whitelist that in Snowflake so that it’s secure at that point, and only Tableau Cloud can connect to that from the external world to your Snowflake instance, or be it whatever cloud instance you have.
This is the most easiest, straightforward way to do a migration. If you going from Tableau Server, and you have just cloud data sources moving to Tableau Cloud, it is the easiest way to do it. It requires the least amount of work. So this is definitely ideal if you can achieve this scenario.
The second one is internal data sources. It’s a little more complex than the migration strategy, because you are now connecting to internal data sources. You have to introduce Tableau Bridge, and that Tableau Bridge then needs to talk to Tableau Cloud. So you will require having a server in the middle that acts as that proxy to relay communication and data between your internal data sources and Tableau Cloud.
Right now, Tableau Bridge is only supported on Windows. It will soon be out on Linux as well. Just something to consider there if you’re talking to IT. But it would be sort of a server to manage. And you might be thinking to yourself, “Well, I thought I’m doing this so I don’t have to manage servers.” In this instance, yes, it’s true that you would still manage a server; however, usually, the requirements for the Tableau Bridge is going to be a lot less as far as size, memory, processing, things like that. And in addition, the bridge client doesn’t require a lot of maintenance, whereas a Tableau Server requires a lot more administration. So the overhead and administration costs is pretty minimal.
Now, the last options which we also see as well is, you got to hybrid. So either you’re a large organization that has both cloud data sources and internal data sources, so you still need bridge, or you might be making that transition from your internal data sources over to the cloud, and it’s taken a little bit longer because your data warehouse development might be taken longer. Whatever the scenario is, you might have to run a hybrid option, so just keep that in mind.
When we’re talking about creating a migration plan, there are several different approaches that you might want to consider, and we sort of bucket them into three.
The first one is called a total migration. And that’s going to be your lift and shift, where you’re literally going to migrate everything you have in Tableau Server today over to Tableau Cloud. The reason that’s easiest is because it’s a one on one, apples to apples. So at the end of the day, whatever you have now in Tableau Cloud should match your old environment in Tableau Server.
If you’re going to go this route, I would recommend cleaning up first before you do the migration. So remove any old objects, things you don’t need. And I would also recommend not reorganizing things during the migration process.
Sometimes we get asked that question a lot. It’s very tempting, like, “Oh, we have a new environment now. Let’s reorganize all the project folders.” It is very tempting, but it does make the testing a lot more difficult, because now you’re not comparing sort of the paths, apples to apples, so it just adds a little bit of time. It can’t be done, but it’s best to launch first and then do the reorganization as maybe a DoD follow-up phase.
As far as the partial migration, that’s where you pick and choose. And sometimes we get asked that, like, “Hey, we got a ton of stuff, but we only want to move these subset of objects.” Well, that also can be done. But to the same point, picking and choosing with the content migration tool takes a little bit more time, especially if the objects you want to move are scattered across many different folders. It’s just a little more time intensive in trying to do that migration efforts. So number two is probably not the approach we typically see. I would say number one with the total migration is the most common.
Now, the third one, of course, I call it the DIY. You can automate a lot of the migration here. But on smaller instances where it’s a smaller set of workbooks or dashboards, let’s say it’s 25 dashboards and maybe 15 data sources, you don’t necessarily have to go through this whole migration strategy and stuff like that. It’s pretty obvious. You can just download the workbooks’ data sources, republish them to Tableau Cloud and call it a day.
So always keep the third option in the back your mind, especially if you have a smaller implementation, because that makes things a little bit easier.
All right. So what is involved, and what should you consider during the migration planning process? What are the steps?
First of all, as I mentioned, you want to perform a Tableau environment assessment. And with this, there’s a lot of things you want to consider about your environment. Is this, first of all, going to be an internal or external facing solution? I would say, most of ours are going to be internal. Most people have internal, but there are definitely external use cases that we’ve migrated as well. And you need to take those into consideration because that’ll affect your approach and your timelines as well, and that level of communication that you’re going to need as you do the migration process to let people know that you are switching platforms.
Secondly, you need to understand, is there going to be any sort of SAML or a single sign-on authentication? Is that required? Is it already being used today? If not, is that something that you want to do when you make the switch? We do it all the time. We have a lot of folks that don’t use SAML; they use local authentication, or whatever, you know, in Tableau Server, and we go ahead and make that switch now in Tableau Cloud. So now would be a good time to do that.
When you talk about how many objects that need to be migrated, during that assessment, look at how many data sources you have, how many workbooks you have, how many prep flows you have, and how many of those can be consolidated or cleaned up, as I mentioned, before the migration. And if you have a multi-site environments on your Tableau Server, consider maybe merging some of those into a single site.
For example, if you have three sites on your current Tableau Server, when you stand up your site in Tableau Cloud, a consideration is going to be licensing costs. And so if you’re expecting to have three sites also on Tableau Cloud, there’s not that overlap in licenses across sites in Tableau Clouds. So what you would do is, you would stand up your one site in Tableau Cloud and then create project folders to represent the different sites that you have on your Tableau Server. That’s one approach.
You can also go the multi-site approach, but, again, there are some licensing implications that you’d want to talk to your sales rep about.
The second step here is to diagram your infrastructure. As we saw on the prior slides there, there’s a couple of different ways that you could configure your architecture. You want to understand if Tableau Bridge is going to be involved, what networking and firewall rules might have to be changed if you’re dealing with internal data sources. So take all that into consideration, and talk to your IT group. If you do have Tableau Bridge involved, you’re going to want to go head and stand up the Tableau Bright server, and get your system accounts lined up, and understand who’s going to manage these accounts and manage the Tableau Bridge server. So go ahead and do your planning with IT and diagram your infrastructure.
The third step here is creating a project plan. And that is going ahead and talking to the business, and understand, what is the good window for doing the migration? And in addition, what is the window for them assisting you in signing off and doing the UAT, and what are your team resources for doing the migration? And can the business contribute or assist with some of that as well? Lastly, you want to finally decide what type of approach you’re going to do. Is this going to be a total or partial or manual migration approach? So that’s what we’ve seen.
Here’s an example of a migration plan. This is a simple, smaller four-week migration. And our approach is to take it in two phase. Phase one is definitely going to be the migration. And step two is what we call the sunset phase, where, by default, Tableau grants you 60 days of overlap between when you purchase Tableau Cloud to Tableau Server, so that you have enough time to perform the migration. When you do the migration, obviously you want to go ahead and sunset your Tableau Server at some point.
So phase one is migrating all the objects and performing the migration itself. And in this case, on a shorter one, you want to leave like a week or two, where you have that sunset period where you might have people call in and say, “Hey, I’m having an issue with this workbook,” or something like that, and you can always have that Tableau Server to refer back to and look at what’s going on there in case something’s not functioning correctly, and then you perform the sunset. So definitely approach it in two phases.
As I mentioned, you’ll then perform the object inventory assessment and identify and prioritize what needs to be moved, and then perform the migration of the objects, do the UAT, and then do any performance testing. And if you need to install Tableau Bridge, work with your IT department to set that up. That’s all phase one, and then you approach the sunset of your Tableau Server.
The one key thing I want to harp on, and I’ll do it again, is the change management. You want to communicate early and often to your users, be it they’re internal or even external. With internal users, you want to communicate with the business, tell them what’s coming up, how you’re going to be logging in. Sometimes there’s some nuances in how they log in.
A lot of default login names we see on Tableau Server are their first initial last name. And then when they come into Tableau Cloud, it’s definitely going to be your email address. So that’s a slight change, not a big one, and they might want to know.
In addition, if you’re implementing single sign-on which they’re not used to, or they didn’t have before on Tableau Server, you want to communicate that too.
Lastly, some of the administrators might have to use MFA, Multi factor authentication, and that’s a change too in the process. So all this needs to be communicated, you know, there’s a new URL that they’ll be using for Tableau Cloud, unless you’re doing a DNS alias rerouting or redirecting. So all this needs to be communicated often.
At the end, for some folks, there might be some training involved. You might have been on a really old version of Tableau, and now there are a lot of new features. And this is the perfect opportunity to get people excited about Tableau, and start leveraging all the new capabilities you have. So this is the perfect opportunity to do that, and you want to promote and foster that adoption. So start doing some lunch and learns. Do Tableau days. You can even bring it to your COE, and really promote the benefits of moving to Tableau Cloud. So that’s what an example of migration plan looks like.
Let’s take a look now on what the migration process is. I know a lot of you guys might have a lot of questions here. I’ll go over real quick, high level, sort of the approach, and then we’ll jump into a demo of what the content migration tool looks like.
Here are the objectives when we plan on doing a migration. First and foremost, you want to make sure you’re simplifying this migration to Tableau Cloud. We want the process to be simple and easy. You want to reduce the administration and infrastructure costs. So take that into consideration. We want to migrate all the environments and sites to Tableau Cloud so nothing is left on Tableau Server. Again, addressing any security or permissions that need to be done, whether it’s single sign on or whatnot. And then we want to ensure that you have better performance than what you have today. So test the extract performances as well.
Lastly, there needs to be a knowledge transfer. So you want to make sure that your internal BI team knows how to support things now on Tableau Cloud versus Tableau Server. It’s less administration, but they still need to know how to handle certain situations, like if Tableau Bridge, for example, has any hiccups or things like that. So just a little bit of knowledge transfer there.
This is our process of methodology. Like I showed before, similar to that project plan, you’re going to start off reviewing the requirements, do an object-inventory assessment, go ahead and start your project planning right in that phase one and phase two that I mentioned. And then you’re going to iterate, per site, on migrating your data sources, your workbooks, and then performing that UAT testing.
I will mention that during the UAT testing, you want to make sure that you keep the migration or the testing window as small as possible, because as you’re doing the migration process, your current Tableau Server environment is still up and running, so there’s going to be some delta changes. People are naturally going to be making some changes, and you need to sync those changes. So there’s scripts and stuff that we have that we leveraged to find out those deltas, and we call those little delta syncs. You want to do those, but you want to minimize some of the migration time and UAT time. The longer the period, the more likely there’s going to be more changes, so you want to minimize that. And then after that, you launch.
So this is what it looks like, high level. I tried to put something together here for what a two-month migration might look like. So you might spend the first week doing some of the planning and configuration, security, Tableau Bridge. And then, weeks three to five, you would do the actual migration itself, and then have a two-week testing period. And then you’d do that support, which might be a couple of weeks, depending on your comfort level and how much time you have with Tableau Server still. And then there’s that sunset period, where you’re going to then start making sure everything’s working properly on Tableau Cloud before you go ahead and turn your Tableau Server off. So that’s what it looks like. So high level, again, giving you an overview of what the migration approach looks like.
What I want to do now is to turn it over to Patrick, who’s going to go ahead and share with you one of the tools that we use to do the migration itself. It’s a tool that’s provided by Tableau, and it assists with automating the migration process. It’s called content migration tool. So we’re going to do the live demo now. And with that, I will turn it over to Patrick.
>> PATRICK LANDIS: All right, thank you. Let me go ahead and share my screen here. Awesome.
What we’re looking at here is the content migration tool. When you come into this, you’ll start with this screen right here, where we’ll go ahead and start a new plan here. We won’t save that one. You’ll start in this view right here where you’ll have your source and your destination. So what you’re going to want to do is sign in to your Tableau Server, and then sign in to your Tableau Cloud as the destination.
In this case, for this demo, we’re just going to use the Tableau Server I have set up, and we’ll just do a quick little demonstration here. Within the connection screen here, it’ll automatically default to Tableau Online right here. What we’ll need to do is, we’ll come in and we’ll create a new connection to that either Tableau Server or Tableau Cloud. So from within here, I already have some saved, but you click “new connection” right here, give it a cool name, server, and then you plop in the URL. And then you’d have some options to do personal access token, browser-based sign in, or username and password. Any of these are fine.
In this demo, I’ll be using username and password. I already have one set up here. In this case, I have my credentials already filled in, and I did that twice. So let’s go ahead and select the first one as our source server. So I’ll click “connect,” it will pop up with the sign-in information here. We click “sign in,” And then it’ll ask us, “Hey, which site do you want to use as your source?” In this case, I have this test site here that has a few workbooks that we’re going to be migrating over from test to prod. So we’ll click on “test,” it’ll go ahead and gather the information from your source site. And then here, we’ll go ahead click on “destination.”
In this case, we can use the same connection string since we’re using the same server. In the case of migrating to cloud, you would select “cloud,” and then you’d sign in to your cloud instance. So we want to move this information and these workbooks over to prod. Just double-check here, test, prod. Perfect.
From here, we go on down to this next button here, or we can navigate over here on the left hand side to our next section, which is “projects.” Let me go ahead and make this a little bit bigger. Then we click “selection” here. So what it’s going to do is, it’s going to say, “Hey, which projects are you wanting to specify?” You can either come in here and specify specific projects to move, or on, I’d say 99% of cases, I always select “all projects” here. And then we click “next,” or go to the next section over on the left, and we can then specify some different options.
If you don’t have those projects already built on the destination side, you can click this button here. I always like to click all of these. And we try to copy project owners, apply user mappings, so on and so forth. And then we go on to the next section, and this is where you start to specify some workbooks. You can either move over all the workbooks or part of your sort of inventory of workbooks here. In this case, we’re going to ahead and move everything over.
Next, you go down to “mapping,” and in here, you can actually specify different things. You can specify, “Hey, I want to rename a workbook, change the project destination for these workbooks, prefixes, and suffixes,” if you needed to do that for organization purposes, so on and so forth.
Then we also have transformations. Within this transformation section, you can actually replace [inaudible] grammar values, images, replace text, things of that nature. So you could actually come in here, specify, “Hey, which workbook has a parameter?” And you can come in here, select that workbook, and then make changes to that parameter and the values within that.
Coming down here, data source transformations. If you have workbooks that have data sources that are embedded, you can come in here and there’s an option to replace the tables, set the connection information, so on and so forth. So you can make transformations to the actual calculations and different types of things for sequel and connection information here. You can also remove the extract.
Say, for instance, you have a really big extract you want to move from your source to the destination location, you can remove that extract to hopefully lighten the load there, and then you can recreate that extract once you move it over to your prod server or cloud.
Then we also have publish options here.
Sorry. Hold on just one seconds. Can you hear me OK?
>> STUART: Yes, I can still hear you.
>> PATRICK: Yes. I keep getting a pop up saying that my microphone is not working, but it’s still working.
Moving along, you can come in here. You have several different options here for workbook publishing. You can copy the workbook owners, apply user mappings, copy, extract, refresh schedule, so on and so forth. And then coming along, you also select your data sources, then you can also add different mappings here, similar to the workbooks, where you can rename the data sources, change the project’s, prefixes and suffixes, if you need to do that for organization. You can also do data source transformations. You can also specify connection information here, remove extracts.
This one right here is important for when you move to the cloud. Because everything needs to be published separately, you would use this option here called “use Tableau Bridge.” So what this is going to do is it’s going to convert all of the embedded data sources you have within your workbooks to being published separately so that it works for the cloud. So you can come in here, click on this, it gives you some search criteria here if you needed to, say, search for a specific connection type that you want it to move to a published data source, you could. And then you can come in here, click on “preview results.” In my case, I don’t have any published data sources here that it would find. And once you have everything configured here, you select this, and it says, “use Tableau Bridge.”
I’m going to go ahead and uncheck that just for the example, to show what it looks like when it’s migrating. I don’t have anything that needs to be published separately for this example.
Moving along, we have this published data source options. Again, a lot like the workbook section, you can overwrite your data sources, copy permissions, so on and so forth. We’re going to go ahead and copy the data source owner. You also have options to add tags, remove tags, apply, extract, refresh schedule, so on and so forth. So lots and lots of options for you to look at when migrating content from source to destination.
Next, we have this important section here called mapping. Of course, there was an error. So we click on mapping here, then from within here, you can do your domain mapping, user mapping, group mappings, or you can import those mappings based on a CSV file.
For instance, if you want to carry over all of the user configuration and have all of your workbooks mapped to the correct ownership, what you can do is, you can actually use this user-mapping section here and specify, “Hey, I want this user to match a user over on the destination site.”
It’s the same for groups. You can specify this group. It may be named a little bit differently in your source site, and it may be a different group name in your destination, but let’s go ahead and map those together. We can do all that mapping within here.
Next, we have another section called scripts. You can run scripts pre and post migration. You could set up the parameters and working directories and things for those here. And then you also have this last one, which is the plan options. Refresh, extract, separate migration. Automatically create, extract refresh schedules that don’t exist. Now, how does this error handle errors in the migration? You can click on “continue migration” if workbook or data source fails, you can also do enable version control. What that’s going to do is, it’s actually going to download your workbooks and put it into a folder for you. Same with data sources, workbooks, and [inaudible] sources. From here, we can go ahead and select a plan name, then we can save this. So let’s go ahead and call it tests. We’re going to save that. And then it’s actually going to go out and create a TCM exe file. I’m going to go ahead and just put that here in my desktop folder. Local disk, users, desktop, test. Just for now. So let’s save that. Then from here, we can click “review,” and it’s going to give you an overview of everything that you’ve selected thus far. And then from here, if everything looks good, we can click “run.”
Now, just before I run this, I want to double-check some of these things I checked. I think because I haven’t done any actual mapping here, I’m not going to do this “apply user mapping.” I just don’t want it to fail. So I’m going to go back to this “run migration,” I’m going to click “run,” and we’ll see if it actually runs for us here.
So it’s going to go out and connect to the server, download the workbooks, and then push them to the destination that we specified.
As you can see here, it also output the user matching. I didn’t have the users in that secondary site there, so it didn’t find that, and so it skipped that section for us.
Now it’s publishing the workbooks. Once this is done, we’ll just take a look really quick to see what it looks like on the server.
Let me go ahead and stop sharing and re share my screen real quick. Did the wrong screen here. So I can come back up here to the Tableau site and we can see if I go to “test,” we have these workbooks here. And now we go to prod, if we go to “explore,” “all workbooks,” we can see that we have these new workbooks published to our destination site. Or in this case, it would be Tableau Cloud.
Thank you very much. That’s a quick overview of the content migration tool, how it works. And there’s lots and lots of options for you to use to tailor that to your specific needs when migrating from server to cloud.
>> CHRIS: All right. Thank you, Patrick. That was an awesome demo. Very cool. Thanks for walking us through that.
Just so everybody knows, that’s just one of the tools that’s provided, and one of the tools we use during our migration process. There’s some scripts and things also that you can use to make things a little bit easier as you do your migration.
I do want to note one thing, and, Patrick, feel free to chime in. I know we often get asked, like, “Oh, cool, well, then it’s just going to migrate everything for me.” Well, there’s some caveats there. It does do a lot of the heavy lifting, depending on sort of what you’re utilizing in Tableau Server right now, it might do 90% to 95% of what you need it; heck, it might do 100%. But there are some things that it doesn’t migrate. Some of the things might be like subscriptions. Some of the extract refresh schedules don’t alert. Custom views is one thing that doesn’t get migrated.
Some people don’t even leverage custom views. That’s where you’re saving your filter selections on your dashboards. Some people use it heavily. So that’s something to consider. And there’s ways to approach this, and we can certainly advise you on strategies we’ve seen.
Sometimes, we have the business go ahead and create that during the UAT process. They know their schedules, they know their custom views. So during that migration testing phase, why not go ahead and recreate some of that stuff. So there’s ways around some of those limitations. There’s other scripting options as well. That’s just something I wanted to call out.
All right. Let me go ahead and share my screen one more time. Again, thank you, Patrick, very much.
So just to wrap up here, let’s talk about some best practices and recommendations that we’ve seen.
As I mentioned earlier in the presentation, any sort of cleanup and reorganization that you want to do, I typically like to do that prior to the migration. Or if you must wait, go ahead and do it at the end. If you really feel like you want to launch with a big bang, then maybe start reorganization and clean up prior to the migration. That way, when you launch after migration, it’s done. Otherwise, I would wait till afterwards, because reorganizing the folders during the migration process really makes it more difficult.
The other thing is, when you’re doing these migrations, be aware that sometimes up to 60% of your objects might not need to be migrated. You might find that they’re not being used, they might be old, or test, or some sort of temporary report that’s been created. We have seen it as high as 60%, so don’t be alarmed if that’s the case. And if it is, then maybe take some time to clean up before you do the migration.
As I mentioned, the total lift and shift, or even the manual approach are sometimes the easiest strategies we seen. We don’t see the partial migration approach as much. But it is used a lot for larger implementations. So each with their own. Figure out what approach works best for you.
I would use that two-phased approach like we said. Focus on the migration first, and then the lower-hanging fruit, things that maybe still need to be addressed, you can do it during that Tableau Server sunset period.
As I mentioned, you want to shorten your migration time as much as possible. Sometimes, we’ve talked to folks when they do their UAT period with the business, and they’re able to negotiate a blackout period. That would be a luxury. A lot of times it doesn’t happen, but if you can, that would minimize that delta change syncing that we were talking about there. So if possible, just take that into consideration, because the longer you do some of that testing, there can be more changes, obviously, that you need to sync later.
I would, if at all possible, remove the dependency on Tableau Bridge, just so that you have more of a seamless user experience and sort of what you have there with Tableau Server today. It will be more of a one to one with your Tableau Server rather than having (Tableau) Bridge involved.
If you do have to use Tableau Bridge, I would definitely recommend pooling. Pooling is similar to clustering. You actually have two Tableau Bridge at that point, and that way it covers you in case of fail over; and that way, you have that redundancy.
One thing that I do, this is a little pro tip here, the default out of the box is sort of 10 concurrent jobs at any point. You want to increase that connection pool size, depending on the size of your Tableau Bridge Server, maybe as high as 30. It could be higher. It sort of depends. But there’s two settings there: the connection pool size, and the max remote job concurrency settings, which I’ve put there. Play around with that, and see what works for you. But that’ll get you more throughputs. So as you start doing your extract refresh schedules, you’re not limited to 10. Otherwise, you’re going to start seeing some sort of timeout settings and jobs failing, and you’re going to wonder why. And that’s because it’s just not getting enough throughput to run your jobs.
Again, one other pro tip is that, as Patrick mentioned, with the content migration tool, for the permissions and assignment of groups and things like that, you want to make sure your Tableau Cloud is seated with all the users and groups that exist in your Tableau Server.
If you’re using SAML, you don’t actually have to script any of that. You could. The other approach is to go ahead and use your SAML provider to sync and pull in all those users and groups into Tableau Cloud automatically. So that’s a little pro tip. It could save you a little bit of time.
Lastly, I harp on this again, and I’ll close with this, don’t forget the importance of change management. So communicate early and often. Let people know these changes are coming, and that things will be slightly changing, as far as where they URL to log on. Now, if they had any bookmarks, they won’t be bookmarked anymore. Little changes like that can help make the process a little bit easier.
With change management, you always want talk to your business who is your end client, and identify what some of the risks are, and challenges that might come up as we’re doing the migration, and how we can address those. Just to make sure there’s a general understanding of what the process is going to be, and how we would address any changes.
Go ahead and communicate those changes. And at the end, also make sure that you’re promoting training and adoption, so that you really see the benefits of what moving to Tableau Cloud is.
With that, we have about 10 minutes. If you have any questions, certainly reach out to us. Here’s my information, Stuart and Patrick’s info as well. If you have questions about today’s presentation, please reach out.
We will then open right now with a Q&A panel discussion.
Stuart, do we have any questions right now?
>> STUART: We don’t have any questions right now. But I have been a part of so many migrations. I know a couple that come top to mind, so we’ll probably wait on some questions coming in.
As we do that, I know one question that comes up a lot. And for the folks on the call, you might be thinking this, but what are some of the challenges that we’ve seen pop up during a migration? Are there specific challenges, Chris, that we could talk to? Pitfalls, things to look out for, things of that nature.
>> CHRIS: Yes, that’s a great question. One that comes to mind is, not knowing your username and passwords. That sounds like an easy one, but it’s crazy how big of a showstopper that is.
When you’re doing these migrations, your data sources, the content migration tool can migrate any embedded credentials. But a lot of times, people want to convert those data sources over to a system account or something like that. If you want to do that, take an inventory of your data sources prior to the migration. Understand, you can look there, right in Tableau. If you go to “explore,” click on “data sources,” you can see all the connections and what the connection types are. Get that inventory list ahead of time before you even start your migration. That way, you’re prepared and there’s no delays in finding out who owns those data sources.
So that’s one that comes to mind. Patrick, do you have any other ones?
>> PATRICK: None off the top of my head. There’s just so many questions that I’ve been posed with.
>> CHRIS: Bridge sometimes can [inaudible].
>> PATRICK: Bridge is usually a big one that oftentimes people… There’s lots of… At least, initially getting it set up. So bridge can be a little quirky getting set up, but once you have it set up, it’s usually hands free. We could definitely walk you through that process if you need assistance with that.
>> CHRIS: Yes, that’s a good one. That is a good one. Sometimes there are some little nuances there on how to set it up with a service account so that can be little…
>> CHRIS: Yes. Yes. Good one.
>> STUART: It sounds like the content migration tool, based on the presentation, is really helpful, depending on the size of the migration itself. How do our customers get access to that content migration tool?
>> CHRIS: Yes. That is either available through advanced management. There’s also a free version that’s available through the Tableau Pre-release Programs. So that is a program that you can sign up for and download that as well. If we’re assisting, we’re a member of that program, we can certainly help you out with that. Or you can download it yourself. And they always have the latest version up there.
>> STUART: Yes. Another question that comes up is, what is testing and the rollout look like for Tableau Cloud? And maybe, Chris, you could talk too. For clients coming from Tableau Server, they may be accustomed to having a dev, a test and prod environment. And what does that look like in Tableau Cloud? Knowing that there’s really one site, and they don’t have those additional environment. Maybe you could talk to that, too.
>> CHRIS: Yes, yes, that’s a good one. So especially for maybe some folks that provide embedded analytics or something through their some sort of SaaS solution where they’re embedding Tableau, they are used to more of the traditional dev, test and prod environments.
As I’ve mentioned, before, when you move to Tableau cloud, you’re only going to get one site. If you set up separate sites, then there are some licensing implications that you’ll want to consider.
So if you are running a true dev, test, and prod, let’s say internally, then most likely, all those users are all the same users, or a subset of users across those environments. So what you want to do is, create one site in Tableau Cloud, and then you would populate all your users. And your route would have your production folders as normal, and then you create a dev and a test project folder. And that’s where you would then manage your objects accordingly in sort of those environment project folders, if you want to call it that.
>> STUART: And it’s a fairly easy process, I’m assuming, to move content that’s in those kind of sandbox dev, test folders in the production. [inaudible] Yes.
>> CHRIS: Yes. Simple move.
>> STUART: Another question that comes up, and it might be harder to answer, but typically how long did these migrations take for a customer?
>> CHRIS: Yes, yes. They vary in size. I know that, obviously, depending on the number of objects and how many sites you have. Some of the smaller to mid-sized ones can be as short as two weeks, and up to a few weeks. Some of the larger multi-site ones where they have a lot of users and more parts of the business, I would say those can take up to two months to maybe three max. It just sort of depends on the number of objects and how much regression testing you want to do, and what your organization feels comfortable with.
So that’s really the long term.
>> STUART: Yes. Cool. All right. I think that’s all the questions that I typically hear. If anyone has any additional questions, please feel free to reach out.
By the way, always feel free to reach out to us. Our emails are right here, as Chris is showing. We’re happy to connect, happy to help in any way that we can.
We’ll look forward to meeting again in August. We’ll talk about data pipelines, we’ll talk about centralizing data and making it easier for analytics.
I want to thank everyone for attending today.