Eleven Myths About SAP to Snowflake Transformations
Clearing up misperceptions about moving SAP workloads to Snowflake.
--
Need an SAP-to-Snowflake myth buster? Who ya gonna call?
Call me! In this paper, I dispel eleven myths that I commonly encounter when talking to SAP customers. The competition regularly spreads fear, uncertainty, and doubt, so pushing back against the FUD is a necessary part of showing how Snowflake can cut costs and increase efficiency. So let’s bust some myths!
Myth #11. You don’t have the right to take data out of SAP.
Except you do have that right, because it’s your data. The “Indirect Static Read” scenario that frequently applies to analytic workloads only requires a user license for the person creating the query, not for those consuming the data. For details, check out SAP’s Indirect Access Guide.
Myth #10. HANA is their answer, but what was the question? The question is: How do you run your business?
Consider the following:
1. Given that you have to move to S/4HANA (on HANA database), because it is the ERP successor to SAP ECC on any database, you will appreciate knowing that operational reporting in S/4HANA returns from the partitioned (and confusing!) hot, warm, and cold storage world of BW, and it now sits in Core Data Services (CDS) views.
2. You will also appreciate knowing that S/4 Group Reporting takes consolidation back from BW as well.
3. Et le planning? That goes to SAP Analytics Cloud. Well, that doesn’t leave much else for poor BW!
In fact, an S/4HANA migration is a great time to move the right parts of your business analytical processes and computation to Snowflake. The Snowflake platform provides business analysts and data scientists a safe, self-service environment, and business partners get gated, governed access — all at a reasonable price.
So, if you don’t need an expensive, hard-to-maintain, in-memory database application called BW (nor you, SAP Data Warehouse Cloud!) to keep multiple copies of your data, consider maintaining a single copy of your data in Snowflake.
You should also consider Snowflake if you want to import point-of-sales, sensor, social, and third-party curated data using an easy-to-use data cloud that allows you to monetize your data effortlessly.
And if you are experiencing problems with your migration? Check out faiv.io to automate your migration with machine learning, and your ECC becomes a digital twin.
Myth #9. You will never completely replace an SAP BW system with Snowflake.
Hotel Beds did it. Completely. Learn how.
That said, it’s not a fair comparison: SAP BW is a data warehousing application, and Snowflake is an ACID-compliant, fully secure, elastic compute, column store data platform that runs SQL, Python (currently in preview), Scala, and Java inside Snowflake…and can function as the core of your Data Mesh.
If you prefer not to code, add some orchestration, automation, and modeling tools on top of Snowflake, and then compare. For data engineering, check out Coalesce.io. Another tool to consider is DBT, which is used a lot. If you have it in SAP BW, move your consolidation into S/4 Group reporting, and move planning into SAP Analytics Cloud or something like Anaplan.
Otherwise, keep your BW, but massively reduce its footprint.
Are your underlying HANA database licenses already paid for? As space is no longer needed on your now lean-and-clean BW, you can move those licenses over to your S/4HANA project. You will be loved.
Myth #8. Snowflake can’t handle SAP hierarchies.
Myth. Not only can the Snowflake platform handle hierarchies, it can massively accelerate reporting on them using recursive commands, common table expressions, and the use of arrays in the same table. Check out Saša Mitrović’s three articles on this topic.
Further, some GSIs, such as Infosys, can analyze and flatten hierarchies. For example, check out Bladebridge’s code conversion tool.
Myth #7. Snowflake doesn’t do currency conversion.
Sure it does! Check out my article on this subject. Adapt it into a function call and you’re good to go. Or use any existing Python or Java currency conversion library within a Snowflake UDF. Or call a BAPI from a Snowflake external function call and retain the logic from the SAP ECC.
Myth #6. SAP HANA is faster than Snowflake because it is in-memory.
That could be true for small queries if cached joins are under 1 GB and only one or a very few users are running queries. But for bigger queries and/or many users, you will encounter out-of-memory errors in HANA. With Snowflake you can run petabyte queries that HANA cannot even touch. And if you are not happy with Snowflake’s performance, you can double your computational power in seconds with just one statement and no downtime. You can have thousands of users running on a Snowflake system at the same time with no SLA degradation, and then have the system automatically dial down the compute when the peaks drop.
But don’t trust me — try out Snowflake and see for yourself.
Next, try adjusting performance in HANA Cloud by increasing the size of the storage/CPU and resizing it down afterwards. Oops! From SAP’s official documentation:
You can only increase the storage size of an SAP HANA database instance. Decreasing the size of an instance is not supported.
Bummer! (For them, that is.)
Myth #5. SAP BW comes with valuable business content.
In phase one, why not put that valuable content to work by using BW as a pump, and landing your star schemas in Snowflake where the entire business can access and mix them, driving true self-service? Next, in phase two, why not rebuild that business logic back better? Use a tool like SAP PowerDesigner, or SqlDBM to explore it? If you tried the opposite — to bring all your data into a BW system to ingest and mix the data (if you could afford to fit it all) — you would hit the 90 million cell limit at query run-time. Ninety million sounded big ten years ago, but now with machine learning workflows, this is a real constraint. SAP Data Warehouse Cloud (DWC) is increasing its size limit after several years, but the problems you have with on-prem architectures such as HANA, you will have with DWC.
Myth #4. SAP HANA Enterprise Data Warehouse doesn’t have to materialize. It can use views to do all the modeling virtually.
The deep dark secret is that even HANA materializes. Specifically, it materializes intermediary result sets in-memory when queries are executed. For large or complex queries, there may not be enough memory to materialize everything, which leads customers to build ETL processes in HANA, and materialize intermediate results ahead of time.
In Snowflake, you can also have views on views — when you’re implementing a DataVault model, for instance. But similar to HANA, it is better for more complicated transformations to materialize. Snowflake has built-in functionality to make all of this easier and automatic, such as streams & tasks, zero-copy clone, windows functions, Snowpark, external function calls, common table expressions, and recursive functions. GSIs, such as LTI, Infosys, and Accenture have view conversion tools — but, yes, there will be a need to rewrite views into Snowflake.
Myth #3. Snowflake is massively cheaper than SAP.
That’s actually true! Using the SAP HANA Cloud Capacity Unit Estimator, you can calculate that one TB of HANA is hundreds of thousands of dollars per year. (Again, this is for ONE TB!) Snowflake, on the other hand, cleverly separates computational power from storage, both physically and in its pricing. For capacity customers, the cost of Snowflake storage is in the range of $20 — $23 USD per TB of compressed data per month. (Snowflake passes on the cloud providers’ charges, but with our compression you get more bang for your buck.) Computation can be turned on and off, either with timeouts, programmatically, or with monitors. To have Snowflake manage the computational power needed for data ingestion, use Snowpipe.
Myth #2. You have to buy specialized applications to extract data from SAP.
It’s probably a really good idea that you do, and with the savings Snowflake provides, you can afford it. But you can also continue to use your Informatica or Talend or other ETL tools to bring data into Snowflake. SAP Data Services 4.2 SP12 onwards has an SAP supported connector to Snowflake. Just make sure that the tool you choose works with the Snowflake COPY INTO command, or it’s going to be dead-slow doing inserts. (But be sure to check out this article on Kafka streaming with JDBC drivers. Very interesting!)
When evaluating tools, consider how each tool connects to SAP. Is it at the database or application level? Can the tool handle cluster tables? Can it leverage SAP extractor logic? Can it do data quality checks?
This is my own opinion, but I’m a big fan of SNP Datavard Glue for pure-play SAP, which is as close as you can get to being an SAP application without being one. Or consider Fivetran HVR, which can handle massive throughput. You will want the extraction load tool to land the data as a PSA, append-only, and then manage the merge from the Snowflake side. We have an excellent DML deferred merge pattern to get quick response time and keep costs low.
Myth #1. You need to replace SAP with Snowflake to get value.
You don’t. Snowflake’s value proposition goes way beyond data warehousing, and there are many situations where you might want to use Snowflake as a sidecar to your existing SAP landscape. Companies can seamlessly share their data either privately or on Snowflake Data Marketplace, use Snowflake to build a Data Mesh architecture, and use Snowflake Data Clean Rooms. Snowflake offers ecosystems for Retail and Healthcare & Life Sciences, with many more to come. Snowflake’s technology enables governed, curated data to become instantly accessible cross-cloud without data movement.
And that’s it! So consider making Snowflake your next data foundation, and don’t let the myths deceive you.
