High Performance Technologies - High Performance Technologies Blog #tableau

Why "If It Ain't Broke" Is the Wrong Strategy for Tableau Server

Tue, 21 Apr 2026 11:48:18 -0500

There is a version of this story that plays out more often than it should.

A company's Tableau Server has been humming along for years without issue. Then something changes — an SSL certificate expires, an OS patch is applied, a staff member turns over — and suddenly the server is down. The team calls Tableau support. Support pulls up the version number and says, essentially: You are too far out of date, and your version is no longer supported.

That is not a hypothetical. It is what happens when people mistake "if it ain't broke, don't fix it" for an infrastructure strategy.

The good news is that this outcome is entirely preventable — it just requires putting a plan in place.

The Pegboard Problem

"Wait," you might say. "Why should we mess with things that are working just fine?"

Because no connected system operates in isolation, and most people are only in control of a subset of the infrastructure, not all of it. There's an illustration we use to drive this point home.

Imagine, if you will, all the different pieces of your analytics infrastructure as pegs on a pegboard. Every individual aspect of your infrastructure — Tableau Server, the Tableau Support contract, the hardware it's running on, Tableau Desktop, database drivers, the data warehouse itself, authentication configuration (I'm looking at you, Snowflake) — these are the individual rows of holes on the pegboard.

