Okay. Thanks everyone so much for joining us today for Tableau to Sigma migrations the Interworks way. Before we dive in, I wanna tell you a little bit about Interworks. Some of you might already be customers of ours. For others, this might be our first time meeting. We are a global data consulting firm working with companies around the world on their toughest data challenges. We specialize in data and analytics and AI, and we partner with best in class platforms like Sigma, Snowflake, and Databricks to help you build the right solutions for your business. You're here because you're interested in Sigma, and that makes sense. We are a Sigma elite partner, and, this year, we've been helping a lot of organizations with their Sigma migrations and AI app use cases on the platform. One quick note, we are in the middle of Sigma September, where we're running a four part webinar series this month. This is our third of four sessions. We've got one more coming up next week, covering Snowflake and Sigma working together. We'll share some details about that final session before we wrap up today. You should also know we don't just help with Sigma. We work with your entire data stack, whether it's architecture, integration strategy, or optimization. We bring expertise across modern data tools and practices. We're active in the data community and genuinely care about helping customers solve real data problems. A little bit of housekeeping for today's session. We are being recorded, and we'll send you the replay to the email that you registered with in a few days. We're going to try and cover all of our content first, which should take thirty five to forty minutes, and then we'll have time for Q and A at the end. Don't hesitate to put any questions that you have in the chat, and we'll answer as many of those questions as we can when we get to the end of the content. So with that, let's do some introductions and then dive into content. I'm Matt DeCarlo. I'm a solutions architect here at InnerWorks. I help organizations push their data and analytics priorities forward across a variety of tools and use cases. Currently, I'm focused on all things Sigma, migrations off of legacy BI tools, creation of AI apps, development of internal tools that make our work here at Interworks more efficient and more effective. Before joining Interworks, I worked in the finance, marketing, healthcare, and retail industries, building data analytics platforms and solutions for the companies that I worked for during that time. This is a very exciting time in the analytics space. I'm feeling really energized by a lot of cutting edge capabilities that tools like Sigma are bringing to the market, both natively on their platform and also integrating with AI. So really, really amped to talk about our content today and all things Sigma. I'll hand things over to Jackie now to introduce herself and she's gonna get started with the content. Go ahead, Thanks, Matt. My name is Jackie Harris. I'm also a solutions architect at InnerWorks. Like Matt, I spend a lot of time thinking about BI tools, data warehouses, and AI, and how we can help organizations and people use these tools successfully. Prior to my time at InnerWorks, I worked in the federal government. I spent ten years in the CIA working on all kinds of data problems, as you can imagine, and then another three years at the Idaho National Lab looking at risks in the nuclear reactor supply chain. But today, we're not gonna talk about that. We're going to talk about migrating BI environments from Tableau to Sigma. At InnerWorks, we've been Tableau partners for twenty years. As the industry has changed and shifted, we have as well. Earlier this year, as Matt mentioned, we were named one of Sigma's first elite partners. We've worked with clients to migrate their BI environments. We've built out AI apps to replace workflow tools, and we've provided hours of hands on coaching, enablement, and co development. In our Tableau to Sigma migrations, we've worked through the processes and adjusted their growing pains, and we now have a migration framework to support our clients as they make the exciting transition to Sigma. We're going go over that framework in four phases. How we assess the migration before we get started, how we model and build in Sigma, how we validate the data and the reports, and finally, how we help launch and support your team as you jump into a new BI paradigm. Throughout this webinar, we'll repeat our overarching migration ethos a lot. We see migrations as an opportunity, and we want you to come away from this conversation fully understanding that a lift and shift migration is not a path for long term success. At Innerworks, when we talk to our clients about moving to a new BI tool, we'll always recommend that they take their time, evaluate their current state, and move forward with a plan to take full advantage of the new tools capabilities. Automated tools and a suite of AI skills may tempt people to simply port content from one tool to another, but we argue that there's a better approach. Keep in mind that after years of working in one environment, it's almost certain that things have gotten messy and that the logic is less logical than we'd often like to admit. As hard as we try to keep data and logic consolidated, it's almost certain that there's data sprawl lurking in your environment. We want to encourage you to use the migration as an opportunity to rebuild with a clear end goal, clean up your technical debt, and move your organization and your people forward with confidence. Lift and shift is a fundamentally different approach from rethink and rebuild, and we'll walk you through the differences. It's important to remember that usually a migration is happening for a reason. It's exciting to roll out a new tool with room to grow. Sigma's capabilities and features are genuinely exciting and impressive, But the move has to happen first. As anyone who has moved houses before knows, the transition can be daunting. In the midst of the uncomfortable in between space, it's important to remember that the gap isn't in Sigma, it's the assumption that any migration will be simple, even a migration enabled with automated tools and AI capabilities. Just like with any big project or move, planning and an experienced crew make all the difference. We encourage you to look at your migration as a one time chance to fix a semantic layer that's grown messy over the years, not just recreate it elsewhere. When we talk about migration, it's easy to jump ahead to the new tools and capabilities. There are a lot, and the space is changing so constantly that it can feel hard to keep up on what is actually feasible with automation and code. This is where it's helpful to have experts on board. Sigma offers Workbooks as Code, which is an amazing capability. With that and AI, migrations can move fast. But the danger comes in when you start to think as automation and Workbooks as Code as a way to lift and shift. Remember, we still want to migrate with intention. We want to take the time to rethink and rebuild. One thing we always come back to at Innerworks is the humans. It's important to remember that tools are almost never the full solution. An easy analogy that almost everyone gets is moving houses. When you rent a U Haul, you're not removing the need for planning a prep. Sure. Moving a bookshelf with a U Haul is clearly the better choice than using your Subaru or asking your neighbors down the street to come pack boxes, but it doesn't account for the full process of evaluating your stuff, deciding what to keep and what to donate, and packing up your boxes. All of that has to happen before you load up your truck. Workbooks as code and AI capabilities are the same way. They can make the process much easier and save a ton of time, but the people using the tools need the full understanding of the underlying logic, the goals of the data, and the priorities of what the migration actually are. To continue with the analogy, years ago, I had the benefit of seeing my whole house packed up and moved by professionals. It was exciting to know that I didn't even have to put my stuff in boxes, let alone carry it out to the truck. I was told over and over again that I still needed to get organized first. People told me that the movers will pack everything, and I did my best. I organized every room of the house. I made many, many trips to goodwill. I felt like the house was in excellent shape. I had sticky notes everywhere. But still, when the movers came, it felt like a tornado. I remember they showed up about an hour earlier than I expected, and it was chaos for an entire day. I couldn't keep my eyes on everything. I lost track of all my organized piles and stacks. I had no idea what was packed in the end. Weeks later, when I finally got my stuff in my new house, I had to just laugh. We opened one box, and it included a full trash can. The trash can with the trash and the trash bag inside. Luckily, it was mostly paper trash and not anything too gross, but no one had bothered to look. The movers also packed a huge stack of brown paper leaf collection bags from my back deck. I was moving to a tropical city that did not have a fall season on the 5th Floor of a condo. I had no need of leaf collection bags in my new place, but the movers really had no reason to know. The point is, movers make silly decisions because they didn't know my stuff or my destination. I had the top of the line tools for the move, but still mistakes and silly things happened. So now we'll take the analogy back to migrations. Innerworks built its reputation as a Tableau export expert for years. We know the environment you're moving from. We know Tableau inside and out, and we have the tools and expertise to pack the content in the correct way. We also know Sigma. As one of Sigma's first elite partners, we're already experts in the destination as well. We know how the tools work. We know how it's similar and different from Tableau. The overall user experience is different, and the capabilities branch off in vastly different ways. Leaning on a team that knows how to make the most of these differences is key. In the next few slides, we'll talk about how we've used Tableau and Sigma to develop tools to assist you on your migration journey. As I said, we've used our experience in Tableau and in Sigma to build out a suite of tools that our customers can depend on. We'll start with Scout, which looks ahead, finds the risks, and delivers a roadmap. It's built on the full context and years of experience that Innerworks brings to migrations. Atlas is our guide that our consultants use throughout the migration. It helps them incorporate fast changing Workbook as Code capabilities and navigate between automation and hands on development. Waypoint gives our clients a place to see exactly how the work is going. They can document the decisions that are being made and provide feedback at every step. With these tools, migrations can go from a big overwhelming idea to a visible manageable project with a clear roadmap. First, we'll dive into Scout, which as the name implies, is our tool for going out ahead of the migration to assess the complexity and make a plan for those coming behind. Scout breaks down each Tableau workbook in your environment by complexity, compatibility, and volume metrics. We can evaluate which workbooks should move first, which will require hands on time to rebuild, and where we need to look at the data layer before we even jump in. As automation and AI skills are evolving, migration complexity and compatibility will also evolve, but it will always be important to assess relative complexity of workbooks and migration effort for the planning purposes. We can use Scout to look at places where technical debt has accumulated and where logic needs to be moved before we even begin. The point of Scout is to go into the migration with your eyes open and a plan, not a guess at how things might proceed. From this high level view, we can then drill down into specific tiers for the migration. We can see the factors that might increase the time spent on any specific workbook or dashboard. We can help our clients make decisions about prioritizing highly viewed workbooks and leave behind content that hasn't been updated or viewed in months. Most of us know the eightytwenty rule, and we see it holding true in our migrations. A small share of the workbooks generally hold a significant share of the complexity. The Scout process helps us identify these heavy lifts early, where we may need to spend extra time rethinking how things are built and thinking about the ways that we can take advantage of Sigma's capabilities in the future. We look at places where logic should be moved to a Sigma data model or a cloud data warehouse. We also consider that complex workbooks will need extra cycles of validation and feedback. We make sure everyone understands the data and the reasons behind the migration scope. The data from Scout then informs our project plan. We can front load our migration work and plan for iterative development when extra complexity calls for it. We can also map out any use case redesigns. We will also dig into where in the process it makes sense for client enablement and training. Remember, we don't just migrate the content, we bring the people along with us. Migrating the InnerWorks way is much more than just pointing a migration tool at your BI environment. It's a plan that helps your team rethink your data and BI space. It gives you room to clean up technical debt, and it enables your people as you go. After we develop the project plan based on the data from Scout, we move on to an active engagement, and this is where I'll let Matt take over. Thanks, Jackie. Jackie just gave a great overview of the Scout tool. And from here, when we begin a migration, we shift our focus into using the Atlas tool. Atlas is a AI enabled tool package of capabilities that guides our consultants through the migration process, workbook by workbook. It indicates what can be automated, what might need manual intervention, And it's both a migration automation tool and a decision aid for consultants. People use these tools. So people plan the migration. We have to keep people in the loop by design, not as a fallback when automation fails or doesn't produce the outcome we anticipate. So Atlas is always retrieving the latest and greatest single migration skills as they're released. It also arms consultants with additional tools to document and prototype workbooks that need to be rebuilt or rethought, and generates documentation that we can hand off to the clients, the customers, the recipients of a migration at the end of the migration effort. Thanks, Jackie. All that said, Jackie already mentioned it, but automation doesn't replace judgment. We want to surface some overlap and redundancy across existing data sources and semantic layers if they exist, we can use Atlas to help us do that. We can generate a clear path of what's worth keeping, what's duplicate and may need to be consolidated, and what's deadweight unused content that can just be retired and not moved at all. These decisions happen before the rebuild starts. It can also happen ongoing as we discover more. AI skills and Workbooks as Code approaches can do real heavy lifting in specific well defined scenarios, things that are guaranteed to be things that need to be migrated in close parity from Tableau to Sigma. But the reality rarely arrives as a neat asset ready to be converted. Logic is often spread across systems at different levels of granularity, and sometimes logic is held by someone who hasn't worked at the company in five years, and we need to understand what was done and why it was done before we just push a button to migrate it. And that kind of logic should be understood by a person before a tool acts on it. That's the part that an easy button automation can't and it shouldn't do. Next slide, Jackie. Data modeling and Sigma development in our framework run iteratively in parallel, not sequentially. Sequencing data modeling first, building and executing a Sigma migration later, is what can slow migrations down and make them more expensive. Our framework targets your highest priority reports and workbooks first to be rebuilt in Sigma as the data layer that supports it is developed and ready. And the goal here is to create momentum throughout the migration. Going back to the example that Jackie shared about moving, when you move, you don't necessarily replicate the layout of your old house in your new house. Just because you made your home office in your dining room in your old house, doesn't mean that your office should be in the dining room in your new place. You might have a dedicated room for that new office. You have to plan ahead and decide where you want that office to be and where the floor plan supports an office. The same holds true in modeling and building in parallel, right? We can't just blindly follow the same path that existed before. We need to pause, consider, and make informed decisions. You can go next, Jackie, thank you. So, while we are using Atlas, while the consultants are using Atlas to execute a migration, we also have a tool called Waypoint that helps us track progress of the migration. Waypoint is a Sigma app that we have developed here at Interworks that is deployed on a client's Sigma instance. It gives both the client and the Interworks consultants a shared live view of progress with room for feedback along the way. Because Tableau and Sigma are different tools, we will make best practice decisions during the migration about where Logic will live and how dashboards maybe will evolve from Tableau to Sigma. We can't lose sight of those decisions. They're important decisions and we need to keep track of why we made them. Because Waypoint is deployed to the client's Sigma instance, it serves as an artifact of those decisions along the way and all the work that was done during the migration. We use Waypoint further to communicate those decisions with the client And we allow it to provide us feedback during testing and validation of workbooks as they are deployed. We don't leave review and feedback to messy emails, spreadsheets, things like that. We use Sigma to migrate to Sigma and to track progress and validation along the way. Next. So what are we actually validating while we are doing a migration? We validating data parity. We know from our experience that the work that is done in Tableau to create a Tableau data source is not necessarily always the most performant or a best practice solution for how data should be built and leveraged in Sigma. So when possible, we do modeling and validation upstream in the cloud data warehouse, especially when we are migrating also from maybe a legacy system into a cloud data warehouse, as well as migrating to Sigma. We do that validation to confirm data parity so that by the time data actually reaches a workbook in Sigma, the validation on the front end UI is a lot more straightforward. And validated literally means that the data and the UI have parity against the original Tableau source. It's not a confirmation of one to one exact matching. Parity means, are we achieving the goal of the migration, retaining the important aspects, and also considering how things will evolve in a new BI power event. This is a standard formal step in every migration. It's not an optional add on. Modern validation doesn't need to wait until Sigma to start. We can do some of that validation upstream and make sure that we are mitigating any chance for surprises along the way. The last part of validation is end user functionality. We know that Tableau and Sigma are fundamentally different tools, but an end user may still need to filter on an object, right? We still need to have maybe some general navigational elements retained. We need to have action buttons still the same. We still need to allow the end user to extract the value of the workbook while understanding and accepting that we are in a different tool altogether. Jackie, you can go next. Thank you. So this is a little bit of a hard truth, right? Legacy logic is rarely neat, as much as we try to make sure that all of our analytical decisions are sound and done with best practices, that rarely is often a 100% the case. So part of migrations is being ready to accept some ambiguity, not chase perfect one to one matching on every single calculation or on every single UI. A lot of times these migrations surface misunderstandings not best practice logic that were built in the past. And we want to surface those and we want to confront them. We don't want to blindly pass them by and accept them. So a validation plan with defined checkpoints is what keeps the migration on track with reasonable expectations, given the hard truth of needing to pause, consider what the right thing to do and the best practice is during a migration. Next, thank you. Validation often can, and sign off can often take a long time. It is generally iterative. There is feedback loops. We have to wait for folks to review things and send messages and reply. At InnerWorks, we execute validation and sign off on a rolling basis. These are parallel lanes staged by client priority workbooks as they are being developed and deployed on the client's environment. Because we are doing validation and sign off all along the way during the migration, We are getting sign off and we're getting buy in before the code over happens. We want to eliminate the possibility for any surprises that might come up right before your Tableau contract ends, for example. This is as much of a trust mechanism as it is a QA step. We want to build trust in the new system, in the new paradigm, while we are executing a migration. We don't want to pull a cover off of the migration at the end and say, ta da, force everyone to adapt immediately right at the end of the migration. We want to bring your power users, your end users in early and make sure everybody feels comfortable with the direction of migration as it is going. We'll talk about change management in a couple of slides, but this is often a good stage to bring those end users into the process, ease that transition into the new platform, create excitement, and create buy in. Okay, Jack, you can go next. There's a fourth tool that we often suggest and recommend as part of our migrations that is not a migration specific tool, and that is Interworks Assist. So the formal sunsetting and decommissioning of your legacy BI environment, Tableau or whatever it may be, is planned as part of our migration engagement. It's not left for you to just figure out after the engagement ends. So, we offer support options for every engagement. Once the new environment is up and running, users are using it, and the client team has adopted that new system and is managing it. So, Interworks Assist and Sigma Builder office hours kind of are really great complimentary offerings that we provide to help ease that transition into the new tool, both for your power users and for your end users. So now I'm going to hand the mic to Jackie to talk about that change management aspect of the migration process. Jackie? Thanks, Matt. We keep coming back to the same point, but I'm going to repeat it at least one more time. Migrating the InnerWorks way means more than simply lifting and shifting your content. It also means remembering that humans are part of the process. You're migrating a system that potentially hundreds of people use every day. You're switching from one platform to another. It's a huge transition, and we all know that change stresses humans out. Migrating the InnerWorks way means approaching the change with intentional communication and change management, not just technical delivery. The world looks different on the Sigma side, and it doesn't pay off to gloss that over. If you don't bring your end users along, you're wasting the migration effort. You don't wanna leave space for your users to create bad habits and take shortcuts because they don't understand the tools and the capabilities. We recommend taking the time to communicate your plan to your users. Build in enablement and coaching for your builders, but also keep in mind your viewers and the changes they'll see in the new platform. Sigma has a lot of capabilities. It can do a lot of cool things, and it will pay off to bring everyone along with you as you migrate. At Innerworks, we get excited about learning new tools and capabilities, but one thing remains key, remembering the humans behind the tools and make sure they're coming along with you. Matt, go ahead. Thanks, Jackie. Yeah, so we're gonna open the floor now for any questions. We have plenty of time left to have a conversation, to talk about any of our tools in more depth, or address any questions that the group might have. We will, you know, wait for a minute or two. We don't have any in the chat yet, so maybe if nothing comes in in the next minute or so, we will wrap up and send out the recording after the fact. And if you are interested in moving to Sigma, if you have questions about your Tableau environment, we have the URL for our Scout tool on the screen now. That page will take you to just more information about Scout and how we think about migrations. You can reach out to us either via the website or reach out to us here, and we can provide you with the token that will allow you to upload your data so we can start an assessment. So please reach out if you're interested in that. K. Doesn't look like we have any questions. So thanks to everyone so much. Oh, we actually do have a question. Just came in. At what point in the Interworks process would Snowflake Databricks come into play? That's a great question. It comes in at the very beginning before we do any work. We know that Sigma requires a customer to be on a cloud data warehouse, whether that's Snowflake or Databricks or Google BigQuery or choose your tool. If you are not on a cloud data warehouse today, our whole process brings that along with you. You can choose to stand up your instance, SaaS cloud data warehouse yourself. We can also offer tools and enablement to do that with you or for you. But Sigma requires a cloud data warehouse to be deployed, right? So that would occur immediately before and in the very beginning stages of a migration. Anything to add to that, Jackie? Yeah. One of the things that we assess during the scout process is where your logic lives. And so oftentimes that involves a conversation about whether the logic going forward is going to live in a Sigma data model or whether it makes more sense for your organization and your goals to move that up to your cloud data layer if it's not already there. So that's part of the conversation. Again, it's kind of a back and forth as we dig into the data and look at where the logic lives of what steps might need to happen and where optimization can take place. Okay. We have another question in the chat. How do you advise customers who maybe extract heavy in Tableau for performance get prepared for live queries to the warehouse. Specifically important to maintain high performance, it also changes the cost equation. Absolutely true. It's important to keep in mind a couple of things. One, extract heavy Tableau environments have their own costs as well, and we have found in practice at least, that for the vast majority of customers who are extract heavy in Tableau, that shifting to a cloud data warehouse with LiveQuery ends up being pretty close to a net even cost change. So that's one side of the question. The first part of the question is performance. So this is a perfectly relatable question to our content. That means that talks about not just clicking a button and lifting and shifting your old Tableau data source that maybe is, 100,000,000 records and two fifty columns. This is an opportunity here to pause and say, how should we modify our data model here in our cloud data warehouse to improve that paradigm so that we can maintain high performance or even exceed performance. There are also tools in Sigma that help to kind of cross the bridge of everything being a full live query to the data warehouse. So things like view materialization in Sigma is a way to actually cache results of a table so that we're not hitting the cloud data warehouse every single time a workbook is loaded or a filter is applied. There are kind of ways to mitigate and avoid that live query every single time if it's not necessary. So there are tools and components in place that we can leverage to make sure that performance stays top of mind, but also again, pause and say, just because we were doing it this way before doesn't necessarily mean we should have a 200 column table with a 100,000,000 records in our new paradigm in a cloud data warehouse. Maybe that looks like some distributed tables that are joined, or maybe it looks like having a Tableau concept of a hot and cold data structure, right, where we've got some aggregation happening for the higher level queries that need to run, and then the the more granular stuff can run at the more granular level. That's Okay. Jack, do you have anything to add to that? No. You covered it. That was great. Cool. That is all the questions we have in the chat. Last call. And if nothing else comes in, in the next couple of seconds, we will wrap up. Thank you to everyone who joined us today. Yeah, just a quick reminder, this is recorded. Send the replay to your email in the next couple of days. If you do have any questions about migrating to Sigma from Tableau or other platforms, or anything related to your migration journey or other topics in data analytics, we'd love to help. Whether that's assessment to scope your migration, planning call to chart path forward, or support any stage along the way, please reach out to our team anytime and we'd be happy to walk you through anything on your mind. Final reminder, we have one more webinar planned for Sigma September. It is titled Snowflake Data to Sigma AI Apps, and that's scheduled for September 30, a week from today, two pm Eastern, 11AM Pacific. And we just popped a link to register for that webinar in the chat. So feel free to go and grab that before we wrap up. Thanks again for your time. We hope to see you at the final webinar. All right. Have a great day, everyone. Thank you.