This is Part 1 of a two-part technical series. Rupak's article on building AI-ready data products describes the larger destination: a machine-readable context layer, governed semantics, and engineering guardrails. This post tackles the migration problem that comes first—recovering legacy knowledge and turning it into grounded SQL. Part 2 will cover natural-language questions, governed execution, and explained answers.
All examples and names below are synthetic
Moving data is often the easier part of an SAP-to-cloud migration. Moving the knowledge is harder.
A pipeline can copy a table. It does not automatically carry forward why two tables are joined, which filter defines an open order, how technical statuses become business terms, or who owns the report.
Without that context, a new platform can produce a technically valid answer that is wrong for the business.
Imagine an estate with more than 5,000 SAP HANA calculation views, hundreds of Qlik and Spotfire applications, and more than 2,500 cloud tables.
A data engineer receives a simple request:
Rebuild our sales-order backlog dashboard in Fabric. What existing logic should I preserve?
The answer is scattered. A HANA calculation view may define the joins, filters, and open quantity. A Qlik application may map technical statuses and write a shared QVD. A Spotfire analysis may implement its own aging logic. Ownership and downstream usage may live in reporting metadata, while field-level dependencies live in a lineage graph.
Qlik and Spotfire are parallel reporting platforms over HANA. They are not sequential stages feeding one another; the same HANA model may support applications in either or both.
The migration task is therefore not just code conversion. It is evidence discovery.
We call the user experience an Enterprise Data Discovery Assistant. Under the hood, a bounded Snowflake Cortex Agent selects retrieval and analysis tools. “Agent” describes the architecture; “assistant” describes its read-only responsibility. It does not change source systems, deploy code, or promote pipelines.
Engineer question
|
v
Enterprise Data Discovery Assistant
|
+-- HANA repository code
+-- Parallel BI artifacts
| +-- Qlik scripts and QVDs
| +-- Spotfire queries and metadata
+-- Reporting metadata catalog
+-- Schema, object, and column lineage
|
v
Recovered logic + ownership + dependencies
|
v
Grounded SQL draft -> data-engineer validation
The four evidence layers play different roles:
HANA repository code provides the calculation-view definition. Parsing indexed .hdbcalculationview XML reveals sources, joins, filters, calculated columns, unions, and nested-view dependencies.
Parallel BI artifacts reveal reporting logic. Qlik contributes load queries, aliases, mappings, resident loads, and QVD flow. Spotfire contributes source queries, columns, and any calculations present in its indexed metadata or exports.
The reporting metadata catalog connects Qlik and Spotfire applications to HANA models, queries, fields, owners, paths, saved-query details, and comments. It adds operational context around the code; it does not replace the code.
Schema and lineage metadata traces upstream sources, downstream consumers, object dependencies, and column paths, then helps map recovered logic to approved target objects.
Together, these sources answer more than “What SQL should I write?” They can also answer: Who owns this dashboard? Which reports use this HANA view? Which QVDs feed the application? What could break if the model changes?
Search locates the artifacts. Deterministic parsers extract their structure. The language model relates the findings to the engineer's question.
The experience should feel like a conversation, not a metadata report. The engineer asks one question; the assistant shows what it checked and returns an evidence-backed answer with SQL.
Synthetic chat demonstration: no production data or internal interface is shown.
The response separates recovered facts from the proposed target design. In this example, the assistant verifies the HANA joins and filter, recovers the Qlik status mapping and QVD flow, identifies the owner, and finds downstream Qlik and Spotfire consumers before drafting SQL.
Only then does the assistant propose a starting point:
SELECT
i.order_id,
i.ordered_qty - i.confirmed_qty AS open_quantity,
s.business_status
FROM sales_order_item AS i
LEFT JOIN status_map AS s
ON i.status_code = s.status_code
WHERE i.cancelled_flag = 'N';
The SQL is useful because its origin and limitations are visible—not because it appeared quickly.
The draft is not a production pipeline. A data engineer still confirms the grain, compares results with the legacy report, maps the logic to canonical target names, and preserves null, fallback, and refresh behavior. Production work also requires incremental patterns such as CDC or watermarks, data-quality tests, security, documentation, owner approval, and CI/CD which was covered in Developer Toolkit.
Trust comes from a few explicit boundaries:
If an expected Qlik or Spotfire expression is absent from the indexed sources, the assistant says so instead of reconstructing it from assumptions.
The same human-in-the-loop pattern shaped the assistant itself. Snowflake CoCo,supported the build-and-tune cycle by helping refine tool instructions, test prompts, failure analysis, and response behavior. Engineers decided which changes to adopt and validated the results.
Moving data gives a new platform rows and columns. Moving knowledge preserves the meaning, ownership, and dependencies people rely on—and provides the context needed to build governed data products.
Part 2 will follow a natural-language question through governed SQL execution and show how the final answer explains its sources and limitations.