Welcome to everyone. Thanks for joining us today for the Tableau to Sigma migrations, the InterWorks way. Before we dive in, I want to tell you a bit about InterWorks if you haven't worked with us before, if the name is new to you. So we are a global data consultancy working with companies around the world again on their toughest data challenges. We specialize in data analytics and AI, and we partner with many platforms, Sigma, Snowflake, Databricks and so on to help you build those right solutions for your business. You are here today because you're interested in Sigma and that makes sense. We are a Sigma Elite partner and we've been helping organizations with their Sigma migrations this year. Several of us, a consultant like myself and my colleagues, we have completed advanced trainings to become AI app specialists, so we're definitely deep in the space right now. Maybe one quick pre announcement: in two weeks from now, on November 26, we're hosting a follow-up webinar called From Snowflake Data to Sigma AI Apps, and this session will include a practical demo in Sigma so you can see all of these capabilities in action. So stay tuned for that one. I would love to see you there. You should also know that we work across the entire data stack, so whether it's architecture, integration, strategy, optimization of your existing architecture, we do bring expertise across modern data tools and practices, and we're active in the data community and care about helping our customers like you solve real data problems. So that's on IntroWorks. Let's do the rest of introductions for today. My name is Darinke Markovich. I'm analytics consultant at InterWorks and for the past five years I have worked with many clients helping them make the best use of their analytics tools that they have, right? So from Tableau Power BI to now Sigma, and I could see both the rapid pace in technology, but also how actual teams dealt with all of those changes. I'll be your main host for today, taking you through the approach that we have migrating from Tableau to Sigma. I'm also joined by my colleague James Austin, our services director for EMEA, who will say hi. Good afternoon, everybody. Hi, I'm James Austin, often known as Oz. I'm the service director here at InterWorks. I've been with InterWorks for a long time, fourteen years or so, and have been involved in a lot of different tools along the way. But I am loving Sigma at the moment. It's great fun and the possibilities for expansion are huge. So yeah, really looking forward to seeing how Drinker is going to guide us through this one. I will hand over. We don't have a slide for you, Al. I apologise. But we did have a late minute drop in. Al is one of our sort of very deep technical guys involved in the actual migration work. So any of the sort of slightly more technical questions that require proper depth, Al will be our man. Yes, thank you, James and Al. Al, welcome. Good to have you both. And yeah, let's start with the four phases of our approach. So the four phases that we have when migrating between these tools are assess, model and build, validate and launch and support. We start by understanding the current environment that you have and deciding what should move. Then secondly, we will develop the data layer and the Sigma experience, test the results, and then prepare the entire organization for launch. These phases do not come as in like go and stop, go and stop, but they overlap in practice. We do not wait until everything has been built to start thinking about validation or user adoption. The phrase you will hear throughout this webinar is human led, and human led matters here. Tools that we have developed for these migrations are mostly AI based. These AI tools can accelerate the work, but people still need to agree what the business logic means and whether the result meets the need. Then let's have a look at these stages and how we approach our migrations the InterWorks way. Usually there are two paths when we consider migrating between tools, and I've seen this in my daily work quite often. There is the traditional lift and shift path, right? So we say we're done with the one tool, we lift and shift everything onto the next one. And then there's the rethink and rebuild path, which is kind of a newer approach. So if we look at the migration, again we can say any sort, it doesn't have to be necessarily Tableau Sigma, but for our example today. For any migration you need more than just a conversion tool. If you imagine an environment that has grown over several years, and I've seen this with my clients, they usually say, well we have set up our environment based on some guidance from the central IT, and then we made it our own. It grew over the years. We didn't really bother with the cleanup, didn't really bother with documentation. It has grown organically and usually when I hear it has grown organically, it means it has become a mess in some way or the other. So something that has grown over several years. One team creates a calculation in the workbook, another team recreates that in a published data source, someone builds a workaround, a hackaround for some of the requirements a business has, maybe that no longer exists. So each of these decisions, if it was a workaround, a separate calculation logic, each of these decisions may have made sense at the time, right? But eventually you have business logic spread across several places. Some things I also very often hear, you have your own silos, right? Across the teams, maybe sales marketing team, they have their own micrologics coexisting even though they're talking about the same business term. And with time this all becomes difficult and it's difficult to tell which version people should trust. So a migration is also an opportunity for you. It gives you a reason to examine what has been happening so far. So which workbooks still support your business decisions? Which calculations need some common definition? How do we bring those genes all together so we don't have them existing in their own bubbles? Also this gives you an opportunity to reconsider which content can be consolidated. I recently heard from a client that a data analyst from the marketing team was working for six months or something developing in this tool, and then only later over a coffee chat he heard from a colleague in a different department that they've built the same thing just using a different tool because there was a lack of communication and kind of organization in the team. So a migration part will give you a reason to examine everything that's happening in your business. That does not mean you need to redesign everything, right? So some content should move with close functional parity because it already serves users well, that's fine. Some workbooks, some reports have always served your users well, let that continue. But other content deserves a more substantial rethink, so anything that has not been used, anything that is also wrong maybe in terms of your business requirements, and this assessment will help us distinguish between those cases. That distinction will also help shape our migration philosophy that we developed here at TintoWorks. And I will pause here on the statement. So we don't do lift and shift, we also rethink and rebuild. What does this mean? Rethinking and rebuilding means making some deliberate decisions about what belongs in the new environment. With the previous philosophy, lift and shift, right, you just said I have 15 workbooks, let's move everything to your new server, to your new cloud instance, your new BI tool of choice. In this new philosophy, we rethink and rebuild. This does not mean changing every workbook. This will also, you know, result in more work for you. Some content already serves users well and should move with parity in mind, but other content needs consolidation, needs different design. We mentioned those examples where logic might be outdated, some team members might have left the team, you don't have anyone to support it. The important decision is also what the future environment should help people do. Once that is clear, we can choose a suitable implementation plan in Sigma. It is a lot like moving houses, and I will use this analogy because I'm sure many of us will have moved houses at some point. The destination may be attractive, you're looking forward to moving into the new flat, decorating, redesigning, but the transition still needs a lot of planning. I think this is what many of us forget in the process, so we need to understand what we are taking with us and how will it work when it arrives. Let's have a look at that. We will have here Workbooks as Code as that little helper and their capability limitations and why we also need human review. In the beginning of this webinar I mentioned human led and then that AI and automation are used quite a lot, right? So automation can make a real contribution here. Sigma's Workbook as Code capability allow workbook definitions to be managed programmatically, and AI can assist with parts of development process. The supported features and limitations still need to be checked for the work in scope. These capabilities will help execute a migration for sure, but they do not establish what the business logic should mean. My analogy of moving houses again, so if you've ever done this, I'm sure you either asked a neighbor, a friend, or even maybe paid for a service like a moving crew. So each of those options like must have happened that a moving crew came, you gave them a plan and they say yes, we'll perform this tomorrow. A moving crew can pack and transport your belongings much faster than you could on your own, but they still need that guidance, They need instructions about what belongs in the new home, maybe also what belongs where, maybe you'll give them instructions to leave these packages in certain rooms. In a similar manner, a tool can help translate this structured pattern, so it cannot approve the business meaning of an ambiguous metric. So before automating calculations, we need to understand its inputs, level of detail, intended use. So if I've packed my card boxes for a kitchen, bathroom, I'm sure there are different products in these boxes and I would like the moving crew to lead them in certain places and handle with care, maybe have some precious items in there. With the analogy, we can say that the automation can be used where it is suitable, but we still need to check its output and involve people when the source logic needs some interpretation. This is why the human stays in the loop throughout the process. So even if I had that moving crew, would still need to give them proper guidance, maybe be available on the phone if they have any questions, and guide them through the process. With the packingunpacking analogy continued, imagine we have a Tableau workbook. As you surely know, a Tableau workbook contains a lot more than just the chart which is visible on the screen. There are many calculations, filters, dashboard actions that you may have built, and definitely your relationships, data relationships, your model maybe if you have it in the workbook. All of that explains why a particular report behaves as it does and it fulfills a certain need. Understanding all those details will let us distinguish the business requirements from the way someone implemented it in Tableau. If we think again about moving houses, that professional crew can pack everything efficiently, no doubt about that. But imagine opening a box and finding your rubbish bin with the rubbish still inside. Well, you know, they did the job, they packed that item, but was it supposed to be done in that manner? The packing worked, but the decision about what needs to be moved did not. That part did not work. In analytics, the equivalent is carrying an unused report or an outdated calculation into the new platform, and before anything we want to understand the content well enough to avoid that. This is why we have these three stages here written out. So first of all, always, always assess what is the table logic, can it be migrated over, How should it look in the new environment? We unpack, and definitely as the last part, some adjustment needed we need to redesign as well. For this process to work, we need knowledge across, right? So we need knowledge of Tableau, which will help us unpack the existing logic, but also knowledge of Sigma, which will help us decide how requirement should work in the new environment. This approach we have implemented or kind of translated into a set of migration tool that I would like to introduce. The three tools that we have developed in the migration process are Scout, Atlas and Waypoint. The toolset has three complementary roles, if I may call it like that. So the first one, scout, as the name says, but kind of gathering information or you send out a scout to do those initial steps. So in our case that same tool, Scout, supports the assessment. So it will help us understand the Tableau environment that you have, and it will help us plan the migration. The second tool, which is called Atlas, will support the consultant delivering the work. It helps identify where automation is useful, but also where hands on development or hands on decisions are needed. After those two tools comes Waypoint. Waypoint will make all of the progress and decisions visible. It gives you, the clients and delivery teams, so consultants performing the work, a shared place for feedback as the migration moves forward. And taken together, these three tools will support the process from initial assessment from the very early stages, through the development, that iterative step by step phase, and into the review. And then let's look at each of these InterWorks tools in more detail. First up comes Scout. So what Scout does, it supports the assessment stage, as I mentioned. It will help us examine your tableau state, your workbooks, their complexity, their compatibility and volume measures so we can build a more informed migration plan. You can see here on the slide how that assessment could look like. So based on your data complexity, the complexity of the actual dashboard, so the user interface complexity, and we kind of assess from there. We use the assessment, so some reports like this, to explore at least three practical questions. First of all, what can move relatively straightforwardly, right? So where we don't need to think twice or do additional work. Sometimes it is one to one migration. Then we think about what is likely to need more hands rebuilding, so one of our Sigma developers comes in. And then where do we need to investigate the underlying data before we Then begin? Maybe there are like third dependencies that we haven't thought about, anything like that. When we try to prioritize what comes first, it's not always the matter of complexity is priority. That's only one part of the decision. We also need business context. So for example, who uses the workbook? Which decisions depend on it, Is this really the decision makers who use the workbook? Is it operational dashboard? And what would happen if it were unavailable? Because we have reports like this, if it does not load at 7AM in the morning, production can stop and you not just might, but you will lose money and precious time. The purpose is to reveal also the likely effort in this assessment and the questions that we need to resolve, so we want the project plan to reflect evidence about the environment. Once we have an overview like this, we can then investigate individual workbooks and priorities. Moving on with the assessment tools. The assessment becomes useful for some, let's say, specific decisions. So I can here drill into the factors that make a workbook more complex and identify where I need more discovery. So here, tier one, a little logic to render a few sheets. This would be like that one to one migration, nothing too much to think about, not as complex, but then I do have that complexity rate increasing. A relatively small group of these workbooks may account for much of the effort. It's almost like the eightytwenty rule, right? So maybe 80% of those workbooks are relatively straightforward and it's a one to one rebuild. But if you come to those remaining 20%, you discover they do take a lot more time. We want to identify those early because they will need additional discovery, they will need discussions with the team and those validation cycles. When I mentioned complexity, complexity alone again will not tell us what to migrate first. I will combine it with my business importance, usage and ownership. From the example that I just given, an operational dashboard, something urgent and critical that needs to be always visible, available to the team, will deserve my utmost attention. But a workbook with little recent activity may be a retirement candidate, so this is why your migration is also an option to again reassess what estate you have, what can be retired, sunsetted, and what needs to be rebuilt. To that note, I also want to mention that, you know, if a workbook is a retirement candidate, this does not mean we'll just shut it down. We will still ask the owner whether it supports seasonal or regulatory need, because definitely we have instances or workbooks. Maybe it's an auditing question that every start of the year you need to have access to this report analysis, and then if you look at usage, might look that it's not as often used, but actually it does sit high on the business needs. So for each of these use cases, the decision may be to retain and rebuild, consolidate, redesign or retire. The aim is a scope of sorts that will reflect what the organization actually needs. We've spoken about that AI led, programmatic, but our approach is always look at what the organization actually needs. When we have those decisions, these will feed directly into a delivery plan of sorts. So let's have a look at that. Once we have all of those assessment outputs, SCOUT, ATLAS Waypoint and other considerations, we also want to feed that into a project plan of sorts, And these delivery milestones and your or client responsibilities like the other team who's involved. First step is always understanding the environment and then we can organize all of this work into manageable waves, if we can call them, or work streams as we can see here. So from technical advisory, that cloud data analysis, and the last one being waypoint progress tracking. For each of the workbooks or use case, we will decide whether to retain and rebuild it, consolidate related content, redesign or again sunset. We will identify the owner and dependencies on data preparation, shared definitions, then and the delivery plan follows, So how we document, how we triage and track is also part of that plan. Then let's have a look at Atlas, that second tool in the migration process, and bring us back to that human in the loop in a plane example. So Atlas is a tool that supports consultants carrying out the migration. In the framework that we have here at InterWorks, it will bring together migration capabilities and guidance to help determine what can be automated, but also where hands on development is needed. The work is still guided by people, so we need to understand the meaning of our calculation before deciding how to reproduce or improve it. If I had to introduce Atlas in a different way, I can say it is both an aid, a helper, small helper to execution of that plan, but also a helper to decisions. It will support the delivery consultant working through each of the workbooks, identifying suitable automation points, any areas that need to be rebuilt, but also questions that might need further review. From the previous slide when I mentioned documentation, this is what Atlas exactly does. It will support the documentation part, which I'm sure is a sticking point for many teams. We usually need to act fast and quickly, and we don't really have time to document everything, which is where a tool like this is really beneficial. So Atlas supports documentation, but also prototyping. That will help the team explain what changed and gives the client later, like after the project has been done, some material they can use after the actual handover. The delivery consultant on the project will remain responsible for checking the output of this tool, and of course making sure it reflects the agreed requirements. For the next part, let's maybe make that boundary between automation and judgment even more concrete. And as it says here, the automation does not need or like it really shouldn't replace judgment. We have three scope decisions, which is keep, consolidate and retire. As an example for you, if you imagine you have two workbooks that both showed revenue but might use different date fields or different exclusions. Or in my example, I had sales and marketing team kind of arguing over a definition of what does a lead mean for a sales team and their pipeline. It's really something different than a marketing team might look at, even though a common term is that lead, but they do use different date fields. For both sales and marketing team, converting their calculations will preserve the disagreement, we need the business owner to explain whether those differences are intentional. So if they are intentional, of course marketing lead and sales leads are two different things conceptually, we document that distinction. If they are not, if this is a mistake of sort, we will agree on the required definition, maybe a common one definition of that lead, and we record the change before we ask people to validate the result. A tool like Atlas also supports documentation and prototyping involved in rebuilding content. That matters because a migration creates decisions that the client team will need to understand after the engagement ends. Across the wider environment in that team, in that business, the same review can reveal overlapping data sources, duplicated definitions. So when I mentioned when someone says our data estate grew organically over time, it usually means is some duplication of effort and business logic. We make initial scope decisions before rebuilding and revisiting when discovery reveals new information. So here automation doesn't replace judgment. Automation will help with repeatable and understood work. When the meaning is unclear, we will involve the owner and resolve the question before treating the output as correct. So it's never a matter of I have translated or automated or programmatically done something in this migration, but always involve the business owner and resolve the question. Does your understanding of lead mean the same as the understanding of a lead? If so, then what do we do about it? In the next part we then coordinate the data model and workbook development. So definitely here we have two tracks. One is data modeling and the second is sigma development. And these are never again go and stop, stop and go phases. These phases are usually done in parallel. We follow both tracks. The delivery work will always work best if it's coordinated, if this is an iterative activity. So if I've developed something and the business logic does change and there's another decision behind it, of course we will in this sort iteration maybe go a step back, reassess and then continue developing. So in that sense, always, always iterative activity. We still respect dependencies, so a workbook might need a suitable data source, but thinking about this, you do not always have to complete the entire future data stage. Usually these are ambitious decisions and something to develop over the next two, three, five years, so you do not need to have the complete data, your data warehouse ready in that sense before delivering the first useful SGMA workbook. We can start with a priority use case, develop the data it needs, then we build the sigma experience and review both together side by side. What we learn will then form the next wave or work stream in that delivery plan, again iterative experience. What this also gives us or gives stakeholders something concrete to react to. It keeps them involved. It will help them, us discover early whether a metric definition, level of detail, any report interaction needs more work. If we return once again to the moving house analogy, you would not automatically again put your desk in the dining room just because it was there in your original home, this is where it fitted. Maybe you have a separate room in your new flat, right? Just office room for that. You will look at the new space and decide where it works best. The same reasoning then applies here. We preserve the business purpose while also choosing implementation that fits the new environment. So always side by side looking at the data state, preparing but also developing in Sigma. I'm sure you're also wondering at this stage if we say data warehouse or like how these two tools work together. Performance belongs in these early iterations too. We should test those early queries, user interactions, if everything is loading up correctly and instantly, and again against realistic data volumes. So if the architecture changes, we need to understand the effect on all of those subsequent queries, time, concurrency, compute usage. These are all relevant topics. The benefit of this approach, you know, modeling and building in parallel, is also earlier feedback and that visible progress. Then we have a chance to resolve issues while the scope is still manageable. What else I have here mentioned? Legacy sources move through bronze, silver, gold. This is an example of one layered data approach. I do not see it with all of the clients, but the actual architecture should fit the client's platform and your governance requirements. As these two phases progress, what else we would need? We would need a shared view of decisions and feedback. And this is Waypoint, the tool I've introduced earlier. As that development moves forward, everyone will need a shared view of what is happening. Who needs to be informed, who needs to see this, and this is the role of Waypoint. Waypoint is actually a Sigma app that we have developed here at Intoworks, and it is deployed on a client's Sigma instance. It will give both the client and the InterWorks consultants a shared live view of progress with room for feedback along the way. It provides a place to track migration process, document any decisions, and collect feedback. This is all especially useful when the result intentionally differs from the original Tableau workbook. Where do you track those decisions as they happened? Perhaps we have consolidated two reports, we moved calculation up upstream, we changed those dashboard actions and navigation to suit Sigma. Where do we track all of this? And reviewers as well need to understand why that happened, why was a decision made. Without the context, an intentional design choice might look like a mistake. Why does this look like that in Sigma? We get it done other way in Tableau. So it can look like an error, like a defect, and you will have these repeated discussions over time, or several times, just not needed. The shared review that Waypoint offers us will also make it easier to see what is ready for testing, right? What is waiting on decision? What is blocked? And what has been accepted? So in that kind of Kanban order. The most important principle is definitely traceability. The team, my client teams, my team as well, should be able to follow from the requirements that we had through implementation, those feedback round iterations, and then into approval. And speaking of approvals and kind of leaving everything in the client instance, all of these records, everything that we see in Waypoint will become useful handover material, that documentation we mentioned, and the client will take full ownership of the migrating environment and instantly, right? So there's little time needed for you to kind of again onboard because you have that handover material, you have the documentation, and you've been involved throughout. Because Waypoint is deployed to the client Sigma instance, it is saved there. It is an artifact and it will log all of those decisions that we made on the way. So once we have the visibility via Waypoint, let's look at what we actually validate. What do we validate? Data parity, workbook parity and end user functionality. When I say validation, this also needs an agreed definition so everyone understands the same thing under validation. We look at the data and calculations. We look at whether users can complete the task the workbook is meant to support. So sometimes it's not a matter of does this look and feel the same in the new tool, it's a matter of this decision maker can they perform their work the same way they did when they used Tableau workbook, that other report. For the data parts, we compare agreed measures at the appropriate granularity, that level of detail. Are we using consistent filters, date ranges, source snapshots where possible, and we investigate any discrepancies rather again than assuming matching total proves the whole workbook is correct. Sometimes that's not an easy way out or easy answer. If logic has moved upstream, some of that testing can happen before data reaches Sigma. That helps us isolate whether issues are coming from the data model, the calculation or the presentation layer. Or functionality, we check the interactions that matter again to users, so what are the user relevant filters, navigation, drill down paths, any other required report actions that they need to make. The implementation again may differ, but the intended business task still needs to work. Again here's another important distinction. We may agree to change a metric definition, redesign it at some point, and maybe a dashboard action is something else in the SGMA workbook. But again repeating that this change needs to be documented and approved. And again a mismatch will not be acceptable just because you know previously you had Tableau, now you have Sigma, it's a different tool. For that workbook parity, we check that calculations and presentation support the agreed business requirements. So a similar looking chart, again this is not just user interface, not just looking at pretty charts, so a similar looking chart alone will not prove that, will not be the parity that we want to achieve. For the end user functionality we test the tasks where people need to, like what do they need to complete in their day jobs? What is the end user functionality? And again, the implementation may be different in Sigma, but the required outcome needs to work. If we come to different decisions on the way, again needs agreement from the team and something that we track. Alright, we looked at what gets validated on the way. Then let's pause quickly on this part. Legacy logic is really neat. You have to be ready to confront it. How do we resolve that ambiguity? So a migration that's moving houses parts will also reveal inconsistency that's existed over the years or have grown over the years organically. Maybe two reports use different definitions, the original calculation no longer has the owner to explain it, we need to confront all of these ambiguities. Maybe that mess that was made along the way, so we identify the owners, establish what was meant to be the result, and we record all of the decisions. Again, we do not silently copy over errors and we do not silently correct errors, like in our view if we say this needs to be corrected. All of this again needs approval and that human in the loop, as mentioned earlier. So throughout the delivery we manage all of these reviews rather than saving them for the end, the iteration part of it. For the final validation and sign off, we have this image maybe like if you wanted to track, you could trace a workbook through three stages, so like testing, feedback and sign off. So if not if, but like as this workbook becomes ready it moves into testing, and different workbooks can be development, review, acceptance at the same time, so it does work in parallel. Where possible the original owners or the relevant subject matter experts can review the results. We give them clear criteria, capture their feedback so the team can resolve issues and record acceptance. This helps also build confidence before that cut over, so users will have a chance to see the new environment and raise any questions while we're still implementing and while there's still time to respond. By the launch date, the required content should have completed the agreed checks and approvals, and the rolling sign off makes the process more manageable and reduces the risk of that last minute backlog, last minute call. What does this all mean? No, we do not need that because you've been involved throughout. So also how do we plan for the old environments and the ongoing support? Here I can introduce another tool that we have called InterWorks Assist for our support. The Tableau sunsets, or like you know, shutting down that environment, this belongs in the migration plan as well. We'll identify the remaining dependencies, prepare your users, agree the retirement schedule for any subscriptions, scheduled outputs. We confirm the replacements and we test it. And again, we're not assuming anything and we should not assume that everything transfers automatically between the two platforms. Before cut over, we confirm, you know, again these questions around access ownership, acceptance and route for reporting issues. On our end we have the IntraRux Assist and Sigma Builder office hours as possible support options, and the scope and availability can be agreed for each of the engagements. I like to introduce InterWorks Assist as that, again, helper if you're working on a very particular technical problem and you're just thinking, if I only could call a friend, someone to help me, someone technical subject matter expert, and you have it by your side to support. This is InterWorks Assist. When I mentioned support, we should not forget the actual users and their experience and where the change management comes into place as well. For users this will definitely be a substantial change from one tool. They relied on every day of their business hours. Right? And now they need to work in a different environment. We need to explain to them what is changing and give them time to learn to adopt this new tool. Sigmund has different workflows and interaction patterns. It's a fairly complex tool in some ways, so we should definitely show these differences openly, explain how people can complete their familiar tasks here. For the change management part, the communication will always start before the launch date. So your representative users will take part in reviews, so that cut over again is not their first encounter with the tool, they will have seen it multiple times throughout the process. Particularly builders will need practical experience with the data model and maintenance responsibilities, but then on the other hand you also have your viewers, your report consumers, who will need guidance on finding content and using the new environment for their own work. This is why the enablement part, the change management part runs again alongside the migration. We have technical work which creates the environment, but also then we have that support and then adoption that will allow the organization to benefit from it. All right, well this brings us to our last part of the webinar. I will open the floor for any questions that we might have. We covered assessment, modeling and building, validation, and launch and support. And then across all four parts of this migration process, the aim is to make informed decisions about the content that you have, but also help people succeed in your new environment.
