1. SAP on Azure Technical Overview

2. Agenda Customer challenges Azure helps address
SAP application evolution
Key SAP products supported on Azure
SAP Business Suites on AnyDB (SQL, Oracle, DB2 etc)
BW or Suites on HANA, S4/HANA
Technical deployment for HA DR
Migration path to BW/4HANA, S/4HANA

3. Customer challenges Challenges
Traditional server/storage/ network hardware with backup/HA solutions can be costly
Dev/Test/QA busy during implementation, go idle after go-live, except QA for trouble shooting
Choices of datacenter locations are limited in spite of global user access
Challenges
Sizing is often difficult and customers realize hardware/hosting vendors oversized after rollout
People to run SAP on-premises without automation solutions is the biggest cost factor
SAP customers cannot afford having a second datacenter for
disaster recovery
and tend to rely on old-style tape backup
Other technologies are needed when SAP doesn’t meet customer’s analytics/BPM/UX/EAI requirements
Azure services for SAP help customers address their challenges they face on a daily basis. SAP landscape is general big including hundreds of servers from DEV, TST, Prod support, and production etc. Also SAP production workload is mission critical to most enterprises who run it, standing up and keeping a DR environment is costly. Azure public cloud become a cost effective and agile solution for these scenarios. Plus people don’t just run SAP but they use other business and productivity solutions like , data analytics etc. Azure has these services to complement the SAP operational data rested in the SAP databases.

4. SAP Application Evolution
S4 HANA
ERP NW
R/3
R/2
SAP has been around for about 50 years now. Starting its online real time data processing products SAP on R/2. ‘R/2” denotes the two tier architecture running on IBM mainframe with fixed function termals connected to the application/database layer. As computing evolved into client/server distributed computing, SAP architecture advanced into a 3-tiers architecture: database, application, and presentation. With R/3, SAP business application and the technical (SAP Basis) modules are delivered in one collection. Products release become too interdepent that slow innovations. In 2004, SAP split out the technical ‘Basis’ and introduced SAP Netweaver being the platform to run SAP business applications and the integration platform offering web/SOA capabilities on top of others (RFC, SMTP etc). The latest innovation from SAP is the HANA in-memory database with supporting a suites of SAP business functions like Finance, logistics plus other data analytics capabilities including IoT, Mobile etc.
1979
Mainframe
1992
Client/Server
2004
Web/SOA
2015
IoT/API/Mobile

5. SAP NetWeaver
Diagram sourced from help.sap.com
The application platform for the SAP Business Suite of applications. Superseding SAP's earlier BASIS platform and launched with mySAP ERP 2005,
Technical Integration platform with no business logic/functionality

6. SAP Business Suite
A family of enterprise applications from SAP that form the core business offerings of the company. Formerly known as the mySAP Business Suite, the primary applications cover
Enterprise resource planning (ERP) [Finance, logistics , IS (industry solutions) etc]
Customer relationship management (CRM)
Product life cycle management (PLM)
Supply chain management (SCM)
Supplier relationship management (SRM)
Reference :

7. Azure infra. for a sample HA SAP system
Azure VNET
SIOS DataKeeper for WSFC without need of clustered shared disks
SAP App Server – ABAP/Java dual or single stack. Preferred smaller VMs
SAP Web Dispatcher installed on Azure VM, performs HTTP(S) load balancing
SQL DB with AlwaysOn Availability Group
Need to deploy in 3-tiers for HA DR
Av. Set 3, WSFC
SAP Cen. Serv. Node 1
Azure ILB
SAP SCS Cluster VNN
SAP Cen.. Serv. Node 2
Av. Set 2
Domain Controller
SAP App Server
SAP App Server
Av. Set
Azure VM SAP Web Dispatcher
Av. Set 1, WSFC SQL AG
A highly available SAP system typically has the above layout min remaining
The SCS is protected with Window Server Failover Cluster. The SIOS DataKeeper (3rd party solution) enable the creation of a cluster on Azure without shared disks.
SAP Application servers are protected by virtue of multiplicity. The HTTP(S) load balancing is handled by the SAP Web Dispatcher built on an Azure VM. The SAP Logon load balancing is handled by the SCS message server.
The DB layer, for SQL Server DB, we use AlwaysOn Availability Group (AG) built on a WSFC leveraging node majority with a file share witness quorum.
Sync Commit
Azure ILB AG Listener
SAP SQL DB WSFC node 1
SAP SQL DB WSFC node 2

