Leaving SAP HANA? Understand What You’re Taking With You.

How we are using an enterprise data agent to understand HANA logic before deciding what to rebuild in Snowflake or Microsoft Fabric.

A HANA report can be rebuilt in Snowflake or Microsoft Fabric, run successfully, and still change what its columns mean.

Take a reference number. Some records get it from a table, others through an older reporting model, and manually entered records get fixed text. Rebuilding all three the same way could change reporting behavior without producing a SQL error.

Our enterprise data agent runs on Snowflake Cortex and helps investigate that logic. The useful outcome is a handoff an engineer can inspect before deciding what to preserve, simplify or retire: what is understood, what is missing, and what still needs testing. The format below is our proposed handoff, not an automatically validated migration deliverable.

Engineering cases are anonymized. The service-report example is fictional, not SAP-delivered content or production output. Results come from selected tests, not a controlled benchmark.

One report column, three different routes

Think of a HANA calculation view as a recipe for a dataset: where records come from and how to combine, filter or calculate them. A view can read other views, creating layers. It can also combine separate inputs, or branches, each of which may pass through several layers.

Think of a service report that combines current records, archived records and manually entered records. All three contribute to the same ReferenceNumber column:

The moving dots follow each input path, stopping where archive evidence is missing. An engineer needs to know what happens along those paths: which field supplies the value, how it changes, and whether records are filtered out. Our early answers could name the view without finishing that explanation.

Find the logic, then follow its sources

First, the agent needed the actual logic. In one case, its searchable material contained a model's outer definition but not the calculations underneath—like a recipe title without the instructions. We added deployed view definitions and executable code, preserving full names and locations to distinguish similar models.

Then we changed how the material was split up.

Large definitions had been divided into smaller pieces for search. This is often called chunking. A search for ReferenceNumber might return the current-record mapping while missing the archived-record mapping elsewhere in the definition.

For our example, the current-record mapping says which field supplies the reference number. The archive mapping describes another source, and the manual mapping supplies fixed text. Returning just the first one could make an engineer miss two different behaviors.

We changed the grouping so those related mappings could be retrieved together. Search helped find the model; an exact lookup then retrieved its evidence and checked whether every expected input was present.

The lesson was practical: the way you divide source material affects what the agent can explain.

Even the right source name may be an intermediate step. HANA models can use a synonym, an alias that points to another object. We added those deployed alias connections and a field catalog describing mappings and relationships. If an alias led to another view, the investigation had to continue inside it.

For this report, that means the current-record path can reach an activity table. The archived-record path must remain unresolved until the deeper definition is available. The manual-record path ends at fixed text; there is no source field behind that value.

After these changes, a recorded test of a selected model and column returned physical source paths that the earlier answer had left unresolved. That was a useful improvement, with a clear limit: resolving those paths did not prove complete coverage of every HANA model.

Correct evidence still needed a faithful explanation

Our previous article asked whether an agent's evaluation was judging the right thing. Here, the practical test was whether its explanation preserved the source behavior.

We found answers that retrieved the right mappings but counted them incorrectly. A parser—a small program that reads the model definition and checks its structure—could count the inputs, but the agent did not consistently run it. We put the count checks into the existing lookup so the answer received checked facts.

Another answer described a fixed placeholder as SQL NULL. In the fictional report, that would mean treating NOT_APPLICABLE as a missing value. NULL means no value; NOT_APPLICABLE is actual text. A filter or report can treat them differently. An engineer following the explanation could therefore change the behavior accidentally.

We corrected the instructions and repeated an ordinary question. The selected test returned the expected paths and preserved the literal values. One generated query still failed before the agent recovered, so this was progress rather than error-free execution.

We also made incomplete answers harder to overlook. The deployed response format uses an orange PARTIAL notice for missing evidence and a red UNVERIFIED notice for unsupported conclusions. In our fictional example, the useful message is specific: “The archive path stops at a view whose definition is unavailable.” A warning should name the gap, not just say confidence is low.

Our own guidance also needed attention: one rule allowed guesses when local evidence was missing, while another required evidence. Parsing was optional in one place and required in another. The design now gives shared rules to the agent instructions and detailed HANA steps to a skill, a task-specific playbook. We also deployed a cleanup that removed duplicated instructions while retaining each rule once. This is easier to maintain; better accuracy or speed still requires evaluation.

For an engineer, the acceptance test remains concrete: account for every input path, preserve calculations and fixed values, and state where the evidence stops.

To make recurring questions easier, we added reviewed question-and-SQL examples through Cortex Analyst's Verified Query Repository. A query that worked directly against the database initially failed through the agent's more limited tool. Splitting retrieval across the appropriate tools corrected that tested request. The lesson: test through the interface the agent actually uses; a verified example guides retrieval but does not certify the answer.

Understanding the old design gives you choices

Now return to the migration decision. Knowing how the report works does not mean rebuilding every view exactly as it was.

An engineer might preserve a business rule, simplify repeated calculations, or retire an input that the business no longer needs. For this report:

Evidence in the fictional example	Engineering decision	Next validation
Current records resolve to a known field	Preserve its meaning in the target mapping.	Compare matched records from the same source snapshot, including any transformations.
The archived path stops at another view	Investigate before implementing, retaining or retiring that path.	Obtain the missing definition and check its mappings and filters.
Manual records contain NOT_APPLICABLE	Keep the literal, or explicitly agree a different representation.	Test the literal separately from SQL NULL, including how reports filter each.

These are proposed engineering checks, not tests completed for this fictional model.

A source explanation is not a data test.

Reading a model definition can establish mappings and filters. It cannot establish the row counts produced by a rebuilt query. If the agent cannot execute that query through an available tool, label the handoff “Query prepared — not executed” and leave the results unknown. Asking it to continue does not create access.

In Snowflake or Fabric, one possible design is an activity fact table, where each row represents a defined event, with shared customer and service dimensions holding descriptive information. In Fabric, a Power BI semantic model could then define the reporting measures and relationships. Some workloads may still benefit from views.

This is an architectural choice, not a rule that HANA uses views and other platforms use facts and dimensions. HANA supports dimensional modeling too. SAP HANA modeling documentation

Conversion tools have a place in that journey. SnowConvert AI and Microsoft's Fabric Migration Assistant support migration work for their documented source platforms. SAP HANA is not listed on those two capability pages checked on October 3, 2026. Our work explores how source understanding can inform the decisions around a migration; we have not demonstrated automatic migration or equivalent results on a target platform.

For teams building migration tools, that raises an interesting question: could the workflow show engineers what they are about to rebuild—and the evidence behind it?

This continues our series from recovering legacy knowledge, through governed semantics and evaluating agent answers, into a specific engineering task.

Before asking how to move a HANA model, we can ask a better question: what does it do, and which parts still belong in the new design?

Want to explore the approach or ask about the code? Connect with me on LinkedIn. Tell me which part interests you: collecting HANA definitions, finding the relevant logic, or checking where fields come from.