We recently completed a full-stack migration from a legacy on-premise BI environment (a mix of Tableau, Informatica, and a SQL Server warehouse) to a modern cloud stack (Snowflake, dbt, Looker). While the technical execution had its expected hiccups, the most significant and unpredictable slippage occurred in user adoption, directly tied to inadequate training. We treated training as a secondary phase, and it nearly derailed the entire project's ROI.
Our initial plan was a classic "big bang" cutover followed by a series of instructor-led workshops. This failed for several key reasons:
* **Context Loss:** We taught the *mechanics* of Looker (how to build a chart) but not the *mapping* from the old to the new. Users couldn't translate their known Tableau workbook logic into the new LookML paradigm.
* **Data Model Disconnect:** The new dbt-built data models were cleaner and more normalized, which changed the fundamental "shape" of the data they were querying. Without understanding the new entity-relationship diagrams, users wrote incorrect joins or couldn't find familiar fields.
* **Lack of Just-in-Time Support:** Post-go-live, when users hit a real problem, our documentation was a static Confluence page. They reverted to extracting data from the old, deprecated system because it was "known."
We were forced to pivot and implement a more granular, ongoing training strategy. The most effective components were:
* **Pre-migration "Mapping" Guides:** For each major user cohort (finance, marketing, ops), we created a document that explicitly mapped their 10 most critical legacy reports to the new platform. This included the equivalent Looker Explore name, the key dimensions/measures, and a sample of the SQL the old report ran versus the new logic.
```sql
-- Legacy SQL Server query (simplified)
SELECT
DATEPART(year, order_date) as order_year,
region,
SUM(sales_amount) as total_sales
FROM fact_sales
JOIN dim_store ON...
-- Complex, nested joins, business logic in view layer
-- New LookML Equivalent
explore: sales_fact {
join: dim_store { ... }
# All logic and aggregations defined in dbt, exposed here
}
-- User simply selects `order_year`, `region`, `total_sales`
```
* **Staggered "Training Sprints":** Instead of one massive training, we ran two-week "sprints" for each department *before* their cutover. This included hands-on exercises with a sandbox environment seeded with their own data.
* **Embedded "Office Hours":** For the first 8 weeks post-cutover, we ran daily 30-minute open Zoom calls dedicated to problem-solving. These sessions were recorded and turned into a searchable knowledge base of common pitfalls.
The forcing function for this change was a 40% drop in weekly active users on the new platform six weeks post-launch. Our sequencing was wrong: we built the perfect technical pipeline but treated user competency as an afterthought. The slippage was a 3-month delay in achieving projected adoption metrics and a significant, unplanned allocation of analyst time for direct user support.
My question to the community: In a full-stack rebuild, where do you formally insert user training and change management into the project plan? Is it a parallel track from day one, or does it only become critical post-build? What specific, repeatable artifacts have you found most effective for bridging the mental model gap between old and new systems?
- dan
Garbage in, garbage out.
I'm a junior cloud admin at a mid-sized retail company, our team of three just finished moving from a similar legacy BI setup (on-prem Qlik) to the AWS analytics stack (Redshift, Matillion, and QuickSight). Our training rollout was messy but we learned a lot.
My breakdown based on our painful trial-and-error:
**Fit / Target Audience:** Instructor-led workshops fit enterprise budgets with formal L&D teams. For teams under 200 users, they're too rigid. We recorded 8-10 minute role-specific videos (analyst vs. casual viewer) and it cut our live training time by 70%.
**Real Pricing:** The big cost isn't the training tool, it's the labor. Our in-house "sandbox" environment for hands-on practice added ~15% to our cloud bill for two months (~$3-4k/month for us). Skipping it would have been cheaper but caused more support tickets.
**Deployment Effort:** The critical path was building a "translation guide." It took me and a data engineer two weeks to map 50 key legacy reports (Tableau workbook names > Looker explore names, old SQL Server table > new dbt model). Without this, users were lost.
**Where It Breaks:** Documentation always breaks post-go-live. We set up a dedicated "ask-analytics" Slack channel and a lightweight rotation where a power user was on-call for 2 hours each morning to answer questions. If you don't budget real human support time for the first 4-6 weeks, adoption stalls.
My pick is the combo of **scoped video tutorials plus a live, embedded support channel for the first month.** If your user base is highly technical, lean on the translation guide. If they're less technical, budget more for the sandbox environment. To make the call clean, tell us how many power users vs. casual viewers you have, and if you have any bandwidth for a developer to do that mapping work.
Your point about the "translation guide" being the critical path is absolutely correct, and I'd extend it to the infrastructure layer. That document shouldn't just map reports, it should map the entire data journey. For example, knowing that `Sales_Dashboard_v2` maps to `Looker:Retail Sales Explore` is good, but users also need to know the upstream change: the old "daily_sales_summary" SQL Server table is now the `mart_retail_sales` dbt model, which itself is built from the `raw_redshift.pos_transactions` table. This context turns a user from being lost to being capable of self service when something looks wrong.
The dedicated "ask-analytics" channel you mention is a lifesaver, but it can become a bottleneck. We found it crucial to seed that channel with a core team who not only answer questions, but also **publicly document** the answers in a shared, searchable runbook. This turns a support sink into a growing knowledge base. The cost of the sandbox environment you mentioned is often justified by this alone, as it allows you to recreate user issues without touching production.
Your experience with role-specific videos is the right scaling strategy. The next evolution we implemented was coupling those videos with automated, ephemeral training environments. Using a simple Terraform module, we could spin up a pre-configured QuickSight sandbox for a user, pre-loaded with their specific dataset samples, that self destructed after 48 hours. This kept the hands-on cloud costs variable and directly tied to active training, rather than a fixed monthly overhead.
CPU cycles matter