Why B2B Personalization Improves Engagement But Doesn’t Always Translate to Revenue
24 septembre 2026 • 7 Minute Read • Chris Boulanger, Directeur général, Données et analytique
See All Our Insights
How a Digital Agency Migrated to Snowflake and Delivered 50 Trusted KPIs in 6 Weeks
7 octobre 2026 • 6 Minute Read • Peter Graham, Directeur de la stratégie, Données et analytique
A services business can only move as fast as its answers. When leadership asks which clients are growing, which projects are losing margin, or whether there is enough pipeline for next quarter, different reports cannot return different numbers.
That was the problem facing a digital agency with between 500 and 1,000 employees. Its SQL Server warehouse had grown over nearly a decade, one reasonable request at a time. The data that leadership needed was already in the environment, but metric definitions had drifted across reports and models. The agency needed to migrate to Snowflake, standardize the numbers, and provide the business with dashboards it could trust.
Verndale helped the agency do that in 6 weeks. The result was 50 governed KPIs, live 360-degree dashboards across 5 operational areas, and a clearer way to manage what stayed, what changed, and what could be retired.
What the Data Migration Project Had to Solve
The agency wanted a shared view of 5 parts of the business:
- Go-to-market (sales and marketing)
- Financial performance
- Clients
- Projects
- Operations
On paper, that sounds like a dashboard project, but in practice it's a definition problem.
Over time, the same metrics were defined differently across reports, and some relationships were managed in code instead of the database. That made it harder for the business to know which numbers to trust.
Success, therefore, had a simple practical meaning:
- Every KPI needed an agreed-upon definition
- Every KPI needed one owner
- Numbers needed to reconcile to the system of record
- Dashboards needed to be usable by people outside the data team
By traditional estimating methods, this looked like a 6- to 9-month migration. The data warehouse included roughly 10 years of development, 177 objects, and reporting logic spread across stored procedures and Power BI semantic models. Plus, some of the original authors had moved on. The business could not afford to discover key dependencies halfway through the build.
What Made a 6-Week Timeline Possible
The project moved quickly because the team handled the highest-risk work first.
1. Read the whole data warehouse before planning the migration
Most migration estimates start with what's easy to count: tables, source systems, rows, reports. But those counts don’t tell you where the real risk is. The real risk lies in years of embedded business logic: calculations in stored procedures, assumptions in semantic models, and relationships enforced in code rather than in the database.
Verndale’s first move was to read everything before sizing the build. During the first week, Verndale’s agent-based delivery harness reviewed the agency’s documentation, warehouse objects, stored procedures, and Power BI semantic layer, producing a full inventory and dependency map for Verndale and the agency’s IT team to review together.
That inventory showed the scope:
- 177 warehouse objects: 100 tables, 39 views, 9 user-defined functions, and 29 stored procedures
- 2,252 columns sourced from 7 operational systems
- 28 BI report projects with 150 semantic-model tables, 244 report pages, and 991 explicit relationships
The most important finding was the measure of sprawl. Across the Power BI models, Verndale found 672 named measures. Many weren’t unique business KPIs but variations of the same few metrics, including intermediate calculations, time-based variants, formatting versions, and report-specific copies. In some cases, the same measure name meant different things in different reports.
That finding changed the project from a straight technical migration into a governance effort with clear priorities. Once the team could map report measures back to the business metrics they supported, it became much easier to identify which KPIs mattered most, which definitions conflicted, and which objects weren’t worth carrying forward.
2. Settle KPI definitions before dashboard design
A key early step was establishing one clear definition for each KPI.
That work mattered because a migration can preserve inconsistency just as easily as it preserves data. If multiple reports define revenue, utilization, or margin differently, moving them to a new platform doesn’t fix the problem. It just recreates it somewhere else.
Verndale used a KPI stewardship process to review measures across the report portfolio, group related calculations under the business metric they supported, identify the version that reconciled to the system of record, and write that governed definition against the target model.
That gave the project a clear rule: no KPI was considered complete until it had a single definition, a single owner, and a reconciliation result. By settling those definitions before dashboard design began, the team made consistency part of the foundation instead of something to clean up later.
3. Use agents for scale and people for decisions
Verndale delivered the work through its own agent harness running on Snowflake CoCo, Snowflake’s native coding agent. The harness mapped work to seven delivery roles, including strategy, architecture, engineering, BI development, analysis, governance, and KPI stewardship.
The agents handled the high-volume work, including reading warehouse logic, extracting dependencies, drafting models, and producing repeatable code. At the same time, the people handled the judgment calls, including what a metric should mean, which version was correct, and whether the output was acceptable.
That separation mattered.
Snowflake provided a single environment for the target data model, governed metrics, and live data access. Because the coding agent could work from the actual catalog, lineage, and access controls, it could generate work against real production objects and dependencies rather than guessed names or structures.
Specific instructions made that setup usable. Each role had defined responsibilities, guardrails, and acceptance criteria. Each agent was assigned specific, reviewable tasks:
- Inventorying measures
- Mapping dependencies
- Drafting target logic
- Documenting preserve-refactor-retire decisions
4. Make every sprint end in something a person could review
The build ran in 3 two-week sprints. Each sprint ended with outputs that a person could open, inspect, and challenge.
To keep speed from undermining accuracy, the project built in checks and balances. The people and agents generating work were not the same ones approving it, so findings, code, and KPI logic were reviewed throughout the project rather than at the end.
The project reduced risk by tackling dependencies and KPI definitions early, with review built into every stage.
What the Team Delivered
At the end of the third sprint, the agency had:
- A Snowflake target model with pipelines from all 7 source systems
- A governed measure library with one definition, one owner, and a reconciliation result for every KPI
- 50 KPIs built into the semantic layer
- Live 360-degree dashboards across go-to-market, financial performance, clients, projects, and operations
- A natural-language interface for exploring live business data
The first release focused on the 50 KPIs leadership relied on most. Just as important, the project produced a decision record for every object in scope, defining what to preserve, what to refactor, and what to retire, along with the reason for each decision.
Because every dashboard drew from the same measure library, a figure meant the same thing wherever it appeared. For example, a figure like headcount meant the same thing in the operations dashboard as it did in project-margin reporting. That consistency no longer depended on each report author making the same choice every time.
Because every dashboard drew from the same measure library, a figure meant the same thing wherever it appeared. For example, a figure like headcount meant the same thing in the operations dashboard as it did in project-margin reporting. That consistency no longer depended on each report author making the same choice every time.
What Other Organizations Can Take from This
This project moved quickly because the team didn’t treat migration as a copy-and-paste exercise.
Main takeaways to consider:
- Read the entire environment before sizing the project. A full inventory turns a vague estimate into a sequenced plan.
- Resolve KPI definitions before you build dashboards. Otherwise, you will migrate disagreement along with the data.
- Treat review as its own workstream. Automated generation scales faster than informed verification.
- Invest in specifications up front. Clear roles, constraints, and acceptance criteria are what make accelerated delivery trustworthy.
Migration timelines will keep shrinking as more repetitive work becomes automatable, including reading legacy warehouses, drafting target models, translating procedures, rebuilding semantic layers, and generating tests. The hardest parts—setting definitions, resolving trade-offs, reviewing outputs, and building agreement across the business—will remain human.
Planning a Data Platform Migration?
If you’re sizing a move off SQL Server, evaluating Snowflake, or trying to create a single trusted version of your KPIs, Verndale can help you start with a complete view of what you own and a realistic plan to move it forward.