8. SAP on Microsoft Azure
Microsoft Azure is certified for the following SAP products, with full support from Microsoft and SAP.
SAP Product
Guest OS
RDBMS
Azure Offerings
SAP Business Suite
Windows, SLES, RHEL, Oracle Linux
SQL Server, Oracle (Win), DB2, SAP ASE
A5-9, D11-D14, DS11-15, DS11-14V2, GS1-5
SAP Business All-in-One
SAP NetWeaver App Server
SAP HANA Base, Platform, Entr. Editions
SLES, RHEL
N/A
GS5, S72-72m, S m
Key SAP certifications listed only. See SAP note for full list and supported OS/DB combo
On May 19, 2015, Microsoft and SAP announced the full support of the SAP products list on the right
Only NetWeaver 7.00 and later SAP releases of NetWeaver are supported for deployment in Azure
Customers can try SAP HANA Developer Edition on Azure using the SAP Cloud Appliance Library. (including the HANA Client software comprised of SQLDBC, ODBO (Windows only), ODBC, AND JDBC drivers), HANA Studio, and HANA Database
Oracle Database 11g R2 Patchset 3 ( ), Single Instance
SAP Adaptive Server Enterprise 16
On May 17, 2016 at SAPphire Orlando, SAP/Microsoft jointly announced the SAP HANA (Base, Enterprise, and Platform editions) certification on Azure

9. What is SAP HANA?
SAP HANA is a modern, in-memory database and platform that is deployable on-premises or in the cloud
The SAP HANA platform is a flexible data-source-agnostic in-memory data platform that allows customers to analyze data in real-time
It is a development platform
The ‘SAP HANA platform’ is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition and and the SAP HANA Enterprise Edition
The SAP HANA platform is a flexible data source agnostic in-memory data platform that allows customers to analyze large volumes of data in real-time. It is also a development platform, providing an infrastructure and tools for building high-performance applications based on SAP HANA Extended Application Services (SAP HANA XS). It is the foundation of various SAP HANA editions, like the SAP HANA Platform Edition, providing core database technology, and the SAP HANA Enterprise Edition, bundling additional components for data provisioning. The SAP HANA Platform Edition integrates a number of SAP components, including the SAP HANA database, SAP HANA studio, and SAP HANA clients

10. Diagram sourced from “HANA, ‘the why’ Henry Cook, Jan 2016”
Let’s just recap the history of ERP. Originally SAP ran on the mainframe and ran a single application. Access was via online terminals (a major innovation at that time) and everything was done in real-time. At the time SAP was serving mid-sized German companies. But then they sold to bigger companies, and those companies grew, they needed to deal with “the multi’s”; multi-company, multi-language, multi-currency, multi-application (remember with the mainframe terminals were tied to applications, multiple apps meant multiple terminals) This exceeded the capacity of the mainframe, so SAP made a big leap, with SAP R/3, to a three tier Client Server architecture, splitting the Client Interface, the application logic and the database access across different servers, thus spreading the load.
At the same time we now have the newly available PC front ends to access multiple back end applications, instead of having to have one mainframe terminal for each application we needed. In the third step we see how this expanded as new applications were added, some of which SAP wanted to be able to sell on their own without necessarily having the ERP core, and at the same time we could mix and match servers to tune for performance and also to make operations easier. At the top of the diagram we see the appearance of separate management information systems, data marts and ‘spreadmarts’ the proliferation of spreadsheets that are actually being used as operational data marts in the organisation. These were used by organisations to make SAP data available for querying and reporting.
Note that where these different applications were sold with ERP –as was usually the case –a subset of the ERP data was replicated within the applications and there would be feedback processes that fed back to ERP too.
In the 4th step we see the addition of a dedicated server for the Business Warehouse, to make management information available from SAP applications, but often this didn’t kill off the separate management information systems, in fact many organization used BW as a mechanism to populate separate management information systems. There might also be a separate generic Data Warehouse added, to combine SAP data to non-SAP data at the time it was easier to do this by extracting the SAP data and taking it elsewhere rather than bringing the non-SAP data in (we’ll see that this has changed). More servers are added, more data marts and more redundant copies of data –however remember that by going this route we were able to scale the systems and to optimisefor individual applications, and, at the time there was no alternative given the technology that was available.