The versions of those components are the columns—and versions tend to increase over time, so you can also imagine the columns as "when was this version released." Some components iterate slowly (like Tableau Server's supported version) and some iterate quickly (like Tableau Server itself), which shows up as peg holes being closer together on some rows and farther apart on others.

The pegs themselves are placed in the holes for which versions are relevant for each component. Remember, you probably only control some of these pegs.

Now, imagine rubber bands looping around the pegs that need to work together.

If the versions of the components are compatible, those pegs are closer together, and the rubber band can fit around all the pegs without snapping. It might be totally slack, with room to give as things change. Or it might have a little bit of tension, but nothing the rubber band couldn't handle. As long as the tension in the rubber band isn't too much to handle, everything works.

But when one of those pegs drifts too far — especially the ones that aren't in your control — the rubber band stretches and, eventually, snaps. And if you've ever been hit by a rubber band when it snaps… it doesn't feel good.

That is the situation organizations find themselves in when deferred maintenance finally catches up: a down server, no vendor support, and a team scrambling to reconstruct years of configuration decisions from memory.

Scope and Size: A Better Way to Think About Updates

Not all updates are created equal. Two factors determine how much work any given update actually requires:

Scope describes the types of things that change from your current version to the target version.

A patch release typically carries only bug fixes — small changes, narrow impact.
A minor release introduces new features, and may require a bit more: it may contain several bug fixes you need to communicate to your stakeholders, but it also contains new functionality to assess and potentially implement. Users love new features!
A major release with backwards-incompatible changes may require an adjustment to your infrastructure's architecture, or configuration reviews — and as a result, it probably requires more planning and preparation than the other two scopes.

Size describes how many of those changes accumulate before you act.

If you update monthly, a given release might carry a few bug fixes and one small feature.
If you update yearly, you're handling 12 months of patches, features, potential regressions, and breaking changes.

Together, scope and size reflect the amount of work required to perform the maintenance, as well as the potential amount of risk that work carries. A sustainable maintenance strategy keeps both as small as possible.

What Deferred Maintenance Actually Costs

When you defer updates long enough, something beyond technical debt accumulates: organizational debt. The team member who understood the original configuration moves on. Documentation grows stale. And when something eventually breaks — because something always eventually breaks — no one knows where to start.

Consider the practical math. A customer running a 2021 version of Tableau Server who needed to reach a current 2025 release was technically dealing with one upgrade. But that upgrade contained four years of accumulated changes:

dozens of individual patch releases rolled into one,
over 200 new or updated features,
more than 20 features deprecated,
all in all, roughly 315 items to consider (excluding bug fixes).

That is a fundamentally different undertaking than a routine maintenance window.

How Often Should You Update?

The answer depends on your risk tolerance, your team's capacity, and how critical Tableau is to your organization — but the options break down clearly.

Monthly is the lowest-risk posture.
- Each release carries the least accumulated change.
- Scope is narrow, size is minimal, and updates become routine enough that they stop feeling like events.
- If something does go wrong, the workarounds are inconvenient, but not show-stopping.
- This is the option that makes Tableau Server maintenance boring — and boring maintenance is exactly what you want.
Quarterly is manageable.
- Contains a larger update window and will contain a few months of patches.
- You will typically stay within the same major version, avoiding the impact of several backwards-incompatible changes at once.
- You may have more workarounds to manage, depending on the scope and size of the changes between versions.
Semi-annually is better than nothing.
- If you're not changing major versions during one maintenance window, you will be during the next one.
- The scope expands accordingly: what was a recurring maintenance task starts to look more like a recurring project.
Ad hoc or annual updates lead to more work, at best.
- These often require project planning, stakeholder communication, thorough testing cycles, and meaningful downtime risk.
- The gap between versions is no longer a maintenance consideration — it is the project itself.
- If you approach these tasks as if they are routine maintenance instead of projects, you may only learn about the risks after they've materialized. By then, you've committed to dealing with the impacts, even though they can't be quantified until everything is back to normal.

Making Updates Part of the Routine

The organizations that handle Tableau Server best are not necessarily the ones with the most sophisticated environments.

They are the ones that treat updates as routine rather than optional.

They have a maintenance schedule. They stick to it. And if something goes wrong, it doesn't take a ton of effort to remediate, because the size and scope of the maintenance was appropriately constrained.

Need Help Getting Current?

If your Tableau Server is behind on updates — or if you are not sure where it stands — High Performance Technologies can help you assess the gap and build a path forward. Whether that means a one-time upgrade to get you current, or an ongoing managed services arrangement to keep you there, we can scope what makes sense for your environment.

Learn more at highperformance.tech/services or reach out directly at highperformance.tech/contact-us.

Get Started Now

Introducing ViewAs: User Impersonation for Tableau Server

Mon, 16 Feb 2026 11:57:00 -0600

I've had the pleasure of working with Tableau Server administrators for over a decade and a half now, and one question that comes up somewhat frequently is some variation of: "A user says they can't see this dashboard, but from my end it looks fine. How do I see what they see?"

In most cases the answer, until now, has been: outside of Tableau Desktop, you can't. Not easily, anyway.

The Typical Approaches

How you handle this depends on your environment. If you're embedding Tableau in a custom application, your wrapper app can impersonate the user and render the viz as them. This works well when it's available, but it requires that you have embedding set up in the first place and that your portal actually implements impersonation. If you're not in that situation, it doesn't help you.

For row-level security issues, the workbook author or other Creators could troubleshoot in Tableau Desktop. This is effective, but now you're potentially pulling someone else into the investigation and waiting on their availability.

You can also check effective permissions in the Tableau Server content permissions dialog. It's easy enough to access, but interpreting the results takes some practice — and it only tells you about permissions, not what the user actually experiences when they navigate the server.

My go-to approach has been scheduling a Zoom call for a screenshare. I like this because you can troubleshoot user behavior and technical issues at the same time — sometimes the problem isn't permissions at all, it's just that the user doesn't know where to click. But scheduling a call isn't always convenient, and sometimes you just need a quick answer without the coordination overhead.

Introducing: ViewAs

ViewAs is a small application that lets Tableau Server administrators view the server exactly as another user sees it — through the actual UI, not just the API.

The workflow is simple:

You authenticate as yourself
Select the user you want to impersonate from a searchable list
Launch a session

From there, you see what they see. Their navigation, their row-level security filtering, their dashboard behavior, their effective permissions at every level. When someone reports they can't see the Sales Dashboard, you can verify in thirty seconds whether the issue is permissions, RLS, or something the user is doing on their end.

This is also useful for validating RLS across tenants, testing how dashboards appear for different user roles, verifying that new users have appropriate access on their first day, and documenting access controls for audit purposes. Automation is still the right answer for anything you need to do repeatedly at scale — but manual validation lets you iterate quickly when you're building something new, and it gives you peace of mind that what you've built actually works the way you expect. Both have their place.

Tableau Cloud

This version of ViewAs is for Tableau Server on-premises deployments. Tableau Cloud has tighter restrictions around impersonation — API impersonation requires Connected Apps with JWT authentication, which is significant overhead just to debug a permission issue. I'm exploring options for a Cloud version, but the architectural constraints are real. If you're a Cloud customer running into these friction points, I'd like to hear about your specific scenarios.

Getting Started

ViewAs is available now for free at viewas.hpt.tools (email required for download).

It works on Mac, Windows, and Linux, and takes less than a minute to set up. If you're using Tableau Server authentication, you can sign in with your credentials directly. Otherwise, if you are using SSO or another method, you'll need a Personal Access Token.

Questions? Reach out at hello@highperformance.tech.

Tableau Server Log Reference

Tue, 03 Feb 2026 13:31:00 -0600

Tableau Server writes logs across dozens of folders in different formats. It can be a bit tough to find info on which logs you need, given the context you’re trying to find. Tableau's documentation covers it, but you have to cross-reference multiple pages to find what you need.

This quick reference should help!

Don't forget to bookmark this page so you can easily find it when you need it.

Log base path on Linux: /var/opt/tableau/tableau_server/data/tabsvc/logs/

Log base path on Windows: C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\

Note: if you installed to a non-default location, look there for the relevant data → tabsvc directory, and you’ll find the logs directory inside.

Quick Troubleshooting

Symptom	Logs to Check
Users can't log in	`authnservice/`, `vizportal/`, `httpd/`
Dashboard won't load	`vizqlserver/`, `dataserver/`, `hyper/`, `httpd/`
Extract refresh failed	`backgrounder/`, `hyper/`, `filestore/`
Search not working	`indexandsearchserver/`, `noninteractive/`
Cluster node unhealthy	`tabadmincontroller/`, `clustercontroller/`, `tabadminagent/`
TSM commands failing	`tabadmincontroller/`, `tabadminagent/`, `appzookeeper/`

Process Log Reference

Core Request Processing

Process	Log Folder	Check When
Gateway	`httpd/`	User-facing errors, SSL problems
Application Server	`vizportal/`	Web UI errors, REST API failures, login page issues
VizQL Server	`vizqlserver/`	Viz rendering failures, session timeouts, memory issues
API Gateway	`apigateway/`	REST API v3.x errors (check out http first)
Data Server	`dataserver/`	Published data source issues

Data & Query Processing

Process	Log Folder	Check When
Data Engine (Hyper)	`hyper/`	Extract query failures, Hyper crashes, memory exhaustion
File Store	`filestore/`	Extract replication failures, missing extracts, sync issues
Cache Server	`cacheserver/`	Query cache issues, Redis failures, session data loss

Background Jobs

Process	Log Folder	Check When
Backgrounder	`backgrounder/`	Extract refresh failures, subscription failures, job queue backlog
Flow Processor	`flowprocessor/`	Prep flow execution failures, flow step errors

Authentication

Process	Log Folder	Check When
Authentication Service	`authnservice/`	SAML/OIDC failures, SSO redirect loops, token validation (also check the vizportal logs)
Identity Service	`identityservice/`	SCIM provisioning, identity migration, user/group sync

Cluster & Administration

Process	Log Folder	Check When
Coordination Service	`appzookeeper/`	Cluster quorum, split-brain, leader election failures
Cluster Controller	`clustercontroller/`	Repository failover, node health, process state transitions
Repository	`pgsql/`	Database connections, replication lag, failover problems
TSM Controller	`tabadmincontroller/`	TSM command failures, config apply errors, backup/restore, service startup errors
TSM Agent	`tabadminagent/`	Service startup/shutdown failures on specific nodes (also check the individual service's logs)

Search & Indexing

Process	Log Folder	Check When
Index and Search	`indexandsearchserver/`	Search not returning results, indexing delays
Non-Interactive Container	`noninteractive/`	Background indexing failures, metadata operations

Ingesting Logs with ts-olly

If you want these logs in Splunk, Elasticsearch, Loki, or similar, you'll need to parse multiple formats — log4j, log4j2, httpd, JSON — and keep up as Tableau adds or changes processes over time.

ts-olly handles this. It reads Tableau's config files to learn the log formats automatically, detects new processes and their configs as they appear, and outputs unified JSON. You don't have to build or maintain parsers.

ts-olly -node node1 \

-logsdir /var/opt/tableau/tableau_server/data/tabsvc/logs \

-configdir /var/opt/tableau/tableau_server/data/tabsvc/config

MIT-licensed: github.com/highperformance-tech/ts-olly

Need help interpreting what you're seeing in these logs? We've helped dozens of organizations troubleshoot complex Tableau Server issues — from memory leaks that only show up under load to intermittent authentication failures that disappear when you're looking for them.

If you're dealing with a tricky performance issue or need someone to review your server health, feel free to reach out — happy to point you in the right direction.

Bring Tableau and Agentic Analytics Together with the VDS API

Fri, 12 Dec 2025 13:17:21 -0600

We talk with a lot of companies that want AI in their analytics practice, but aren't totally sure what that looks like. Many of them want it enough that they are tolerating some oddities they shouldn't be, especially as they're exploring feature sets that haven't yet proven their worth. Specifically, they're having to build/define the same data sources and metrics in the AI system, simply because the AI system can't handle connecting to what's already there.

I've been working a lot with Ana, the agentic AI analyst made by TextQL, and have been extremely impressed by how it's able to navigate querying and connecting data from many different data sources, including APIs. Its command of Python and the iterative nature of analytics is the best I've seen. So I thought it might make sense for me to have Ana use Tableau's VizQL Data Service API to connect to Published Data Sources on Tableau Server (or Cloud), and see how it handles interacting with and querying the very same data sources that Tableau dashboards use. It took some iteration but worked out well. So I'm showing you how I did it!

pssst. if you'd like to see me actually do this live, register for the webinar on the right. i'd love to see you there

Live Webinar · Dec 18

Unlock AI-Powered Analytics on Your Existing Tableau Data

Live demo of Ana + Tableau VDS Integration · 11:00 AM CST

What's VDS?

Tableau's VizQL Data Service API (VDS) gives you programmatic access to Published Data Sources on Tableau Server/Cloud. Since it's the same data sources your dashboards use (and therefore the same data model), you can reuse the field names, calculations, and relationships you've already defined. It automatically respects row-level security and permissions. There's no need to download extracts or hit underlying databases directly, risking bypassing the governance you've already established in Tableau. Instead, everything goes through Tableau's governance.

In contrast to the REST API, which is powerful for managing metadata and performing administrative operations, VDS provides a more direct way to access data. While the REST API allows you to download detail or summary data from specific visualizations, it requires an extra step. VDS lets you query the Published Data Source itself, just like the dashboards do, making it a more seamless option for accessing data.

Who or What is Ana?

Ana is an agentic AI analyst built by TextQL. It's excellent at querying and coding (especially making API requests), tool calling, and iterative analysis. It understands data structures and relationships intuitively, and can reason about analysis steps. It can hold context across many many steps, build on previous queries, and create artifacts like Streamlit apps, static visualizations, downloadable reports... even playbooks that email you or Slack you their results after they run. (Yes, it supports Teams too...)

And it's observable: you can see what it's doing, how it's doing it, and thanks to inline comments, why it's doing what it's doing.

Connecting Ana to Tableau with the VDS API

To connect Ana to Tableau's Viz Data Service, we need:

Tableau Server/Cloud with Published Data Sources
Ana (hosted by TextQL) as the AI analyst
VDS API to let Ana query Tableau's Published Data Sources

Setting Up

Teach Ana about the relevant technologies using the Context Library

To start out, we gave Ana some context that makes it better at using the relevant tools. Ana has a context library where you can store information that can be dynamically added to a chat's context based on user roles or which data connectors are selected for the chat. As TextQL admins, we can add this context from the "Organization Context" tab on the Settings page. It's quite straightforward:

To be clear, this context is not strictly required! It just allows Ana to cut through some repetition and trial-and-error, which saves us time and money. It took some iterating, and we ultimately landed on context that includes:

Authenticating to Tableau - using a Personal Access Token, in this case; more on that in a moment...
Finding the data source - using the good old-fashioned REST API
Exploring fields/metadata - using the new VDS API
Constructing queries
Analyzing results and iterating
Filtering strategies
Performance tips
Common patterns:

Simple query
Searching with fuzzy matching
Complex filtering

Error handling
Additional resources

Here's the raw text we use that you can easily copy and paste into your own context library:

Download the Code Snippet

With that in place, we need to ensure Ana can authenticate to the Tableau APIs when it needs to.

Setting Up Authentication

Personal Access Tokens (PATs) are credentials you create in Tableau that let you authenticate to Tableau APIs without using your own username and password. They are revocable, and they keep you from exposing your actual credentials in various systems, scripts, or configuration files. If your Tableau account uses multi-factor authentication (MFA), like Tableau Cloud accounts often do, then PATs are required for programmatic access since it can be difficult to complete an MFA challenge within an automated workflow.

Creating a PAT in Tableau is very straightforward, and you can see a step-by-step guide here if you haven't done it before, or if you need a refresher: create and manage personal access tokens.

Note: Personal Access Tokens do have an expiration date on them! Based on my personal experience, it's useful to create a reminder a week or two before a PAT expires so you have a chance to create a new one and switch them out before it simply stops working. "A bit of prevention is worth a byte of cure", as they say.

Now that we have a PAT from Tableau, we need to store that in a place Ana can find it: the Environment Secrets. As the name suggests, Environment Secrets behaves like a password manager for Ana, allowing it to reference sensitive information like credentials without having to type the details out in the code verbatim.

These secrets don't necessarily have to follow an exact pattern, because Ana can inspect them and determine the most appropriate way to use them. I prefer to store them as JSON with a little extra helpful information. In fact, if you downloaded the context snippet from earlier in the post, you'll want to follow the same structure I do. The structure is documented in the snippet, and the snippet's code examples depend on it. Here's what that looks like:

{"server": "https://tableau.example.com","tokenName":"YOUR_TOKEN_NAME","tokenSecret":"YOUR_TOKEN_SECRET"}

From here, we navigate to the Settings > Configuration > Manage Secrets page, and create a new secret. We'll need to fill out:

Secret Name - we refer to it as TABLEAU_PAT in our context snippet, so if you're following along, you should too.
Secret Value - the single line of JSON above, filled out with the relevant values.
Instructions - Ana sees these instructions in every chat context so it knows when to use which secret. Be sure to give it enough info to make those decisions! In this example, the instructions were: "Use this PAT to authenticate to Tableau Server using their REST API; the authenticated session can be used for other Tableau APIs as well."
Docs Links - Any links to reference documentation that may be helpful when using the secret.

Here's what the screen looks like just before we click Create:

Note: After you click save, you won't be able to edit or view the secret's details again. If that's a concern for you, there's an easy and more flexible solution we typically use, but that'll have to be a different blog post!

At this point, we've given Ana enough information to:

connect to Tableau using the URL and PAT details from the secret, and
skillfully use the relevant APIs to authenticate, search for data sources, explore their metadata and data, and query!

Let's see how it works by creating a new thread and asking a question.

Chatting With Our Data

For demo purposes, we're using a demo dataset based on Microsoft's Contoso dataset.

We have created a Published Data Source on Tableau Server that exposes the Online Sales fact table and all of the related dimensions, as well as some calculated metrics and KPIs. We have not included any details about the data source in Ana's context library, so it will have to explore a little bit to understand how to collect the data we ask it for. Here's that data model in Tableau, for your reference:

To keep things interesting, I'm going to ask a question with an intentional but easy-to-resolve error in it:

"Using the Contoso Online Sales data source, show me the sales over time for the customer named Tom Miller."

The dataset has a "Thomas Miller" in it, so it will be interesting to see how Ana handles the discrepancy there. And with that background information out of the way, let's see the chat!

The chat has a few components to it:

The response messages
The tool call cells
Artifact previews
The summary response

In my mind, the interesting things happen in the tool call cells. We can see Ana follow the overall structure we detailed in the context library. It:

Authenticates
Lists Data Sources
Reads Metadata
Queries Data, and
Analyzes in Python

Overall, everything went as well as we could hope, in seven individual API calls to Tableau! It handled the name issue pretty well. It queried using filters for the First and Last name, and found no results. Since it expected results but found none, it decided to look into the customer names to find similar names. There are a handful of approaches it could have used, but in this case it decided to search for similar names, found the full list of Millers. With the relevant names in context now, it determined that "Thomas" was likely the one I was asking about, and proceeded from there.

It then created and saved some visualizations of the data using python, as well as wrote the underlying data to a CSV. Finally, it responded with a summary of its findings.

It Works! Now What?

So we now have an agentic AI analyst capable of connecting to Tableau and querying the same Published Data Sources we use in our workbooks. We see it's capable of correcting course when things aren't exactly as it first thought. Where do we go from here? Below are a few use cases we've implemented already, and one we're about to implement:

Playbooks - Executive Summaries via Email or Slack

I mentioned Ana has a playbooks feature that allows you to schedule these analyses to be delivered on a recurring basis over Email, Slack, or Teams. We've implemented operational playbooks that surface actionable information around deal flow and accounts receivable aging. Users enjoy getting the relevant data delivered to them directly in Slack, and really enjoy being able to ask follow-up questions in the same thread.

Exploring Complicated Database Schemas

We've already seen that Ana is adept at course-correction if something seems off about its findings. Similarly, it's also very good at exploring database schemas and determining how data relates. We have implemented Ana for users who need to uncover specific data without spending a ton of time digesting complicated schemas and ERDs. Ana's iterative discovery process makes easy work of that, and the context library allows users to improve Ana's efficiency over time as it discovers the relevant relationships within the data. Of course, there are several great approaches to mapping out the data models in advance, but that's out of the scope of this post.

In-Dashboard Chats

This is the one we're most excited to try next: embedding Ana directly inside of a dashboard, giving users a way to ask relevant questions about the data that's right in front of them at the moment.

Come see this demo live!

Want to see a live end-to-end demonstration of what you just read above? Come see the process start-to-finish, so you can do this with your own Tableau environment! Click the big red button below to register. Even if you can't make it live, we'll send all registrants a recording of the webinar once it wraps up.

Live Webinar · Dec 18

Unlock AI-Powered Analytics on Your Existing Tableau Data

Live demo of Ana + Tableau VDS Integration · 11:00 AM CST

Want to skip the line and get started now?

Schedule a time to talk with us about our Ana Quick Start, where we guide you and your users through the "getting started" phase so you can see immediate value.

Schedule a Call

Understanding User License Dependencies in Cloud Migrations

Fri, 15 Aug 2025 14:39:53 -0500

When you switch from Server to Cloud, getting your users licensed properly is essential. Tableau recommends setting up your Creator users first, and we agree! Working with your Creators, the Content Authors, throughout the migration process is vital to a successful migration. Once your Creators are added then you want to migrate the content so it keeps the correct ownership.

If you migrate manually, this looks like asking each of your Creators to download their content from the Tableau Server and republish to the new Cloud location, recreating any extract refreshes and custom views in the process.

One thing that is different about user set up in Cloud vs. Server is that Cloud requires users to sign in with full email addresses (ex: johnsmith@company.com), whereas Server requires just a username (ex: johnsmith) and password. If your Server currently has users signing in with simple usernames, they will need email-based credentials for Cloud, and it’s important to communicate any new sign-on procedures to your users during migration.

Unlicensed Users with Content

But what about the content sitting on your Tableau Server owned by an unlicensed user – either they have left the company or changed roles – and their legacy dashboards exist without continued ownership? How will their content get migrated?

The best thing to do is take inventory of all content owned by unlicensed users and evaluate if that content is still relevant and needed. Are those workbooks being accessed and used regularly?

If yes, then a Tableau Admin can reassign that content to a licensed owner so it can be migrated to Cloud.

If not, then the content can be decommissioned and flagged to not migrate to Cloud.

Clean House Before You Move

Not only can you clean up unlicensed users’ content but think of your Tableau Cloud migration like moving to a new home - it's the perfect opportunity to declutter! Why spend the time to migrate (and then maintain) dozens of outdated dashboards that nobody's looked at in months?

It's common for Tableau Servers to accumulate digital dust over time. That quarterly report from 2019? The prototype dashboard someone built but never finished? The "test" workbooks scattered across projects? Migration is your chance to leave them behind.

Before moving anything to Cloud, we recommend auditing your content usage. Look for:

Workbooks with zero views in the last 6-12 months
"Test" or "Draft" content that never went live
Dashboards created by employees who've left the company
Multiple versions of the same analysis

Starting fresh in Tableau Cloud with only your active, valuable content means:

Faster migration process
Cleaner, more organized environment
Easier maintenance and governance

You can use your Server's admin views or repository data to identify unused content before migration.

Get a Jump Start

As mentioned in our introduction post to this series, auditing your Server content and creating a Content Readiness Dashboard provides insight to which content on your Server is owned by an unlicensed user, so you can zoom in on the relevant content to make license changes before migrating.

When we handle migrations for our clients, we migrate content and make necessary changes at scale. This includes moving active users with proper licenses, content, and permissions. If needed, we can automatically reassign orphaned content to valid licensed users in Cloud during the migration process.

To get a Content Readiness Dashboard for your Server and see your unlicensed users' content, schedule a call with our migration experts below.

Talk to a Migration Expert

This is part two of our ongoing series on Tableau Cloud Migration Roadmap. Up next: Font Compatibility: The Hidden Migration Complexity.

This can be a pretty tedious process depending on how much content you have on your Server.

Taking the time to evaluate if content is still needed is well worth it in the long run — and will save you time on your migration journey.

CobWEBS...am I right?!?

Your future self will thank you for the squeaky clean Cloud environment.

If you get to Cloud and realize you've forgotten something, we can help you restore it from a pre-migration backup!

Tableau Cloud Migrations: Mapping Your Migration Journey

Wed, 13 Aug 2025 11:11:08 -0500

In the age of GPS-enabled smartphones, it’s rare to plan a trip without first checking your favorite mapping app. Whether you’re avoiding tolls, aiming for a specific arrival time, or want the fastest route, the app gives directions to meet your needs.

Migrating from Tableau Server to Tableau Cloud works the same way. You know your starting point and your destination — but what about the delays that could slow you down?

When you’re mapping your route from Server to Cloud, considering the unique details of your Tableau environment will help you avoid the most common (and costly) slow-downs you could encounter. In this ongoing blog series, we will show you how to identify these road hazards ahead of time so you can travel with confidence (and have the right ETA).

So, buckle up, and let’s begin.

The Route Overview

We find that most Tableau Server --> Tableau Cloud migration routes are made up of five key segments. They're all important, but the first, Planning and Analysis, is essential so you can get the best possible route customized to your unique environment, avoiding any potential roadblocks along the way.

During the Planning & Analysis phase, you need to answer two critical questions:

What is your strategy for data connectivity in Tableau Cloud?
Is your content compatible with Tableau Cloud?

To answer those questions, you'll want to audit your Tableau Server content, looking for things that could cause you to veer from the standard route. Think of this phase like checking the route before departing on a road trip — this is where you spot the construction zones, detours, and traffic jams. With that visibility, you can adjust your timeline, reroute where needed, and plan smarter. The result: a clearer picture of what’s ahead and a more accurate ETA for reaching Tableau Cloud.

Potential Route Delays

Here are six potential delays we’ve identified to be on the lookout for:

User License Dependencies
Unsupported Fonts
Broken URL Connections
Database Connection Failures
Flat File Refresh Failures
Private Data Connectivity

Each of these items may appear straightforward on the surface, but with the complexity of each dashboard and data source, they can end up being quite nuanced in how you approach a solution before and during migration.

Taking Inventory

When we plan successful Cloud migrations for clients, we start by creating a complete Content Inventory of all the users, data sources (and their connections), and workbooks on the Server, looking for the six potential delays we listed above. Once we've gathered our inventory, we visualize it in a Tableau Dashboard. The Content Readiness Dashboard helps us quickly see areas where remediation, or a reroute, is needed and plan accordingly.

» We'll keep adding to this series as we uncover more potential delays to look out for.

» This blog series will dive into each of these in more detail, ensuring you have the knowledge and tools needed to prepare for your journey.

» We get this information from the Tableau Server API, but you can also get the details from the Tableau Repository for your Tableau Server.

Planning a migration without knowing what's ahead is like driving cross-country without checking traffic. Taking an inventory and identifying the potential roadblocks we've outlined will show you exactly what to expect from your unique environment as you plan your migration.

Want to see what roadblocks might be waiting in your migration? We can help you out with your content inventory and provide you with a Content Readiness Dashboard for Server content.

Talk to a Migration Expert

This is part one of our ongoing series on creating your Tableau Cloud Migration Roadmap. Up next: Understanding User License Dependencies in Cloud Migrations.

What does it take to stand up a Tableau Server?

Fri, 15 Oct 2021 16:44:33 -0500

Understanding your Use Case

Possibly the most important step in planning out a Tableau Server deployment is to understand your use case. What are the end goals you want to achieve? You’ll want to consider things like how many users will be accessing your server, as well as what they'll be doing. You'll also want to understand what kind of data they'll need to have access to. Which users will just be viewing content, and which users will need to author their own workbooks?

Since Tableau Server is designed as a scalable web application from the ground up, it provides customers a great deal of flexibility and is an ideal platform for deploying on-premise or in the cloud. It’s important to choose the right hardware configuration that will work best for your use case as well. Typically it's good practice to separate the processes from the data source because they'll be on different servers. For example, you can keep your data on an internal database and configure the Tableau Server to access it from there.

Tableau Server can be installed on either Windows or Linux. There are pros and cons to both operating systems, and which you’ll choose should largely depend on whether or not the other related applications infrastructure in your stack is are native to Windows or Linux. It’s also important to consider which system your IT resources are most familiar with. If you're trying to share data with others and need a more robust server, you will probably want to go with Linux. If your BI needs require high-capacity servers with large amounts of data that need a lot of processing power, Windows is likely to be the more cost effective option.

While the following list certainly isn’t exhaustive, these are some of the questions our server experts at High Performance Technologies ask when planning a new deployment:

1. Will your server be running on Windows or Linux?

2. What version of Tableau Server will you be using?

3. What kind of Tableau license types will you need?

4. Is your server hardware on-prem or in the cloud?

5. Is your data on-prem or in the cloud?

6. Will you be working with protected data?

7. Should you utilize SSO or SAML?

8. What resources (CPU and memory) should you provision for your server?

9. Will you be using any database technology?

10. Will you be using any data warehousing technology?

11. Do you have resources and skills available for ongoing management of your server?

12. How quickly do you need to deploy a solution?

Once you've made the decision on your operating system then it's time to install Tableau Server! We will describe how you can go through each step of installing and configuring Tableau Server so that your server is ready for use in production.

We'll begin by logging into the server and making sure the system software is up to date. You can choose which services you want Tableau Server to run on Windows or Linux by using their respective user interfaces in order to install them onto the server. The main components we recommend installing to get started are the server, the data engine, and Tableau Prep. Once all of those pieces are installed, you’ll need to configure them so that they work together properly in production. You can do this by configuring each service one at a time inside their respective UI interfaces which will be located under Administrative Tools. This blog post won't discuss how to configure Tableau Server in depth, but it will explain the steps involved with each process.

The first step is to open up Tableau's configuration file which can be found at C:\ProgramData\Tableau\Tableau Server\. This is where you'll find all of your server configuration settings including users and groups, workgroup mode, and ports. If you need to modify any of these settings then this is the place where you will want to go first.

After that's finished then it's time to configure Tableau Server by opening up its UI interface which can be found at C:\Program Files\Tableau\. Once you’re inside the interface, it's time to configure your data engine which will be used by Tableau Prep and other services that need access to databases like PostgreSQL, SQLite, Oracle, MySQL, etc. You can do this by using the "Configure" button on the dashboard to open up your configurations.

It’s important to configure which port you’d like Tableau's data engine to run on and which databases it will need access to. Since we recommend that you set up your database server using a separate server instance, we’ll focus on configuring Tableau's data engine. Both Tableau Server and TSM require an available TCP port for you to access them. During installation, TSM defaults to port 8850, and the Tableau Server Gateway service defaults to port 80. Keeping both of those ports open before installation is the easiest way to ensure this goes smoothly.

Lastly, you’ll want to configure Tableau Prep which will allow you to schedule extract refreshes and cleanse our data from the servers. You can do this by going through the server tree on the left-hand side of the UI interface in order to find "Prep Service." Once you've found it then hit on its corresponding Configure button. Tableau Prep has a large number of configuration settings so it will take some time to go through them all in order to get the service configured properly in production. This blog post assumes that you'll be running Tableau Prep on its own instance of Windows Server for each component, but if not then these configurations can also be found by going into the Tableau Server UI interface.

Once you've configured all of your settings then it's time to start up each one of your services so that they can run properly in production. You can do this from inside the respective UI interfaces, accessed under Administrative Tools for Windows or Application Menu for Mac.

Finally, you’ll need to configure Tableau Server so that your users can access it from a web browser. This will require you to have Domain Admin permissions in order for users to be able to authenticate against Active Directory. You can configure this setting by going into the Tableau Server UI interface and finding "Tours & Messages." Once you've found it, click the “Configure” button.

Once you've configured all of your settings, we recommend testing out to make sure that everything is working properly before deploying this instance of Tableau Server to production.

After you've tested everything out and confirmed that it's working properly, you’re ready to deploy this instance of Tableau Server to your production environment! You can do this by copying over your files from the "Staging" directory on your development computer to the "Production" directory on your production computer.

Once you've moved all of your files over, it's time to give yourself access before installing Tableau Server onto your new server instance. You can do this by going into Administrative Tools for Windows or Application Menu for Mac and finding each respective service's UI interface inside their corresponding directories (i.e. Tableau Server UI interface will be found under Administrative Tools on Windows or Application Menu for Mac, etc.).

After you've given yourself access through the service's respective user interface, install and configure your new instance of Tableau Server by double-clicking on its corresponding MSI installer file, which you can find in each respective service's directory.

Once you've installed Tableau Server, then it'll ask for some information about your new instance of the software. These configurations can also be found by going into each respective service's user interface under Administrative Tools on Windows or Application Menu for Mac. We'd recommend taking a look at this blog post to help guide you through the installation process.

This blog post is designed to help you plan, install and configure Tableau Server. It's important that your use case be well-defined before starting this process so that you can ensure the best possible experience with regard to performance and usability for your end users. If you're not sure where to start then just reach out! We want nothing more than for our customers' experiences to be exceptional when it comes time for them to deploy their new instance of Tableau Server in production. So go ahead - let us know if we can answer any questions or provide assistance during the planning phase (or anywhere throughout) by contacting our team here at High Performance Technologies.

Get Started Now

Best Practices for Upgrading Tableau Server

Wed, 13 Oct 2021 16:59:18 -0500

Why You Should Upgrade

As you grow your business and your needs change, it may become necessary to upgrade from the version of Tableau Server that you started with. Newer versions of Tableau Server may introduce new features and if you want to take advantage of those features, then you need to upgrade your server. Other times, there are bug fixes and performance improvements which could dramatically improve your work experience!

Upgrading can be a significant undertaking because many aspects of the current environment are likely customized or configured specifically for the current version of Tableau Server. In addition, there is no “one-size fits all” approach when upgrading an existing deployment; each situation has unique requirements and considerations. The process can also take time—anywhere from a few hours up to several months depending on how complex the environment is—and resources must be dedicated towards this effort during that period.

Creating a Strategy and Plan

Upgrading your Tableau Server is not a difficult process if done right! It's important to make sure you have a strategy and plan in place before starting the upgrade. The first thing that you need to do when planning your Tableau Server upgrade is figure out what Tableau Server version you are currently running. You will also want to collect information on the hardware specs of the existing server and any other software or applications that are installed on it. This way, when you do make a new Tableau Server machine, you can try to match those specs as closely as possible. Tableau Server is installed on top of an operating system, which means that you will need enough RAM and disk space for both Tableau's requirements in addition to the OS'.

Once you have all this information collected together, it’s time to think about what version of Tableau server you will be making. Tableau Server comes in several different versions depending on the components, security features and support that is required for your organization. You should also think about how Tableau Server fits into your existing IT infrastructure as well as other networked technologies, such as Active Directory or Single Sign-On (SSO) systems. This information will be useful when planning Tableau Server upgrades.

You should also make sure you have backups before upgrading Tableau Server because there's always risk involved when modifying such an important system with lots of data and features. Make sure you test the upgrade on an identical instance beforehand so that when it comes time for the real thing, all will be well.

Completing the Upgrade

When it is time to actually upgrade Tableau Server, one of the first things that you need to do is make sure that your Tableau Server machine or machines are taken offline. This means shutting down all Tableau services on each server and then making a copy of the existing data before you start the upgrade process.

The steps to upgrade Tableau Server from here are relatively simple. You will need to download the appropriate installer from your account, and use it to install the new version on a fresh instance of Windows or Linux server.

When you install Tableau Server, you can license it either online or offline. If your server is connected to a network that allows you to access the internet, you’ll want to license Tableau Server online. On the other hand, you may have security or regulatory requirements that don’t allow your Tableau Server to be exposed to the internet or require you to have a proxy in place. If that’s the case, you will need to do an offline activation (you may also find this blog post useful: How to Stand Up a HIPPA compliant Tableau Server). This essentially requires someone to behave as a manual proxy themselves. It’s easier to license your Tableau Server online, so go that route if you are able to.

Once Tableau Server has been upgraded, you will need to migrate your data from the old Tableau server to the new one. Tableau provides a command line tool for this process that is simple and straightforward to use, but some Tableau versions require additional steps. The Data Migration Tool can be used with any version of Tableau Server, but anything older than Tableau Server 2018.x requires that you use Tableau Prep Conductor to migrate data before the upgrade can be completed or on Tableau Data Extracts (TDE) files created with a version of Tableau Server earlier than 2017.

The Importance of Upgrading Frequently

While it can be hard to keep up with the latest features and bug fixes Tableau releases, if you don't upgrade regularly, your server will become outdated and less useful over time, and may even start slowing down or even crashing unexpectedly. Thankfully when you upgrade to a new version of Tableau Server, all sorts of old bugs are removed from the codebase and they never come back!

We recommend creating a schedule to upgrade your server on a regular basis so that you always have the most current version of Tableau Server available. This way, you'll always be able to get the most out of your server environment!

If you’re interested in learning more about whether it’s time for your organization to upgrade Tableau Server, please feel free to reach out. Our expert resources have been working with Tableau for over 13 years and are happy to assist with your next upgrade or helping you figure out how to navigate your evolving Business Intelligence needs. You may also want to consider automating your upgrades as well as your deployments and backups using our infrastructure management service, Vizstack.

Get Started Now