S/4 Hana Sizing (Server sizing) is an important cost item in SAP projects. Especially, companies using less complicated and on-premise ERP want to use their existing server resources in SAP application and database while implementing S/4. Although this is not technically possible with the HANA database, we see that existing resources can be used as SAP application servers. Of course, although it varies according to the company and SAP usage, the actual SAP hardware investment is on the HANA database side. Because Hana is on Memory, there is a high memory usage. For example, while 2 x 96 GB RAM and 16 Core servers are used in Application servers, 512 GB RAM may be insufficient on the HANA side in the same infrastructure. Considering Hana’s backup, this capacity grows well and increases its cost to the company.
As mentioned above, these numbers are just an example and of course depend on the number of users in the company and many parameters such as the process used and the documents created. SAP actually gives you information on this subject, it can be accessed from the link below.
Although there is a sizing document sent by SAP before the project and filled in by the customers, there is always a margin of error in such foresight-based transactions. It is very difficult to make accurate sizing, especially since some processes have changed and more documents are created in SAP compared to simple ERPs. To give an example, in a company that went live with 2 application servers, 5 to 6 additional application servers were added within 1 month. On the HANA RAM side, it was doubled after the first month of go-live, then tripledin the second month. In the third year of life, the HANA resource had to be increased to 6 times the initial one. Application servers were also around 15.
There are different views and practices for sizing and optimization on the application side. Some administrators want to grow horizontally (like a large number of application servers), while others want to grow vertically with few but powerful servers. Although it is not an absolute truth here, my personal opinion is that horizontal growth is more accurate, since when a server has a problem, the others can continue quickly, and it will bring less process and workforce loss.
For another article on the subject