11. Innovation Through Simplication
SAP 7-8 years ago
Impeded by complexity,
large, complex suite of applications
15 month release cycles,
SAP was surrounded by increasingly nimble competitors,
Dependent upon others for data management,
Incurring large development costs
SAP’s strategy to get ahead and stay ahead through massive simplification
This simplification is what we now know as S/4HANA and BW/4HANA
7-8 years ago SAP found itself in a bit of a bind. The ERP applications were large and complex with 15 month release cycles. SAP was surrounded by competition, many of them increasingly more nimble than us.
SAP was dependent on others for data management, some of them major competitors, and all of this complexity incurred great cost.
The only way SAP could see out of this would be if they could radically simplify what we did, and this was the objective of the research project that eventually produced HANA. This entailed hundreds of developers working around the clock for 6-7 years –to get to where it is now.

12. SAP HANA then and now
Diagram sourced from “HANA, ‘the why’ Henry Cook, Jan 2016”

13. SAP HANA Use-Cases
SAP HANA as Primary Persistence for SAP NetWeaver Based Applications
SAP HANA as Data Mart
SAP HANA-Based Accelerators
SAP HANA Data Provisioning
SAP HANA as Application and Development Platform
SAP HANA Smart Data Access
SAP liveCache on SAP HANA
20 min remainig
SAP NetWeaver has two distinct aspects, ABAP and Java. Many applications built on SAP NetWeaver’s ABAP and/or Java application servers are able to run “on” SAP HANA, where SAP HANA serves as the sole database in the architecture.
With SAP HANA, operational data marts offer real-time analytics and reporting on data replicated from a transactional system’s database. The raw tables themselves are copied (structure and data) from the transactional system’s database into SAP HANA. The SAP Landscape Transformation Replication Server (SLT) is an SAP NetWeaver ABAP-based tool that provides real-time data replication. In addition, a log-based SAP Replication Server (SRS) can also be used to provide real-time data replication
SAP HANA-based accelerators are types of applications or scenarios that extend the capabilities of business processes in SAP Business Suite systems by leveraging the performance and scalability advantages that SAP HANA provides. The typical approach for accelerators involves replicating data for data-intensive operations that are often bottlenecks for the given operation in an SAP HANA table. A type of “switch” is then set in the SAP Business Suite application to indicate that whenever these specified tables are read, the read operation will take place in SAP HANA using a secondary database connection
SAP HANA is also used as an in-memory data proxy for many source systems leveraging data integration capability of SAP HANA for Data Provisioning
SAP HANA provides the basis for an application development platform, where many different types of applications can be built on, and run on, SAP HANA
SAP HANA smart data access enables remote data to be accessed as if they were local tables in SAP HANA, without copying the data into SAP HANA
SAP liveCache is an in-memory object store technology that is used to speed up material planning scenarios in SAP Supply Chain Management (SCM). It is available as an add-on for SAP HANA

