Äripäev and NabuMinds on moving to Microsoft Fabric

On Wednesday 21 October we spent the morning at Palo Alto Club, Telliskivi 57, for a Tallinn Data Week satellite event. SparkleSolutions OÜ organised it, the Estonian Fabric User Group community was invited, and the talks were streamed live. The morning was called “Fabric, from the people running it”: Äripäev and NabuMinds explained their move to Microsoft Fabric, what worked and what did not. I spoke twice, first and last, so parts of this recap are my own notes. The figures from Äripäev and NabuMinds, and the slides shown here, come from their own talks. Thanks to everyone who joined, in the room and online.

Fabric in 2026: worth, cost and the first decisions

My first talk was built around the three questions in its title: what Fabric is worth in 2026, what it costs, and what to decide first. The short version: Power BI stays, and Fabric is everything around it. Nothing is thrown away, because workspaces, models and reports move as they are. You buy one capacity rather than separate tools, and pipelines, the warehouse, models, reports and Copilot all draw from it. Existing Power BI licences stay valid. On cost, my advice was to start pay-as-you-go, measure, and only then reserve the size you measured, not the one you guessed. The two talks after mine were the practical side of the same questions, told by the people doing the work.

Äripäev: from Qlik to Fabric with an AI-assisted flow

Liis Rush is Head of Data & Business Platform at Äripäev, with three areas (data, CRM and marketing technology) and nine people. Äripäev has about 250 employees and more than 20 business units, from news and conferences to training courses, books and radio, and the goal is one data platform for all of its analytics. The first phase built a lakehouse that brings about 20 sources together in a medallion structure. The second phase, under way now, is about reporting: a customer 360 view built from two CRMs and Infopank, and moving the Qlik reports to Power BI.

Before building anything, they found out what is actually used. Workshops with focus groups mapped the reporting needs, and a usage analysis went through all 89 Qlik reports in use: 18 were dropped and the rest consolidated, which left 46 to migrate, ordered by usage and business criticality.

The first try: AI from Qlik metadata

The problem was speed. The analysts split their time between existing reporting, ad hoc requests and learning and building on the side, and each of the 46 reports needed its own semantic model design and review. AI already helped them write code, but not build models or design reports.

So the idea was to hand AI the Qlik report logic and let it build. They pulled every Qlik app's scripts and object definitions with qlik-cli, extracted the load scripts, dimensions and measures of each app, and asked AI for a report. It looked like a report. Some numbers were close and some completely off, it made up metrics where input data was missing, and it produced duplicated charts, too many pages and no clear styling. Her lesson: “AI tried its best, but the input wasn't good enough.”

The second try: context, agents and an analyst in control

The second try was a process rather than a prompt: everything in Git, written business context, governed access and analyst controls. The context is the groundwork. The process defines every source, table, field and metric, documents it in Confluence and syncs it to Fabric, starting with basics such as who counts as a subscriber and what a product is. Agents work on top of it, one per role and each with only the tools and skills it needs: a Jira agent, a planner, a navigator that finds items in Fabric, an agent that analyses the existing Qlik solutions, Fabric and Power BI developers, a tester and a reviewer.

The analyst stays in control from start to finish. The analyst describes the task in Jira, AI drafts a plan, the analyst confirms it, AI builds and tests, and the changes are reviewed and approved before they are deployed. Nothing reaches production without review. The prerequisites were Fabric MCP 1.0 (April 2026) and Power BI modeling MCP 1.0 (September 2026).

What it changed

A report migration now takes two to four days instead of about ten, a change in the data layer half a day instead of two or three, and the team saves up to a third of its working time. The way they work changed too: every Fabric change follows the same governed flow, from Jira task to reviewed deploy, and analysts define, review and approve while AI does the hands-on build.

Her tips were plain. Keep the context and instructions fresh. Plan time for the guardrails, because governance takes effort. Whatever AI generates and you deliver is your work, hallucinations included. And be ready to adapt, because the method and the tools keep changing. Next for Äripäev: a richer context layer of business definitions for people and agents, conversational analytics that users can trust, and finance data and reporting on the same platform.

NabuMinds: from a reports-only Power BI tenant to Fabric

Aaron Lee Amarga, Head of Business Intelligence at NabuMinds, opened with “If it ain't broke, don't fix it”: nothing was broken, and that was the problem. NabuMinds is a data and CRM consultancy based in Tallinn. His story was about a finance and payments client whose BI platform NabuMinds runs end to end, from data pipelines and semantic models to reports and alerts. Payments data moves fast, and an issue found hours late costs real money.

The client's old, reports-only Power BI tenant had no data layer, so reports on different semantic models could show different numbers. Refreshes ran on a schedule, so issues surfaced only once the data reached the reports. There were more than 60 reports, and fixes waited on the client's IT department. They chose Fabric, not just a new tenant, for one platform with one copy of the data in OneLake, for Direct Lake semantic models that read Delta tables without import copies, and for Real-Time Intelligence, Copilot and data agents on the same governed data.

