Thank you so much to everyone who's joined today. I would love to share with you a bit about InterWorks. If this is your first time being on an InterWorks webinar, welcome. We're so glad you you're here, and we're excited to talk today about Tableau Cloud migration readiness. At InterWorks, we are an analytics consultancy focused on strategy, solutions, and support for all things data. We're global with teams in the US, EMEA, and Australia, and our goal is to help you find your path forward wherever you're at with your data. At Interworks, we specialize in helping people and teams succeed with tech. So, Sarah, if you wanna hop to the next slide, that would be perfect. Alongside our partners and customers, we help you build strategies and problem solve solutions to succeed with the technology that you've invested in. We can help you with anything in your journey such as data analytics, data prep, data management, data architecture, cloud migration as we'll talk about today, server administration, embedded analytics training, and so many other topics surrounding tech. But today, we'll be talking about Tableau cloud migrations. I do recommend that you also visit the InterWorks blog. That's going to have a bunch of resources around all of the tech community support and you'll get also some great advice there from the global inner works team. And then go ahead and also follow inter works on LinkedIn. That's where you'll find updates from us on future webinars, upcoming events, like the one that you've joined in today. And a few reminders before we get started. Did see a question come through the chat about whether we're recording this session. We absolutely are, and this will be shared to you, to your email in the next couple days when that recording is ready. And then one quick ask if you weren't on a minute ago when we talked about q and a, if you would use that q and a function within Zoom today to ask any questions that you might have, that provides a really nice format for me to go in and answer those questions as Sarah is taking us through the content. So you're welcome to use the chat function, but for questions, we do recommend the q and a feature within Zoom. And if you're not seeing that, it should be tucked under that more button at the bottom of your Zoom toolbar. We will have some dedicated time at the end of the presentation for questions, but I will be keeping an eye on that q and a to answer questions along the way. So just so you know who is on the other side of the q and a, my name is Madeline Cook. I'm an analytics consultant with InterWorks and a member of the InterWorks Tableau cloud migration solution team. So myself along with Sarah and a few other colleagues, are spending lots of time helping our clients strategize the path forward to Tableau cloud migration. So I'm super excited about what share what Sarah has to share with you all today. And with that, I'll go ahead and pass it over to Sarah to do her introduction and take us through today's content. Thank you, Madeline. Hi, everybody. It's nice to have you here today. So like Madeline said, we are here today to talk about, Tableau cloud migration readiness. So what are the things that, you need to consider and prepare sort of for the big move from Tableau Server to Tableau Cloud. So you might be here on the webinar today or catching this recording. If you are a Tableau server, or site admin, or a BI developer who is really tasked with or planning to or you're thinking about migrating to Tableau Cloud and you're really curious, like, what do I need to know, before I migrate? What are some things I should keep in mind or plan for or prepare for in order to migrate to Tableau Cloud successfully and smoothly? So a little bit about me. My name is Sarah Dorfman. I am an analytics architect here at InterWorks, based in, the Los Angeles area. Like Madeline said, I'm also part of our, solution team for our Tableau cloud migration. So, Madeline and I handle things like cloud migration assessments, which we currently offer for free if you're interested. We also, lead and execute many of our migrations as well. So any migration question you have, we are the folks to ask. So moving on, I just wanna kind of, at a high level, go through, today's agenda for the webinar. We're primarily gonna cover five different areas in this order, looking at things like content prep and the logistics behind a migration to Tableau Cloud along with your authentication options and some things to keep in mind when it comes to authenticating users with Tableau Cloud. And then, of course, the all important but slightly heavy area of data connectivity, when it comes to a cloud migration. And then we'll close with governance before we get to our q and a. So to start, I would say think about Tableau Cloud migration. We're gonna dive right into the content prep piece. As someone who recently moved in the last year, I would say I'm not gonna lie, Tableau cloud migrations do remind me a bit of moving. So we'll kind of hear this this theme and this through line throughout the the webinar and how it's really similar to moving house, or moving your business in a way. So like I said, migration is a lot like moving, especially when it comes to content prep. One of the things we emphasize when we do our cloud migration assessments, for example, with clients, and I'm sure this is something that you guys may be considering in your move, is really only to take what you need and what you can see yourself using for analysis in the future, in your Tableau cloud environment. One thing that we tend to see, is, what we rec or I would say one thing we tend to see and recommend, especially for clients that are preparing to migrate to Tableau Cloud, is making sure that they reduce, a certain amount of content, maybe archive it in a shared network location before bringing it over, before bringing things over to Tableau Cloud. I like to think of it as a what we call our six month rule. And the six month rule, the reason I have these hangers up here, if you haven't heard of it, when it comes to maybe cleaning out your closet, a tip that a lot of organizers have is if you're trying to figure out what to get rid of or what to pare down, have all your hangers faced one way at the beginning of six months, and as you wear things turn the hangers around. And then at the end of six months, if those hangers have not turned around, that's when we say get rid of those, donate them, consign them, that kind of thing. And so in much the same way, we sort of take that approach when we're reviewing, clients' content on server when they're considering cloud migrations. We tend to see a lot of content or a good chunk of content doesn't get used, at like, or isn't accessed per se in the last six months. And so even if you're going to have plenty of room, in migrating to your cloud site, there is still, in order to make the migration smoother and easier, we still recommend finding ways to reduce your content. So one of the things to think about too when it comes to content prep is, am I also going to have enough room? Not just cutting down my my pile of stuff, but am I gonna have enough room to bring things over? So when you are thinking thinking about moving to Tableau Cloud, there are two different types of sites that you can migrate to. There is the standard Tableau Cloud site, which has, a file store size of one terabyte. The largest piece of content, whether it's a data source or a workbook, for example, that can live on a standard Tableau cloud site is fifteen gigs max. If, however, you have, much more content on your Tableau server, you're definitely well over that terabyte, limit, you can go with an advanced management site. So that gives you a much larger, file store size of that five terabytes, and individual content can be as large as twenty five gigabytes. However, one thing, I will say about the Seismax is that even if you are able to move to or planning to move to something like an advanced management site, from our experience doing migrations, we highly, highly recommend keeping individual content sizes fifteen gigabytes or below. It can be very difficult to, download really large pieces of content, particularly anything that exceeds fifteen gigabytes, off of your Tableau server and have it move, let's say through the rest API or through our migration tool if we were to do your migration and bring it up to cloud. We've just seen that issue a lot with clients even if we're doing the migration within their environment. Tableau does have really we've seen some limits in terms of being able to move content that exceeds fifteen gigs. And in general, I would say it's best practice to keep an eye on keeping your content from getting that large because it can also affect your, performance and load times for your workbooks. So just wanna kind of throw that tip out there that even though there is that twenty five gigabyte max, overall, from a performance perspective, we would suggest keeping things at fifteen gigs or below. Then in terms of thinking, okay. Will will what I have actually function and work in the new space? And there's a couple, limits, so to speak, that Tableau puts in place on their cloud sites for certain functions and tasks. So things like extract refreshes, on both types of sites, whether it's a standard Tableau cloud site or advanced management site, you have a two hour refresh, extract refresh maximum. So those are things that we can explore and look into to see if you're hitting those minimums in our assessments. This load request as well. Now, obviously, three hundred seconds is a very long time. It's five minutes for a visual to load, but that is the maximum load time for a visual on Tableau Cloud. It will time out and will not load for end users. Additionally, you can see here the, concurrent subscriptions and refreshes that you can have on both site types of sites. And one thing to note, and we'll talk about this a little more, especially when we get to the data connectivity section. But if you have on premise data that needs to be refreshed via Tableau Bridge, The default refresh time out limit for Bridge is twenty four hours, and that can be configured or changed. But I will emphasize, do not use this twenty four hours or use Bridge as a workaround to get around that two hour extract refresh time. That can actually make refreshes a lot slower if you're trying to skirt that two hour limit. And, again, so a lot of things that we like to point out here, are so that you can take into consideration anything that you may need to optimize prior to migrating to Tableau Cloud, whether it's the size of your data sources, or certain elements or features within your workbooks, that may be causing performance issues. Another thing to consider, like, when you move when you're moving house, are there any sort of maybe updates or modifications I have to make, to things before I move into my new place? And we when it comes to, certain file types, that is the case with Tableau Cloud. So many of us who may have extracts now that we connect to, in our published data sources or embedded in our workbooks are likely in the dot hyper file format now. However, for clients who've had, a longer history with Tableau Server, we tend to find that sometimes there are still dot TDE or those older Tableau data engine file types. And one thing, I wanna note is that any dot TDE files or extract files that you have of that format, they will not physically migrate to Tableau Cloud. You will get error messages in your in the REST API, in our migration tool if you try to move them. Tableau Cloud simply won't accept them. And so, one of the things we recommend doing, is this is a little tip. If you wanna see if you still have any dot TDE files that you need to convert to hyper files before migration, you can go on your Tableau Server home page to explore to the all data sources option, in the upper left corner of that home page. And you can check the in the connects to column, you'll see the file names, and it will include the file extension in them. So you'll see if it says dot TDE or dot hyper. And that's a good quick way to check to see if you have any older data engine files that need to be converted to hyper files. And then, of course, any other modifications or updates you might be wondering about, that's not the only one. So one thing to note is that, let's say, for example, you are connected to any kind of flat file, so an Excel file, a CSV file, some kind of a text file. And currently, those files are maybe, you are connected live to through your shared network on and Tableau Server, or maybe you have, an embedded extract, let's say, that you're connected to of that flat file. One thing to note is that in if you need to keep these flat files fresh, if they need to stay on a regular refresh cadence, one, you will need Tableau Bridge in order to keep them fresh. But the other thing to note about flat files is that they will need to be extracts, and you will need to convert all of those connections to published or hosted data sources. So in other words, your your flat files that require refresh, again, you'll have to convert them to extracts and publish data sources. They cannot be embedded in your workbooks if you need them to be refreshed. And, of course, is there anything else we need to maybe install or consider sort of before we settle in, before we really start the migration process? And so, yes, I'd say any anything like extensions, webhooks, if you, are doing, or have an embedded application that you put your Tableau content in, you'll wanna set up things like connected apps, and test those out, especially before you go live, and and move your content over as well. Third party apps, what I tend to see a lot of, and I would say what Madeline and I see a lot of here when I refer to this in in particular is things like Alteryx workflows. We have a lot of clients that, create data sources that they then push up as hyper files or publish data sources to their Tableau server right now. And so, if, if you're gonna continue to need that to be the the case in Tableau Cloud, we highly recommend, working that out and mapping that out, before, you start to migrate content and processes over. For the Alteryx workflows, for example, that usually requires, the end user who's maybe creating that workflow to set up a personal access token in their Tableau cloud account, and then set up and test though that flow process with Alteryx. So just wanna make sure that that's also the case. And I see, there have also been some questions coming in about, custom scripts or things like tab command. And so those are also things that you wanna make sure that you test and prepare ahead of time as well. And sometimes I I know with with certain clients that we've done work for, sometimes you can't test them until the content exists. But, again, it's really you wanna make sure these are all tested and worked out before go live, before you open this up to your broader base of end users. So So the next thing, next main section we wanna cover is about logistics. Think of this when you're moving as, okay. Let's schedule movers. Let's put a reminder in the calendar. Let's make sure we're organized and ready to go. So a couple things to note. When you get, you're ready to start maybe the process of getting your cloud migration in place, this may seem obvious, but you wanna make sure your site is activated, and that you've, you've set up your site. You've assigned it to a pod. Generally, you wanna assign it to a pod, that's within, like, your geographical region. And then, obviously, this is when you also get to choose your site name, that will appear in the URL. And so one thing to note is make sure you really, really are sure about what your site name is. It is very, very difficult, to change in the sense that it just is gonna require just some messaging with Tableau support and and things like that. So, make sure that you are absolutely sure about what your site name will be, when you activate your site since that is the one time that you get to do that. Another thing to note, is when you are activating and setting up your site and when we do migrations, one of the things we have to migrate first is we always have to migrate users first in a Tableau cloud migration because users are tied to groups. Groups and users are what we apply, project permissions with. They are also associated as the owners of content and data sources. So we cannot do the migration without you moving users. However, a lot of clients we find do not want their users to know we are migrating. We don't wanna reveal that the migration has occurred until we're ready to go live with the Tableau cloud site. So one thing to note is in your Tableau cloud site settings, in the general site settings section, if your organization is going to authenticate to your Tableau cloud site via SSO, like SAML, let's say via, Azure or Okta, something like that, What you'll wanna do at the very top of the general site settings is uncheck that box that says enable site invite emails. What this will do is it will not email users once they are added, and imported into the site through the migration. If, however, you are not going to authenticate users via SAML or single sign on, and you're going to use the native Tableau ID with MFA option, meaning the user's email and setting up a an a multifactor authentication method, this will be grayed out and you won't be able to uncheck that box. So one thing that we suggest is when you migrate users over, migrate them over unlicensed. That way they won't get notified that they have access to the site. And let's say they are aware of the site or maybe do know where it is, they still can't physically log in because they don't have license assigned to them yet. So that's another way to prevent users from knowing about or accessing the site until you are ready to have it go live for them. The other thing that we tend to recommend very strongly, is making sure that you schedule your migration dates fairly firmly and also implement a content freeze. Obviously, depending on how much content you have, and how much testing you prefer to do as an organization, you know, your content freeze, meaning no no adding of users, no adding of new content, so no new workbooks, no new data sources, no major sweeping changes to existing content. Your content freeze may just be a few days, or a few weeks. But the reason we strongly recommend this, is because in general, it's just gonna make the migration easier and the validation of the content that's been migrated easier as well once it's been moved over. Sometimes we find that clients really can't institute a content freeze. So what we strongly suggest, and we have sample communication when we do migrations that we provide our clients, is basically saying this is the start date of the migration. So as of this start date, for example, if you are to make any changes to content, or add new content, let's say, to Tableau Server, we then suggest it is the end user's responsibility or the developer's responsibility to then move that content themselves, at go live. Sometimes we can also work with clients to say, hey. Do you know maybe who some frequent developers are that are constantly changing content or updating it, like and maybe give us a list of stuff to remigrate? But generally speaking, we find being very upfront and communicating those deadlines and those start dates and the go live and the content freeze with end users is really, really important, to make sure things go smoothly and that you can do proper validation of your content after migration. So the next thing I wanna touch base on is authentication. Think of this as getting your new lock and keys ready at your new home. You wanna figure out how am I going to access my new environment. So there's lots of options. Kind of in the same way, we pick out different types of paint we wanna pick for our house as well. There's lots of different ways that you can authenticate into Tableau cloud. So there is, of course, as I just mentioned, the built in authentication option, Tableau ID with MFA, where you can use any kind of third party authenticator app, as your authentication mechanism, for example. You can have single sign on options, like, through Google. What we tend to see a lot of with organizations, big and small, is usually whatever mechanism a client was using in their, server environment, which is usually some sort of SAML authentication, is what they're going to end up using in Tableau Cloud. And sort of I would say these the big three, Azure, Okta, and OneLogin are compatible with Tableau Cloud. From a best practice standpoint, this guy seems very excited about about this option, here on screen. But one thing we like to recommend to folks is consider the use of SCAM or the system for cross identity management to auto provision and sync your users and groups on Tableau Cloud. You can do this if you have those, sort of big three SAML options. I was mentioning these three identity providers, because if you're even considering of syncing users and groups this way, we highly recommend setting it up from the get go. Managing, users and groups locally from the start is fine, but it can be a little tricky, if you integrate this later on and need to maybe consider reorganizing or reassigning permissions, to content or different project folders. And so we generally like to say, if you're thinking about this, set this up from the beginning. One thing, I do wanna call out here because we actually ran into this recently with the migration, is be cognizant of, the domain names for user emails. So we have an organization that as we were starting the migration, we did set up SCIM via Okta, but the users we began to import, from server use the company's old domain. And then when we started syncing them with Okta, they were using a new email domain. So that's also something to keep in mind, which just required us to do a few extra steps, some additional cleanup to resync users. But make sure if maybe your organization is either, you know, let's say you're going through an acquisition or a merger or just a rebranding and you know your email domain is gonna change, I would recommend ahead of time making sure that's implemented on server first so you don't run into that issue maybe when syncing with, one of your IDPs in Tableau Cloud. And then another best practice that we like to recommend is if you are not using Tableau ID with MFA as your main authentication method, that's fine. We still strongly recommend though that at least one site administrator on your Tableau cloud site authenticates though via Tableau ID with MFA. The reason for this is, let's say there's an issue with your identity provider, you can't get access to the site, it's always good to have at least one user who can go in via Tableau ID with MFA and maybe update everybody to authenticate via the same way if there's a major issue. If everyone is authenticating via SAML and there is no backup method, when you do set up your Tableau cloud account, individuals are all required to set up and create backup recovery codes and then save them sort of in, like, a text file locally. But it it can be, it can take a few steps to to work with Tableau to just unlock your site through those recovery codes. So that's why we like to say and even Tableau says this on their site that it's really for emergency purposes only. So that's why both we and Tableau emphasize having a backup, site admin to authenticate via Tableau ID with MFA. And then, of course, don't forget when you have users on Tableau Cloud now, we use email as a username. So there will be no more guest access if that's something that you've had in your Tableau server environment based on the way that you currently license in Tableau server. And so each end user then who is going to access your Tableau cloud site must have a valid email address. So next up, data connectivity. So I'm sure, many of you are curious about data connections and, excuse me, and what what is and isn't supported on Tableau Cloud, what data connectivity will look like in that environment. And so kind of thinking, is is everything gonna work? Is everything gonna connect properly? So let's take a look at at at what that's gonna look like in this environment. So I'm gonna leave this up on screen for a bit just so you guys can digest and take this in, but I'm gonna go through each one of these columns individually. We're primarily gonna focus on talking about is your data type that you currently connect to supported in Tableau Cloud. So the left hand column, I will say, these are data types that are currently not supported, particularly cube data. So, anything like Oracle Essbase, Microsoft Analysis Services, it's just not compatible with Tableau Cloud. If you even try publishing up a Q based data source that wouldn't even require refresh to Tableau Cloud, Tableau will not accept it. So if you have Q based data, in your environment right now, you do need to convert it, to a compatible data type for it to work, in Tableau Cloud. In addition, there's just a couple other things to note that things like live connections to Google Cloud SQL. This is not Google BigQuery, but there are just some certain exceptions here we wanted to call out. If you also have Snowflake data, let's say, that's behind a firewall, you have a private cloud connection to Snowflake, and you have data management and you'd like to use virtual connections with that private Snowflake data, that currently is not supported, in Tableau cloud. However, I will say that just because things are not supported now does not mean they will not be supported in the future. By Tableau, this list we find does tend to get shorter over the quarters. So it's always good to kinda keep an eye on on things on Tableau's help site, around their Tableau cloud and Tableau bridge sections of that site to see what is and isn't supported. In terms of things that are supported, but with some exceptions, so we're gonna kind of kind of cover this first column. I'm gonna go ahead and move over to supported with exceptions, on premises data. So when I say on premises data, I'm talking about, like, any of your SQL Server, MySQL, Oracle SQL, databases, that are on prem in your organization's environment. And, of course, anything that would like I said earlier with Snowflake, if it's behind a firewall, if you have private cloud data, that also is going to require, it is supported by Tableau Cloud. But in order to keep that type of data fresh, you will need Tableau bridge. And we'll talk about Tableau bridge shortly in terms of what that is, and what that does to help keep that on premises or private cloud data fresh. Additionally, there are certain data sources that can only be refreshed on Tableau cloud as extracts only. No live connections. And then one thing I wanted to note about the, SAP NetWeaver, business warehouse data is that this cannot be refreshed on Tableau Cloud, but you can publish up extracts of it to Tableau cloud. It's just gonna require that you have to manually refresh them if you connect to that type of SAP data. And then in terms of what is supported, of course, is any public cloud data. So if you don't have Snowflake behind a firewall, Redshift, Google BigQuery, if you have cloud file based data. So you have files in OneDrive or SharePoint online, Google Drive, Dropbox, Box, those types of files, in those public cloud file spaces can be refreshed. So I realize that is a lot to take in. Like, this guy is kind of reacting right here. But like I said, I'm just gonna share this on screen one more time so you guys can kind of take it in, digest it. I do recommend, if you have phones handy, you don't need to take pictures of the slides, but in a couple subsequent slides, I forgot to mention this at the top, we will have some QR codes that you may wanna scan. So just make sure that you have your phones handy. So like I was alluding to with, earlier, mentioning Tableau bridge a few times, you're You're probably wondering, okay, Sarah. Do do I need this Tableau bridge you keep speaking of and in order to keep my data fresh? And you will, like I said earlier, if you have those, on premise on premises, databases, or you have maybe flat files that require refresh, or you have a lot of private cloud data behind a firewall, like this lovely little environment here with all the crazy little red arrows. But if you're not familiar with Tableau Bridge, we'll kind of just touch base on on what that is first. So Tableau Bridge, it's free software. You can download it from Tableau's website in much the same way you download copies of Tableau Desktop or Tableau Prep Builder. It is free software. Think of it as a conduit or a proxy that allows your on premises data to talk to Tableau Cloud and be refreshed on the cadence that you set, on Tableau Cloud. Bridge software, we call that we tend to refer to it as the bridge client. Bridge clients get installed on either Windows virtual machines or in a container on Linux. And then on each of those environments, whether you're in Linux or Windows, the appropriate drivers also get installed there too. So if you have SQL Server, SQL Server drivers will get installed, for example, on the Windows virtual machine if you're going to operate your bridge clients in a virtual machine in Windows. Bridge clients should always be managed by site admins in your Tableau cloud environment. When you install the bridge software on your virtual machine or your container, in order to have that bridge client then talk to or connect to your Tableau cloud site, you have to log in to your Tableau cloud site from the bridge client. And the login or user type that is required has to be a site admin. It can be a site admin creator or explorer explorer, but the site role must be a site administrator in your Tableau Cloud site in order for Bridge to talk to Tableau Cloud. Another thing to note is that you can only have one site connected to a bridge client at a time. So one bridge client can't service multiple Tableau Cloud sites. It can only service one site. However, if you have your Tableau cloud site, and we're gonna get into this in a little bit, and, you can, however, have multiple bridge clients connected to one site. We find a lot of clients will do that, and we recommend that to help with load balancing, your refreshes for your on premises data. So and I'll I'll touch on that in just a few points. But anything else with bridge, these are some things that we like to call out, if you're going to require Tableau Bridge in your Tableau cloud environment. We always recommend that you run bridge in service mode. So in Windows, there are there are two modes. If you're installing Bridge on Windows that you can run Bridge in, there is application mode and service mode. Service mode, you're basically running Bridge as a Windows service. So what that means is that Bridge will run continuously even if the user for that Windows virtual machine is logged out of Windows. And so we and that by running in service mode, it always ensures that any live queries or refreshes are continuously running and stay on schedule in your in your environment. And as I was alluding to, in my last slide, we generally recommend that you have at least two, preferably three bridge clients stood up to connect to your Tableau cloud environment. This helps with load balancing and pooling of resources, so that if you have a lot of on premise extracts that need refreshing, what this allows Tableau Cloud to do is go to available pools when resources are available. Or if one bridge client for some reason is down, there's always a backup pool of resources to go to. Another thing we recommend with pooling. So in your Tableau cloud site settings, we saw a bit of what the site settings look like when I showed you that enable site invite email section. That's the general site settings tab. There is a tab in Tableau cloud site settings fully dedicated to Tableau Bridge. And within the Tableau Bridge site settings page, there's a section here on pooling. And so we always recommend that you set up custom pools, to, load balance those extract refreshes and live queries with Bridge. There currently is a default pool. For those of you who are migrating very soon or in the near future to Tableau cloud, there is a default pool setup, but Tableau should have a note there now indicating that this default pool concept is going to be deprecated and will go away. So if you do have any default pools, if you're utilizing the default pool Tableau has for your cloud site, move that move move your bridge clients out of that and into custom pools that you've set up yourself. Another thing that you'll wanna make sure of in setting up those pools sort of simultaneously is at the bottom of your bridge settings on your Tableau cloud site. You will wanna make sure that you add the domains where your on premises data is to this private network allow list and then map those domains to pools so that the pool knows, okay, someone's coming in to do a SQL Server refresh. I can, let's say, maybe refresh anything in this local inter works environment in network pool a. I could also maybe add it to network pool b so I have the ability to refresh that data in multiple places, if needed. I know you're probably wondering, but, Sarah, what if I really don't wanna deal with Bridge? What if I I don't wanna have to worry about, downloading this extra software, potentially maintaining it or upgrading it? One thing that we can do to avoid bridge is migrating your on premises data to a hosted cloud platform. I realize that probably is a much bigger discussion for another day, for your organization. But in the long term, it will make the maintenance and management of your data on Tableau Cloud much smoother. If, however, let's say you have private cloud data, this is where if you have your phones available, I highly recommend scanning this. You can white list the Tableau URL, specific to your site's location. So when your your site URL will have the name of the pod that your site is assigned to, and each pod has a specific IP address or IP range. And so it would be helpful, like, let's say, if right now you have Redshift and it's behind a firewall, if you allow Redshift to whitelist the IP for your Tableau cloud pod, and then Tableau can directly talk to Redshift and you won't need Bridge to help with those refreshes. So that's another alternative. So this QR code links you to the full list of IPs for all of Tableau Cloud's pods. I'll leave this up for just a second. K. Alright. And moving on to this last piece, another alternative is to move flat files to public cloud spaces. So, again, things like Dropbox, Google Drive, OneDrive. If, let's say, you wanna move some of your flat files to those locations instead of needing to refresh them from your shared network drive with Bridge, this is also a good viable option. And one thing that we we also tend to talk about when we do our cloud migration assessments is, you know, we look at also how much on prem data do you have. And if it turns out you just have a little bit, this is where we'd really push and make those recommendations. Or if you find that you will need Bridge, but you're apprehensive about having to maintain it, upgrade it because even though Tableau cloud sites upgrade automatically, bridge software does not. The bridge client software is released, at the same cadence that your Tableau cloud site is updated, but it does require manual upgrades. And so these are different types of services that the maintenance and monitoring and like deployment of bridge that, our InterWorks KeepWatch team, for example, can help with is post migration support. So that's also something to think about depending on your appetite for whether or not you want to manage bridge yourself. And then finally, let's talk about governance. Think of this as, okay. I've got, like, my my data connectivity. Think of those as my utilities. Like, those are turned on. I've got my new locks and keys. I figured out what I'm moving with and figured out how it's gonna fit in my space or at least physically what I'm gonna bring with me. But think of governance now as really sprucing up your new place. You wanna settle in to the site and and get everything, nice and in order. So, obviously, when we do the migration, you're gonna be moving things like data sources, workbooks, flows. That's the bulk of what we're always migrating in these Tableau Cloud migrations. However, these are also all of the other objects that we are moving. Users, groups, sites. You may have multiple sites that you need to migrate to one or two or however many new Tableau cloud sites you plan to migrate to. The permissions, for your content also need to be migrated. You also need to migrate things like favorites or tags, and subscriptions and refreshes. So one thing to note here especially is embedded passwords. So meaning your usernames and passwords, that you have maybe embedded in your published data sources and workbooks for your data connections. So, these will have to be reentered after migration manually, either, maybe by your site admin if everything is using a service account or by the end users if it's their personal credentials. One thing that we can do, as part of our migration tool is we can embed the username and passwords with the migration so that you do not have to manually enter them afterwards. I will say from experience, we tend mostly to embed the clients that provide us this information, service account username and passwords, and not the username and of individuals where there are individual credentials that are used for data connections. Obviously, individuals, like, they just don't wanna share their usernames and passwords with us, and we totally understand. That's where we just have to emphasize. That's great. After we move the content, those end users will have to come to the site and reembed the credentials themselves. So that is something to keep in mind when you're doing the migration. Another thing to note, there are a few things that we physically cannot migrate to Tableau cloud. Collections is one of them. Think of these as your they're essentially a somewhat newer feature within the Tableau interface, groupings of your favorites, or different types of content that you wanna curate. Collections will have to be manually recreated, which I find a mix of some clients who use them a lot and some who don't. I tend to not see not migrating these as too much of a big deal because we tend to find it's good when the go live is announced for end users in that communication to include some links to remind folks like, hey, now that we're on this new site, maybe start to create some collections again for yourself, or start to recreate, some new subscriptions, things like that. It's a good way to reeducate end users about some of the features that they have control over in Tableau Cloud. And so, that's just something I wanna note here. There are other things we cannot migrate, like, comments that people might leave on workbooks or data sources. And then things like metrics and ask data lenses, those are deprecated because you're gonna be moving to Tableau Cloud, which now has Tableau Pulse, which has sort of succeeded those features. Another thing to note, with custom views is we can migrate custom views. However and we can migrate as I note at the bottom, we can migrate things like subscriptions and refresh tasks. However, we cannot migrate subscriptions to custom views. So that is also something to keep in mind and examine, in your repository data. And that's something we can also help look at if you have a lot of subscriptions to custom views. Those will need to be manually created after you migrate content. So when it comes to governance too, like I said, you wanna spruce up not just think about all those other things that you have to move with finer details moving, but how do I also wanna spruce up and organize my place? So one thing that we recommend after migration, after you've brought all the content over that you've decided to bring over, particularly if you are migrating or consolidating from multiple sites down to, let's say, one Tableau cloud site. This is where we start to suggest clients really start to think about how do I want my site structure on my new Tableau cloud site to be organized. So do do I want to have maybe better delineations between dev and prod projects? Potentially, if I have multiple sites, maybe I create a new project for content from each of those sites to help delineate, user access and content. So, again, something you wanna think about. It's a good opportunity to do that reorg, and re strategize how your content is organized on your site in the new environment. Another thing that we suggest, simply because if you have some Excel files that require refresh that may need to be converted into published data sources, we also recommend thinking of of of trending more towards using published data sources in your new environment versus having lots and lots of embedded data sources, particularly if a lot of the embedded data sources are very similar to one another. By consolidating down to having more published data sources, it reduces the proliferation of a lot of similar data sources. It's going to engender a lot more trust because you can certify these data sources so that if you have explorers who need to build content off of them, or you have viewers or just other end users who are who are looking at the data, you can add data certifications or and they're just gonna also be easier to maintain, versus maybe making five updates in five different workbooks in where where the similar data source is embedded in each, you'd only maybe have to make the changes in one published data source to have the downstream impact on all five workbooks. And then another thing to note, if you're not already aware, when you migrate to Tableau cloud, you no longer have access to your Tableau server repository. Instead, Tableau provides access to a project folder called admin insights. So any site admin on your site will automatically see this folder when they log in to their Tableau cloud site. You can also permission this folder to anyone else, any other creators maybe who may need access. But Tableau provides you with a workbook with pre built administrative views and about eight or nine data sources that cover different key areas of your site usage, your adoption, performance load times, information about, jobs and and background tasks as well. Many of the administrative views already use these data sources. Some of them don't. So think of them as sort of your mini repository. The look back window for data for a standard site for admin insights is ninety days. If you have an advanced management site, it's three sixty five days. One thing we tend to recommend to clients is let's say you wanna make some tweaks to the, standard views Tableau sends you in that workbook. I always recommend making a copy of the admin insights workbook that's provided, the starter workbook, and maybe making your changes or enhancements there. Because on a a couple times a year, roughly quarterly, generally when the Tableau cloud updates occur, sometimes Tableau pushes updates to that starter workbook. So if you've made changes to that workbook, visual or otherwise, Tableau may override them when they push their new updates to that workbook. So that's also just something to, be cognizant of. And usually, when you immediately activate your site, you may not see this folder. It takes about twenty four hours from the time your site is activated for it to appear. So that's also something to be aware of if you don't see it right away. And with that, we are now at the end. I realize that's a lot of information to cover in these five different sections. And maybe for anybody who's moved recently in person, it's hopefully not creating too much PTSD for you. But, I would say if you need help with your migration, please reach out to us. You can reach out to Madeline or I directly. We're easy to find online on LinkedIn on the InterWorks website. But, I highly recommend giving this QR code a scan if you have your phone nearby. Like I said, we specialize in migration planning. We offer our migration assessments for free currently. We can also do your migration. And with migrations currently that we do for clients, we offer a year of post migration support for Tableau site admins with our KeepWatch team. And so go ahead and scan the QR code or visit that URL that we have up on screen. And thanks for joining us today, Madeline. We have any questions maybe we wanna try and cover here. How's it how's it going in the Yeah. I've been doing my best to keep up. We've had a lot of great questions. There there are still a few outstanding that maybe we could talk through, Sarah. The first question is around what the user experience is like when they attempt to log in, but they're not licensed, if they're unlicensed on the Tableau cloud site. I think this is specific to an embedded use case. So Mhmm. What would be the the expected behavior from Tableau if somebody attempted to, like, grab a link or something without a a site license? So this would probably be be, it would this I would assume are these users potentially, like, external users, like, maybe outside the organization area? It says, what about dashboards, that are maybe intended to be, like, you know, kind of a command center appearing inside a waiting room or a large shared room, so something projected onto a monitor. Do you have any advice around how something like that could be authenticated? That is a good question. I, honestly, I would probably feel more comfortable if potentially one of our strategy or AEs, we can maybe get back to you about that because there are some licensing implications about about, the dashboards relies on, this new type of licensing called usage based licensing that Tableau has specifically for external embedded use cases. That, like, that sort of, authentication mechanism, it's you're simply just doing it based on views so that folks don't need to be licensed. It just requires some, certain type of coding within your embed site. We just set this up for a user recently, where they embedded a Tableau dashboard, that use it utilizes this, usage based licensing license for external viewers, on their main website. And so it just required some additional back end coding, with JSON web tokens and utilizing the connected apps setup, in Tableau cloud site settings to make sure that it appeared for those viewers. But in terms of the large screen piece, I feel like maybe we could follow-up with you about some more information about what that looks like. Thanks, Sarah. That makes good sense. Let's see what else we've got here. Just want to clarify that the post or the Tableau admin insights with advanced management, you get three hundred and sixty five days of history. Do what is the default, kind of the standard deployment? It's sixty sixty days, I wanna say. Right? Nine ninety for standard. Ninety? Okay. Would there be any advice around if someone wanted to retain data for longer than three hundred and sixty five days? I know it's not configurable, but I suppose they could they could script the the collection and storage of that data elsewhere. Yeah. So there's there's a couple things. If you have I guess, one, if you have advanced management and you have that three hundred and sixty five day look back, one of the things you have access to, although it's not the full repo data, is you get access to your activity logs. Those land in an s three bucket. And so, that's something that's a different, you know, kind of activity history, but you can build that up over time. And then, one of the things that we recommended to some clients who want a longer history is, if you if you search the web for Tableau Hyper API. The Hyper API, we found a couple clients, and and we've we've tested this internally where, you can essentially extract copies of those data sources in the admin insights folder that Tableau provides and land them in a data warehouse like Snowflake, and you can incrementally set up processes to build up that history over time. So using the hyper API, and landing, copies of those extracts of those data sources in, like, a cloud data warehouse is another way to build up history longer than three hundred and sixty five days. Awesome. Thank you, Sarah. Mhmm. Okay. Looks like q and a is slowing down a bit here. For anyone whose questions we didn't get to, we do retain the logs from the q and a. So Sarah and I will be able to follow-up with you directly following the presentation. Sarah, I don't know if you had anything else that you wanted to add, but I think as far as what I'm seeing still outstanding in q and a, these are things we can follow-up right after the press. Yeah. Yeah. Sure. I would say, yeah, I'm just looking at a couple of the other questions in q and a. I would say I see Jim's question about they haven't been using the login based license management yet. But, yes, it is it is a requirement for Tableau Cloud. So every user that logs in must have, a license to access the site. The use case I was speaking about, is a very specific use case where, if you have an external site, where, like, users outside your organization need to access Tableau content, that external cloud environment, you might have one or two creators who are, creating or publishing content up to that site, but then everyone else would be a viewer, and licensing would be based on, instead, you'd be charged based on impressions for those views. But, yes, everyone is going to need a license in order to access the site. I know that, I don't know the the specific details, but I know that eventually, Tableau cloud manager will be available, which I believe will allow, the creation of multiple sites on under one account. And so, but I'm I'm not sure specifically if that will require I don't think it will require a user to have a license for each site, but I I don't wanna speak I don't wanna, like, say that yet. But, again, as things stand right now, we do need a license to access a Tableau cloud site. And then, Brandon, in terms of when signing up for a cloud instance, how many hosts do that include in terms of processing power? I know that let's say I I think you can purchase more resource blocks. Again, this is a question I might, Madeline and I might follow-up with our AEs about to understand the processing power. The other thing to note is that, Tableau cloud sort of underlying infrastructure is is going to be relocating to and and migrating to Salesforce Hyperforce this fall. Each of the pods will be supported by that. So that is going to be, and is expected to provide a lot more processing power and security across Tableau cloud sites. But we can we can look into more specifics for, the resource piece for you. But I do know that the Hyperforce is going to, I think, provide a a a lot more support and and processing power for clients in that respect. K. Great. And then we probably have time for one more that just popped into the chat. Is the license to cloud on top of your normal Tableau license? So I'm assuming and feel free to clarify, but I think this is in reference to if you have tablet server currently and you're looking to migrate, would you need to add on to achieve tablet cloud or could, some sort of conversion take place? Yeah. So, usually, we find when when clients have users on server that they're licensing and they migrate to cloud, it is a new type of license. So, we find that clients tend to, like, transition off of their server licenses onto new Tableau cloud licenses. So it is it is a new licensing type. Awesome. Thank you. And then Tableau Bridge, no additional costs incurred with the installation of the bridge client. It would just be the hardware on which you'd install bridge. Right? Correct. So whatever whatever it costs your organization to stand up the Linux containers or Windows virtual machines, but there would be no additional costs, that you would have to pay Tableau. The bridge software is downloaded for free. Mhmm. Awesome. Fantastic. Well, we're right at the top of the hour here. For those of you whose questions we didn't get to, rest assured we will be following up after the presentation. Feel free to also reach out directly to Sarah or myself. Our emails should be listed in this presentation, which you'll you'll receive as part of that recording. Otherwise, thank you so much for joining. We hope to see you again on the next webinar, and everyone have a great rest of the week. Bye everybody. Bye bye.