14. SAP HANA Deploy/Operations Models
On-premises (and IaaS)
SAP HANA Appliance
Tailored Datecenter Integration (TDI) – MSFT offers this model in the Azure brand with Azure Large Instances for SAP HANA
In the cloud
SAP HANA is offered as a comprehensive infrastructure combined with managed services
SAP HANA Cloud Platform (HCP)
SAP HANA Enterprise Cloud (HEC)
SAP HANA One – MSFT Azure supports this product on VM (DS14_V2)
SAP HANA using the appliance delivery model, meaning preconfigured software and hardware bundled by an SAP hardware partner. This approach offers you well-defined hardware designed for the performance needs of an in-memory solution out of the box. The appliance delivery is the first choice if you are looking for a preconfigured hardware set-up and a preinstalled software package for a fast implementation done by your chosen hardware partner and fully supported by both, the partner and SAP. The installation of the SAP HANA appliance software is performed by the SAP hardware partner. External software is software that was not delivered by SAP or by your SAP HANA appliance hardware partner. SAP permits the installation and operation of external software that is required but customers need to pre-arrange such agreement with SAP
SAP HANA tailored data center integration approach, which allows you more flexibility when integrating your SAP HANA system with your existing infrastructure, for example, network or storage solutions. TDI has special hardware specs. The server must be certified and is listed in the hardware directory; all storage devices must have successfully passed the hardware certification for SAP HANA; the install person needs to be certified as SAP Certified Technology Specialist – SAP HANA Installation” (E_HANAINS)
HCP includes: SAP HANA Infrastructure Services (High-performance cloud infrastructure), SAP HANA DB Services (Fully-featured SAP HANA hosted in the public cloud), and SAP HANA App Services (SAP HANA Platform-as-a-Service (PaaS) in the cloud)
HEC includes: Enterprise-class SAP HANA managed cloud offering
SAP HANA One: Fully-featured SAP HANA hosted in the public cloud, generally used for smaller companies

15. SAP HANA Appliance vs. TDI
Diagram sourced from SAP Teched Sept 2016 handouts
Microsoft Azure large instances for SAP HANA are certified to meet the TDI specs. With Azure large instances for SAP HANA, Microsoft deploys the physical server, the SLES or RHEL OS with the required logical volumes for an SI to install the SAP HANA DB and applications that run on top of it. All management of the HDB and apps are responsibility of the SI or the customers
SAP HANA appliance model: SAP HANA software pre-installed by certified
hardware partners on validated hardware running a specific operating system
 SAP coordinates all support requests for all components of the system, including hardware, with the
responsible partners
 SAP is the main point of contact for all issues; SAP works with the hardware partner as needed
SAP HANA TDI model: Customer is responsible for software installation; the
customer is also responsible for defining support agreements with the
various partners and for managing support with all the involved partners
 Customers work with hardware partners on hardware support requirements
 Supportability tool called the HW Configuration Check Tool for SAP HANA * (documentation attached
to SAP Note ) allows customers to check if the hardware is optimally configured to meet the
requirements of SAP HANA
 Customers are also responsible for on-going system maintenance and support, including:
– initial software installation
– updating
– patching the OS and SAP HANA DBMS software

16. SAP HANA certifications
SAP Solution
Supported OS
Azure Offerings
SAP HANA Developer Edition (including the HANA client software comprised of SQLODBC, ODBO-Windows only, ODBC, JDBC drivers), HANA studio, and HANA database)1
SUSE Linux Enterprise Server (SLES), Redhat Enterprise Linux (RHEL)
A5-A11, D11-D14, DS11-DS14, GS1-GS5
SAP HANA One
SLES, RHEL
DS14_v2
SAP S/4HANA
Controlled Availability for GS52
SAP HANA on Azure (Large Instances)
SAP Business Suite on HANA (OLTP)
SAP HANA Platform or Enterprise Edition for SAP BW (OLAP)
GS5; SAP HANA on Azure (Large Instances)
1 Customers can try SAP HANA Developer Edition on Azure using the SAP Cloud Appliance Library.
2 Contact your Microsoft or SAP account manager for more information.