A four-month kickstart, then their own team

The move started with a short kickstart with Sparkle Solutions, where I work, from December 2025 to March 2026. It had four workstreams: migrating the old Power BI tenant to a new Fabric tenant, the Fabric foundations (capacities, workspaces, lakehouse), a medallion model feeding Power BI, and Real-Time Intelligence and Copilot. The reports were rationalised before the move: 43 were migrated, with separate development and production capacities from day one.

The medallion model sits under Power BI. Client databases are mirrored into Fabric and land raw in Bronze. Silver (cleaned and conformed) and Gold (aggregated tables) are in Fabric Warehouse, and Direct Lake semantic models on top serve Power BI and the data agent. Every step from Bronze to Silver to Gold is a dbt SQL model, run by scheduled Fabric pipelines and version-controlled in Git.

NabuMinds' own team now runs the platform, from capacity monitoring and DAX optimisation to deployments through the REST API and a Gold layer rebuilt on Warehouse tables. Aaron's slide shows a BI team with two tracks: a development track for requirements, semantic models and dashboards, and an operations track of BI process engineers who look after infrastructure, deployments, QA and platform governance.

A data agent tested in three rounds

The business sends the team around ten ad hoc questions a week, and each one is a ticket. A payments manager's question is typical: which customers made a transaction with this specific payment method? A Fabric data agent grounded on the Gold-layer semantic models now answers questions like that, within guardrails on its scope, its instructions and who has access. It has 25 users.

Before trusting it, the team taught it. Every field is explained and every join defined on the central semantic models, and business preferences add synonyms, correlations and “when people ask for this, they mean that”. Then they tested it in three rounds: 75% accuracy on 80 real service-desk questions, 93% on the same questions after recalibration, and 95% on 80 random AI-generated questions that nobody on the team had written.

Real-Time Intelligence on payments

Every transaction from every payment provider goes through Eventstream into Eventhouse. Every 15 minutes the transactions are aggregated per provider and checked against agreed limits, for example acceptance below 80%, 20 refusals in 15 minutes, or volume below its expected level. When a limit is hit, Activator alerts the right owner. The business now knows within about 15 minutes that a payment provider is struggling, instead of at the next report refresh.

Aaron called it a signal, not a verdict: the alert says something might be wrong with a provider, early enough to act. Knowing early matters, because, Aaron said, every hour a payment provider is down costs the client about 10,000 euros on average.

What was harder than expected

Capacity sizing, first of all: they started on an F16 and learned that their transaction volume needed a bigger capacity. Workspace visibility waited on admin role assignments, in-house delivery was concentrated in too few people, and using capacity well takes proper sizing, optimisation where needed and reading the capacity metrics to know what you actually consume.

Three of Aaron's lessons, what the team would tell itself on day one: rationalise before you migrate, treat capacity as a cost model from week one, and spread platform knowledge before it walks out the door. He closed with “You can buy a platform. You can't buy ownership.” In a LinkedIn post afterwards he called the past few months challenging for the team, “but we delivered”.

Fabric IQ: business context for agents

My second talk picked up a thread from both stories: an AI agent is only as smart as the business context you give it. My example was a freezer that drifts above −18 °C on a Saturday afternoon. Facilities, the store manager, quality and finance each see part of it, and nobody can say which products are at risk, worth how much, and who needs to act.

Fabric IQ lets you describe your business on top of your data. The semantic model stays the contract for metrics, and an ontology adds what the business objects are, how they relate, and the rules and actions around them. My advice was not to start by modelling the whole enterprise: pick one question, model only what it needs, start from a model you trust, and ground one agent and prove it. Then I showed a live example of an agent answering questions across the business.

Lunch and demo corners

Over lunch there were four demo corners: Real-Time Intelligence, ontologies with Fabric IQ, the Fabric data agent and a Fabric app. People could see the tools at work and ask their own questions. Anneli Tomingas ran the data agent corner.

Three takeaways

Rationalise before you migrate

Both teams cut their reports before moving them: Äripäev from 89 Qlik reports in use to 46, NabuMinds from more than 60 to 43. It was the first of Aaron's lessons, and it makes every later step smaller.

Give the agent context before you trust it

Äripäev's first AI attempt failed on poor input, and the second worked because the context was written down first. NabuMinds explained every field and tested its agent in three rounds before relying on it. Fabric IQ is the same idea for the whole business. An agent works with the context it is given, so write that context down and test the answers.

Keep people in charge, and spread the knowledge

At Äripäev, nothing reaches production without an analyst's review. The client's platform is now run by NabuMinds' own team, and Aaron's warning was to spread platform knowledge before it walks out the door.

Next meetup

The group's next meetup is on Thursday 5 November 2026, 18:00 to 21:00, at DIGMATIX Estonia, Mäealuse 2-4, B, Tallinn. It is free, and the November meetup page has the programme and registration. The programme, the recording and the photos from this morning are on the 21 October event page.