If you’re planning a Sigma migration in the next six to twelve months, something just changed that’s worth paying attention to. Sigma recently introduced workbooks-as-code into private beta. It’s still early, still limited in scope and not yet generally available. But the capability is real, and it materially changes how migrations onto Sigma can be approached.
InterWorks is working with Sigma within the beta program, collaborating and building on top of its most recent released features. Most immediately, we’re focused on what it means for the migration work we already do every day. But before we go any further, I think it’s important we call out two crucial points:
1. We don’t recommend lift and shift. Sigma is not just another place to park dashboards.
2. We prefer to rethink and rebuild to the strengths of the future platform.
We’ll elaborate more on this further down in the article, but keeping those points in mind will be helpful in understanding how we approach Sigma migrations. Now, back workbooks-as-code.
What Workbooks-as-Code Actually Is
In plain terms, workbooks-as-code means the workbook stops being something that only exists behind the UI. In the private beta, Sigma is exposing workbook structure as code. The workbook’s data sources, pages, elements, layout and configuration are represented as JSON or YAML and can be managed through the Sigma REST API. It doesn’t contain row-level data. It defines what the workbook is made of and how it’s arranged.
Sigma has already shipped data-models-as-code publicly, which does the same thing one layer down. Together, they start to form a code-defined analytics layer. Workbook on top, model underneath, both expressible as text and manageable through APIs.
The current beta is designed for creating new workbooks rather than editing existing ones, and Sigma has prioritized BI elements first: charts, tables, controls, conditional formatting, layout, dynamic text. Support for app and workflow elements is rolling out next. They’re solving the core BI use case first, then extending the same pattern into the app and workflow layer.
Analytics Platform Migration Is a Space We Know Well
InterWorks has been doing analytics platform migrations for over a decade, and migration tooling is something we’ve invested in seriously. Fifteen years ago, we built a widely used Tableau content migration tool. That tool helped move Tableau objects across Tableau environments at a time when doing that manually was the only option. Tableau eventually acquired it and shipped it as part of their product stack. That it was worth acquiring tells you something about the problem it was solving.
What Sigma’s workbooks-as-code opens up is a different kind of opportunity. Those earlier tools were built to move Tableau assets within the Tableau ecosystem. Workbooks-as-code creates a path to programmatically generate Sigma workbooks from source-platform assets, including Tableau, Power BI, Looker and others where the structure can be interpreted cleanly. That changes the scope of what’s automatable in a migration, and it’s exactly what we’re building into the next version of our tooling now.
Automation isn’t the whole answer, though. This is where most migration approaches go wrong.
Our Philosophy on Sigma Migration
We don’t recommend lift-and-shift. Sigma is not just another place to park dashboards, and treating it that way means carrying forward yesterday’s reporting sprawl instead of designing for what the platform can actually support. Sigma is built around the cloud data warehouse, governed collaboration and increasingly, AI-enabled workflows and applications. Porting your existing environment onto it without rethinking it leaves most of that on the table.
We prefer to rethink and rebuild to the strengths of the future platform. Use automation where it earns its place. Use human judgment where it actually creates value. That’s the same approach we’ve always taken with analytics migrations. The goal is not to recreate every asset one-for-one in a new environment. It is to use the move as a forcing function. Eliminate what no longer serves the business, improve the assets that matter most and rebuild around the strengths of the platform you’re moving to.
Teams that treat migration as “move everything, then be done” usually arrive with the same sprawl, friction, and governance debt they were trying to escape.
InterWorks Scout and the Four-Path Model
InterWorks Scout is our migration assessment and roadmap tool. We’re updating it to take advantage of workbooks-as-code, and the core question it answers is straightforward: Before anything gets rebuilt, which path does each asset in your analytics estate actually belong on?
Scripted migration. Workbooks that are straightforward in structure, clean in their underlying data model, and worth preserving largely as is. These are the assets where workbooks-as-code earns its keep, generating Sigma workbooks programmatically from source artifacts and cutting the time and manual effort required.
Redesign. Workbooks that belong in Sigma but should be rebuilt around what the platform is actually good at, not ported as is. This is often where the highest-value content lives: the executive dashboard that’s become a political artifact over five years or the operational report that would be better as an interactive workflow. These deserve human attention, not a script.
Retirement. Workbooks that shouldn’t make the trip at all. Every legacy BI estate has them. Unused reports from projects that ended two years ago, duplicates that multiplied because nobody knew which version was authoritative, content built for someone who left the organization. Retirement is often where the largest share of migration value gets created. It’s also the path most automated approaches quietly skip over because it requires judgment, not code.
Modernization. Workbooks that become something more powerful in Sigma than they ever were in the legacy platform. A static monthly report that becomes an AI-enabled application. A dashboard that becomes an embedded workflow with actions and governed input. This is the real upside of a well-executed migration. Not just landing in a new platform, but using the move as the forcing function to finally build what you always wanted to build.
Deciding which path each asset belongs on is where migration stops being a rebuild and becomes a strategy conversation.
What Else Migrating to Sigma Unlocks
Migration is the most immediate use case, but it’s worth saying out loud where this is heading more broadly. Self-service BI gave people access to trusted answers, and that genuinely moved the industry forward. What it couldn’t do was keep up with the pace of questions. Every dashboard was a prediction. Someone decided in advance what would matter, built the view, and hoped it stayed relevant. Getting real value out of those tools still required a level of proficiency and effort that not everyone had. The bar to get there is dropping quickly now, and the experiences people are starting to expect look less like static reports and more like workflows. Ask a question, get a useful response, understand what to do next.
The analytics layer must evolve to support that. Manually authored artifacts trapped behind a UI can’t keep up. The artifacts behind the experience need to become structured, versioned and programmable, even when the user-facing experience stays familiar and accessible.
When a workbook lives in a Git repository as structured text, it gets pull requests, code review, branching, diffs, rollback and a deployable history. The question of “who changed that KPI on the executive dashboard, when and why” stops being a forensic exercise. That kind of rigor has been standard practice at the platform and transformation layers for years. The analytics layer is starting to catch up.
The AI angle matters too, but it needs a little precision. The more AI changes the front-end experience of analytics, the more disciplined the back-end structure has to become. When a workbook is structured text with a published schema, an AI agent can read, generate and reason about it. As Sigma’s app-building elements come online in the spec, this extends from AI-assisted dashboards toward AI-generated applications. Trusted data flowing into workflows and applications people can practically use.
The structure doesn’t make AI safe on its own. The rest of the work like semantic definitions, lineage, permissioning and human review, still has to happen. The structure just makes it possible.
It’s the same pattern we’ve already seen across the rest of the stack, now finally reaching the analytics layer. When we talk about “Modern Data” at InterWorks, this is exactly what we mean. The analytics layer becoming more intentional, more maintainable and more trustworthy isn’t a future state. It’s what’s being built right now. And for organizations evaluating where to land, Sigma’s ability to plug into modern data platforms, work alongside AI models and support workflow-driven experiences makes it a more future-proof choice than its competitors that weren’t built with any of that in mind.
Want to Chat with Us About Sigma?
InterWorks is one of Sigma’s first Elite Partners in the inaugural SI program cohort. We’re in their private beta, actively building tooling on top of it, and we’ll have more to share as the features mature.
We’ll also be partnering with Sigma at Snowflake Summit in San Francisco this June. Demoing Scout, walking through our approach to Sigma migrations and meeting with customers thinking seriously about making the move. More details on where to find us and what we’re hosting later this week.
If you’re already thinking about a Sigma migration, or just trying to figure out whether now is the right time to start, we’d like to have that conversation.