17. SAP on Azure (HANA) 448 GB 1-2 TB 0.76-2 TB 4 TB 60 TB 448 GB*2
448 GB
1-2 TB
OLAP
Single node / Virtual Machine *4 *3 TB
4 TB
60 TB
SAP on Azure (HANA)
Single node / Purpose Built Hardware
Multi-node / Purpose Built Hardware *1 *2
448 GB TB
OLAP : Business Warehouse (BW on HANA, BW/4HANA), Side Car, HANA Enterprise DWH
OLTP : S/4HANA, Business Suite on HANA, NetWeaver
Single node / Virtual Machine
OLTP *4 *3
Azure can run all kinds of HANA applications / and support both HANA scenarios / – OLAP and OLTP.
OLAP means Business Warehouse, / BW on HANA, BW/4HANA, HANA Side Car, HANA enterprise DWH / and data mart and so on. OLTP includes / S/4HANA, Business Suite on HANA and SAP NetWeaver / such as Portal, XI, PI or EAI, Solution Manager.
HANA database sizes that we can cover today / are the numbers that you can see in white in this slide.
For OLAP we can run HANA database / up to 448GB on Azure Virtual Machines / one GS5 VM, / and up to 4TB / on Large Instances one blade, / and up to 60TB / on Large Instances 15-node scale out. The numbers in red are what we’re going to release / and get SAP certification / by the end of this calendar year. We will be able to run / up to 2TB on Azure M Series VM / by the end of CY17.
As for OLTP / it’s up to 448GB with VM / for S/4HANA / and up to 20TB with HANA Large Instances scale up – one node / as of today. By the end of this CY / it will be up to 3.8TB with M Series VM.
Please note that Azure is now offering market’s best scalability / that many on-prem HANA hardware manufacturers cannot provide. We are still hearing / classic cloud vs. on-prem argument / such as / large production HANA stays on-prem / and only small non-prod goes to cloud. This is not true any more. TB TB
Single node / Purpose Built Hardware
24 TB
*1 : Controlled availability for S/4HANA
*2 : M Series will be available at East US2, West US2, West Europe, UK South, Australia East, Australia Southeast, Japan East, Japan West in CY17
*3 : HANA on Azure Large Instances are available at East US, West US, West Europe, North Europe, Australia East, Australia Southeast, Japan East and Japan West in CY17
Multi-node / Purpose Built Hardware (S/4HANA)

18. What is SAP HANA on Azure Large Instances ?
SAP TDI (Tailor Datacenter Integration) certified purpose built HANA hardware infrastructure hosted in Azure
HANA server blade
Storage hardware (persistent, 4 x RAM)
Snapshot backup capability
Storage replication capability in paired datacenter
Volume encryption capability
Network devices including backend ExpressRoute to connect to Azure VNET (10Gbps)
Supported HANA scenarios
OLAP : BW, BPC, Enterprise Edition, DWH, Side Car
Scale Out to 60TB
OLTP : Business Suite on HANA, S/4HANA, NetWeaver
Scale Up to 20TB
SKU #
# CPU threads
RAM (GB)
HANA NFS Storage (GB) (persistent)
Supported HANA scenarios
SAP Certification + GA (* subject to change)
HANA on Azure Large Instances Intel® Xeon® Processor E v3 (Haswell)
SR72 72
768
3,072
OLAP/OLTP
Certified
SR72m
1,536
6,144
OLTP
SR192
192
2,048
8,192
SR192m
4,096
16,384
HANA on Azure Very Large Instances
Intel® Xeon® Processor E v4 (Broadwell)
SR384
384
SR384m
18,432
SR384xm
22,528
SR576m
576
12,288
28,672
SR768m
36,864
SR960m
960
20,480
47,104
And what is SAP HANA on Azure Large Instances offering ? This is not regular Azure VM/, but SAP certified purpose built / HANA hardware infrastructure hosted in Azure.
We’re using Equinix colocation datacenter / to host these hardware / which sit behind Azure IaaS/VNET. HANA database hardware in colo / and SAP application server VMs in regular Azure VNET / are tightly connected thru / backend ExpressRoute / and network latency between colo and Azure / is kept within 2 ms.
HANA Large Instances offering includes / certified HANA server blade, / storage hardware with built-in capabilities of / snapshot backup, storage replication and volume encryption etc / and network devices including / backend ExpressRoute / to connect to Azure VNET which is 10Gbps.
Based on customer’s application scenario – OLAP or OLTP, / and how much memory is needed for HANA database, / you can pick Large Instances SKUs for HANA database/ while application servers can be hosted in Azure VM / as needed.

19. M-Series Virtual Machines Massive memory, CPU, storage, and scale
Hyper-Threaded support
Premium Storage support
Based on Intel® Xeon® Processor E v3
High Performance DDR4 memory
Support Nested Virtualization with Windows Server 2016
SAP Certified for Netweaver on AnyDB
HANA certification soon
Key talking points:
The M-series is the largest instance size with up to 128 virtual cpu’s (VCPUs). These instances support premium storage for low latency workloads and are designed for the largest enterprise workloads. These have huge RAM sizes from 1.75TB to 4.0TB of RAM!
VM size
vCPU’s
Memory: TB
Local SSD: TB
Persistent Data Disks Max
Network Bandwidth
Availability
M64s 64
1.0 2
Extremely high
GA in US
M64ms
1.75
M128s
128
2.0 4
M128ms
4.0
Launching soon

20. SAP HANA Scale-up
Single-node physical/virtual server with expansion capacity
Massive parallelism for query execution with maximal exploitation of available hardware
The challenge is NUMA effect on large multi-socket systems
Pros
No inter-node communication overhead
Less administrative overhead than for scale out deployments
Doesn’t require deep knowledge of application, data, and hardware for scaling
Cons
Limited scalability by hardware resources in one server
Potentially higher initial cost

21. SAP HANA Scale-out Shared nothing, multiple nodes acting together
One logical system but physically distributed database
Pros:
High scalability: Distributed systems can overcome hardware limitations of one single server by distributing load between multiple servers
Scale-out has wider range of scalability
Cons:
Inter-node communication overhead
Higher administrative overhead (as compared to scale up systems)

22. SAP HANA Business Continuity
Diagram sourced from SAP Teched Sept 2016 handouts
Host Auto Failover
System Replication
Storage Replication
Cluster like solution
Shadow DB like Solution
Common DR Solution
SAP HANA Host Auto-Failover for SAP HANA Scale-out: One node will fail (data-set is not complete anymore), Stand-by node will take over data and log files of failed node and will replace it (data-set is complete again).
SQL query can again retrieve data from all nodes in parallel. Multiple stand-by nodes are allowed but not common. One stand-by node is serving as fail-over target for any of the worker nodes – no data preloading possible
SAP HANA System Replication for SAP HANA Single-node Each SAP HANA node represents running instance. Only active node is having own data and log files. There are no data and log files on standby node. Data is written only to active node. SQL query will retrieve data from active node

23. Tools For HANA Migration & Migration Paths
Now that we learn about the HDB possible configurations, what is the migration path? What tools do people use for the migration?

24. SW Update Mgr. w Data Migr. Option
Diagram sourced from
Benefit of Database Migration Option (DMO) of Software Update Manager (SUM):
- Only one maintenance phase (not several) Reduces business downtime (TCO), less regression tests
- In-place migration keeps application server and SAP System ID stable Low impact on system landscape and interfaces: only database server is changed
- Original database is kept, can be reactivated as fallback Reduces risk, no restore required, more time for testing before cutover
- Lower prerequisites for SAP and DB start releases Reduces effort (total cost of implementation), no additional licenses for traditional database update

25. SAP Landscape Trans. – Repl. Server
Diagram sourced from SAP TechEd Sep 2016 session handout ‘DMM213 –A Holistic View on Transforming a Landscape to SAP S/4HANA’
10 min remaining
The SAP Landscape Transformation (SAP LT) Replication Server is the SAP technology that allows you to load and replicate data in real-time from ABAP source systems and non- ABAP source systems to an SAP HANA environment.
The SAP LT Replication Server uses a trigger-based replication approach to pass data from the source system to the target system.
The SAP LT Replication Server can be installed either as a separate SAP system, or if the technical prerequisites permit, on an ABAP source system.
You use a configuration to load and replicate data from one source system to one target database schema of a HANA system (1:1), or from multiple source systems to one target database schema of an SAP HANA system (N:1).
Furthermore, it is possible to load and replicate data from one source system to multiple (up to 4) target database schemas of one or more HANA systems (1:N). You can also specify the type of data load and replication - either in real-time, or scheduled by time or by interval.
For new Implementation: data from ABAP or non-ABAP systems can be selectively migrated to a HANA DB
For System Conversion: SLT can also be used for converting an existing SAP system (business suite like ECC for example) to SAP HANA DB
For Landscape Transformation: selected data from one or multiple sources can be migrated to one or more SAP HANA targets. Also used to migrate part of the application from a classic ERP system.

26. Path to BW/4HANA New Install - New to SAP or Ready for a Fresh Start
System Conversion - Convert your existing system
Landscape Transformation
Bring data from your old system to SAP BW/4HANA with SAP integrated data management and quality tools
If your current SAP landscape is over five years old, consider a fresh start
Leverages a modern data warehouse, no modifications or work-arounds of the past
Complete conversion of an existing SAP BW system to SAP BW/4HANA
If your current SAP landscape has been highly maintained (SAP BW, powered by SAP HANA), you most likely can convert to SAP BW/4HANA in just a few steps
Ideal for large enterprises with many instances of SAP and non-SAP BW systems
Consolidation into one global SAP BW/4HANA system or selective data migrations
BW4HANA see details info here ; Also see
New Installation: Also referred to as “greenfield approach”, this path start by installing a brand new SAP BW/4HANA system. You begin from scratch, connect any data sources – that could be a legacy data warehouse or any other data source available in your enterprise – and start modeling you data warehouse. If you run already a SAP Business Warehouse (BW) system today and want a fresh start, you can get a head start by transporting certain configuration and data models from your existing landscape to SAP BW/4HANA. Please note that this is only supported for the initial system setup, not for continuously updating the new landscape. And, of course, it’s only supported for objects that are fully compatible with SAP BW/4HANA.
System Conversion:, your intermediate target is to get to SAP BW powered by SAP HANA and transition to data models that are fully optimized for SAP HANA. SAP is working on a so called “Transfer Tool”. The tool is currently available as part of the SAP BW, edition for SAP HANA add-on (which installs in on your SAP BW 7.5 powered by SAP HANA system). This transfer tool allows you to create SAP HANA-optimized objects for all your standard SAP BW data models.
Landscape Transfromation: The third and final option is to optimize more complex data warehousing landscapes resulting in a single, global SAP BW/4HANA system.

27. Path to S/4HANA New Install - New to SAP or Ready for a Fresh Start
System Conversion - Convert your existing system
Landscape Transformation
Installation SAP NetWeaver Application Server ABAP 7.5 based on SAP HANA
Installation of SAP S/4HANA
Installation SAP Fiori for SAP S/4HANA
Update to SAP NW App Server ABAP 7.5
Migrating the db to SAP HANA (in case the SAP Business Suite system is not yet on SAP HANA)
Install SAP S/4HANA
Install SAP Fiori for SAP S/4HANA
Migrate data from the old data structures to the new simplified data structures
Possibly a new installation of a SAP S/4HANA
Possibly converting a system to SAP S/4HANA
Additional migration steps that are based on SAP Landscape Transformation combined with SAP Landscape Optimization services
New Install - Focused on net-new customers (coming from any legacy system) or SAP Business Suite customers that start for different reasons with a new installation. Benefit with this path is the re-engineering and process simplification based on ready-to-run business processes and reference solution delivered with the solution; new implementation of industry-leading Business Suite; pre-defined migration objects & Best Practices available in a guided process
System Conversion - This scenario is focused on existing SAP Business Suite customers that want to change their current system into a SAP S/4HANA. Benefit include migration without reimplementation; no disruption for existing business processes; re-evaluation of customization and existing process flows
Landscape Transformation - This scenario is focused on existing SAP Business Suite customers that want to change their current system or system landscape into a SAP S/4HANA. Benefit include staying with current business processes and move gradually to SAP S/4HANA innovations; harmonized business processes and shared master data through consolidation; carve out of single entities of the company to SAP S/4HANA and leverage process simplification

28. SAP HANA Admin tools

29. SAP HANA Administrative Tools
Native Tools for SAP HANA Database Administration
SAP HANA Cockpit
SAP DB Control Center
SAP HANA Studio
Use for: Core administration and detailed monitoring of a single SAP HANA database
• Web-based SAP Fiori launchpad
• Runs on SAP HANA XS Classic
Use for: Administration and monitoring of the entire SAP HANA database landscape
• Web-based SAP Fiori launchpad
• Runs on SAP HANA XS Classic
Use for: SAP HANA basic administration tasks and development including modeled views
• Eclipse-based IDE
• No longer in feature development
Native tools for SAP HANA administration:
SAP HANA Cockpit is used for Core administration and detailed monitoring of a single SAP HANA database. It is a Web-based SAP Fiori Launchpad and runs on SAP HANA XS Classic
SAP DB Control Center is used Administration and monitoring of the entire SAP HANA database landscape, It is a Web-based SAP Fiori Launchpad Runs on SAP HANA XS Classic
SAP HANA Studio is used for SAP HANA basic administration tasks and development including modeled views. It is Eclipse-based IDE. This tool is depreciated and no longer in feature development but there are customers still using it.
The next generation of development tool is SAP Web IDE for SAP HANA that runs on XS Advanced providing SAP HANA Dev & Modelling, SAPUI5 & Node.js Dev Tools

31. Appendix

32. SAP NetWeaver App Server Architecture
Diagram sourced from
Dual-stack (ABAP & Java)
Only a few applications on dual-stack
Single stack servers are more common
Key pieces in App Server:
SCS (Message, Enqueue)
Work Processes
Dispatcher
Internet Comm. Mgr.

33. SAP Applications run on SAP HANA
SAP Business Warehouse
Classic SAP BW – Netweaver based BW on HANA referred to as BW powered by HANA or BW on HANA
BW/4HANA – Next-gen version of BW that is completely optimized and tailored to SAP HANA
SAP Business Suites
Classic ERP applications – ECC, SCM, CRM etc. marketed as Suites on HANA or ‘Powered by HANA’
S/4HANA – New generation of ‘simplified’ data schema style of applications like Enterprise Management, LoB Products
BW/4HANA is an evolution of BW that is completely optimized and tailored to SAP HANA. The BW/4HANA code can only run on SAP HANA as it is interwoven with SAP HANA engines and libraries. For more details see
The SAP S/4HANA family is fully built on the in-memory platform SAP HANA. Using the advanced potential of SAP HANA, SAP S/4HANA is designed for your digital business and provides an instant insight by using a single source of truth, real-time processes, dynamic planning and analysis. With SAP Fiori user experience and less complex data model it is designed to run simple, and in parallel reduces the data footprint
SAP S/4HANA Enterprise Management is designed for enterprises across industries that need a deep and broad level of functionality combined with a high degree of flexibility in customization. It includes functions like Asset Management, Finance, Human Resources, Manufacturing, R&D Engineering, Sales, Sourcing and Procurement, and Supply Chain etc.
SAP S/4HANA LoB and industry Products enhance core functions of SAP S/4HANA Enterprise Management to provide additional business benefit for your line of business (LoB). Includes functions like: Asset Management for Environment, Health, and Safety, Commerce Management, Finance, Contract Accounting, Master Data Management etc. These products designed and configured for specific industries: Automotive, Banking, Insurance, Oil & Gas, and Professional Services.