Best practices for budgeting, sizing, and migrating your SAP BW system to SAP BW 7.4 on SAP HANA Dr. Bjarne Berg COMERIT

In This Session Learn how to create a realistic budget for your SAP BW to SAP BW on SAP HANA migration and how to correctly size your environments. In this session, explore the options for scale-out vs. scale-up hardware architectures and their respective costs and complexities. Hear about lower cost alternatives such as MCOD, MCOS, MDC, virtualization, and cloud Walk through a step-by-step migration plan for SAP BW to SAP BW on SAP HANA using the Direct Migration Option (DMO) tool Hear about migration caveats and gotchas in terms of security conversions, query conversions, dataflow conversions, and Unicode requirements

Introduction – Dr. Berg

What We’ll Cover Introductions Sizing a SAP HANA Environment for BW 7.4 HANA Environment Deployment Options Migrating and Upgrading using the DMO option of SUM BW 7.4 Upgrade Considerations Wrap-up

There are several sizing options depending on the software components: Sizing Overview There are several sizing options depending on the software components: BW system for HANA QuickSizer – New implementation only, not migrations BW Automated Sizing Tool in the Migration Cockpit Rule of Thumb T-Shirt Sizing

SAP QuickSizer for HANA There are three versions of the tool for each version of SAP HANA The QuickSizer for the Business Suite allows you to size for specific modules The second QuickSizer version is for SAP HANA on SAP BW The last is for those who want to use SAP HANA as a standalone platform for in-memory data (i.e., using SAP Data Services to load data to) SAP’s QuickSizer for SAP HANA is available at: http://service.sap.com/quicksizer. * Requires login credentials to the SAP Service Marketplace.

SAP QuickSizer for New BW HANA Implementations If you’re using planning in SAP BW, enter the info here. The fields marked with * are mandatory. For H-PLAN-1, enter the maximum concurrent users in the USERS field. The S.T. and E.T. fields are the start and end times for the processing. By entering this type of information, you’ll get estimates of loads on the SAP HANA system by time periods at the end of the sizing exercise. Enter the estimated number of information consumers (H-BW-INFO), business users (H-BW-BUSI.), and experts (H-BW-EXPER). SAP suggests a ratio of 71%, 26% and 3% for each user group, but you can enter your own mix if you have better estimates.

SAP QuickSizer for BW on HANA — Output This SAP HANA sizing example calls for 1.6TB of memory In this case, SAP HANA for BW will deploy the master data, ABAP system tables, and most row store data on the master node. The other connected Index server node(s) will contain the InfoCubes and DSOs.

HANA Sizing Tool for Existing BW Implementations Using the BW Automated Sizing tool in the Migration Cockpit

HANA Sizing Tool for Existing BW Implementations To increase speed, you can suppress analysis tables with less than 1 MB size SAP has released an updated tool that generates a report significantly better for sizing SAP BW than using the QuickSizer. This tool should be used by all existing BW implementations for sizing (QuickSizer is only for new implementations). This program takes into consideration existing databases, table types, and includes the effects of non-active data on the HANA system The higher precision you run the estimate at, the longer the program is going to run With 8 parallel processors and 10TB database, it is not unusual to see 4-5 hours runtime

SAP BW on HANA Automated Sizing Tool Since timeouts are common when running the sizing program, you can temporarily change the parameter in rdisp/max_wprun_time to 0 in BW transaction RZ11. Finally, you estimate the growth for the system as a percentage or as absolute growth. The output is stored in the file you specified and the file can now be emailed to hardware vendors for sizing input and hardware selection This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace

Rule-of-Thumb Approach to Sizing HANA — Memory Memory = 50GB + [ (rowstore tables footprint / 1.5) + (colstore tables footprint * 2 / 4) ] * Existing DB Compression The 50GB is for HANA services and caches. The 1.5 is the compression expected for rowstore tables and the 4 is the compression expected for column store tables. The 2-factor refers to the space needed for runtime objects and temporary result sets in HANA. Finally, the term “existing DB compression” is to account for any compression already done in your system (if any). Remember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases

Rule-of-Thumb Approach to Sizing HANA — Disk & CPU The next item you need is disk space, which can be estimated by the following: The persistence layer is the disk that keeps the system secure and provides for redundancy if there are any memory failures, so it’s important not to underestimate this. The CPUs are based on the number of cores that you include. For example, 18 core CPUs now exist (depending on when you bought your system). If you have a single node with 8 x 18 cores, you will have 144 cores and can handle about 720 active BW users on that hardware node, and quite a larger number of named users. Disk for persistence layer = 4 Memory Disk for the log = 1 Memory CPU = 0.2 CPU cores per active user Remember, these are quick rules of thumb, so don’t rely on it for finalized budgeting and hardware purchases

A T-Shirt Model for Sizing HANA on BW A T-Shirt model is a quick way to get some basic ideas on what a system may look like While very inaccurate for sizing, it provides basic information for those just starting to consider SAP HANA The number of processors are largely driven by the number of users and usage patterns. Serious consideration should be made before buying hardware.

Summary of HANA Sizing Approaches Work with your preferred vendor before ordering your hardware or finalizing your budgets Approach Quality of Estimate Effort Required T-Shirt Sizing  Sort of “OK” Very Low Rule of Thumb  Better Low SAP QuickSizer  Much better (new implementations only) High Sizing for programs  Excellent (for existing BW systems) Moderate/Low SAP Note 1736976 (ABAP report to help with BW on HANA Sizing) SAP Note 1909597 (SAP BW Migration Cockpit for SAP HANA) SAP Note 1729988 (SAP BW Checklist for Migration) SAP Note 11855041 (Sizing the Master node)

Hardware Options Sept 2015 Onward

Hardware Options Sept 2015 Onward These systems are based on Intel’s E7 IvyBridge processors with 15 cores per processor, or the newer Hartswell processors with 18 cores.

Key Cloud Options Infrastructure as a service – IaaS Think of your options in terms of Infrastructure as a service – IaaS Platform as a Service – PaaS Software as a Service - SaaS

What We’ll Cover Introductions Sizing a SAP HANA Environment for BW 7.4 HANA Environment Deployment Options Migrating and Upgrading using the DMO option of SUM BW 7.4 Upgrade Considerations Wrap-up

Landscape Deployment Planning Scenario Virtualization MCOS MCOD Technical Co-Deployment HANA DBs Multiple One DB Schema Availability Supported for DEV & QA systems Defined by: White List 1661202 for BW White List 1826100 for Suite Business Suite components SCM and/or SCM co-deployed with ERP

Save Money with MCOD and MCOS You may not need separate hardware for sandbox and development environments Using Multiple Components One Database (MCOD) and/or Multiple Components One System (MCOS) you can simplify the number of hardware environments you need SAP BW on SAP HANA SAP Finance and Controlling Accelerator for the material ledger ERP operational reporting with SAP HANA SAP Finance and Controlling Accelerator: Production Cost Planning SAP Rapid Marts SAP COPA Accelerator SAP Operational Process Intelligence SAP Cash Forecasting SAP Application Accelerator/Suite Accelerator Smart Meter Analytics In addition to custom developed datamarts, all items above can run in an MCOD setup (see SAP Note 1666670 for more details)

BW HANA MCOS - Example In this real example, we sized a 2.5 TB BW system for migration to SAP HANA

Example from Real Company - BW HANA System Landscape MCOS Note that the QA and Production system are kept the same size so that performance tests are accurate and so that the QA system can be used as for disaster recovery

Multitenant Database Containers (MDC) Deployments APPLICATIONS A tenant database is a single database container You can save money by running multiple tenant databases on a single HANA system MDC is supported for production systems and you can backup for each tenant database You can manage resources such as memory and CPU for each of the tenant databases Application A Application B SAP HANA System Database Tenant Database Tenant Database MDC became available with SP-9 of HANA in 2015

MDC Deployments Details MDC can be used in Platform & Enterprise Cloud For on-premise it can replace most MCOS deployments and many of the MCOD scenarios There is no virtualization overhead, and scale-out systems with standby nodes is supported You can use SQL to query across databases: I.e., SELECT * FROM schema1.Customers AS tab1, db2.schema2.Customers as tab2 WHERE tab2.column2 = ‘Johnson’ NOTE: Attribute and analytic views must be converted to calculation views to be used as remote tenant database objects Individual database backups and restores can be done from HANA Studio A new privilige “Database Admin” allows you to seperate admin access to each database You can convert a HANA system to MDC, but it cannot be converted back (command: hdbnsutil –convertToMultiDB)

The HANA cockpit can monitor both the system and tenant databases MDC Monitoring The HANA cockpit can monitor both the system and tenant databases You can connect to any system and tenant database using HANA studio. The DBA Cockpit can also be used to monitor databases

What We’ll Cover Introductions Sizing a SAP HANA Environment for BW 7.4 HANA Environment Deployment Options Migrating and Upgrading using the DMO option of SUM BW 7.4 Upgrade Considerations Wrap-up

The SAP_BW_BEFORE_UPGRADE Task List If you are on 7.0 SP31 or higher, you can generate an “SAP BW Before the Upgrade task list” and get help in preparing the system for the upgrade The more of these tasks you complete, the faster the upgrade may proceed since you are reducing size and complexity, while assuring that your system is ready for the 7.4 upgrade You first have to install the program from SAP Note 1734333 before you can generate the SAP_BW_BEFORE_UPGRADE task list using tcode STC01

Pre-Steps Before Staring SUM (Software Update Manager) To start the process, you will need some disk space for the SUM tool, the download directory, the Trans directory, as well as some space for the shadow system that will be created during the upgrade SAP recommends that you have at least the following disk space available in your source system: 20GB for the temporary download directory and the DIR_TRANS directories (each) 8GB for the SUM directory The size for the shadow system equal to the size found in this directory: \usr\sap\<sapsid> (Windows systems) /usr/sap/<SID> (IBM i systems) /usr/sap/<sapsid> (UNIX systems) During your upgrade, the SUM will create a “shadow” system for your non-data files and you will need some space for this

Upgrade Decision: Low, Standard, and High Resources A major decision is: Are you going to minimize the system downtime or do a low resource upgrade? The trade-off is between using more system resources or downtime. In the “standard” upgrade, you create a shadow system while the BW system is still operating. You turn off any archiving to make sure you do not miss any data and do your system backup right before the downtime starts. Therefore, you can do much of the upgrade before the downtime (shorten the outage). In a very high system resource upgrade, you also use a shadow system, but imports are much faster and you can keep archiving on (may create large logs), but downtime starts earlier. Most companies should use the standard upgrade method, unless their system is very small or they have limited resources. For those, the shadow system is created during the downtime.

Shadow System During the Upgrade Application Data Target Release SAP NW BW 7.4 XPRA Import & Data Conversion You use a shadow system to reduce the system outage Target Release System Application Data Source Release Target Release Shadow System - High system resource – locks system in the REPACHK2 phase - Standard system resource – locks system in the REPACHK2 phase - Low system resource – locks system in the LOCKEU_PRE phase Source Release System Target Release System SPDD Shadow System Installation Application Data Target Release BW 7.0 (or higher) BW 7.x

Step 1: Hardware Install, Dev Copy, and Sandbox Upgrade BW 7.x Sandbox BW 7.x Dev. Box BW 7.x QA Box BW 7.x Prod Box In this example, we are installing new hardware. This creates a lot of flexibility and less project risk! First, we copy the BW 7.x development box to the new hardware Second, we upgrade the new sandbox in a controlled manner and document all activities 1 An Example BW 7.4 Sandbox We want to create a repeatable process, so no ad hoc activities are allowed. Remember, extra time has to be set aside for notes research and unforeseen issues. BENEFITS: This is also a test run for upgrading the development box (!), thereby reducing the upgrade risk. After the upgrade, we also get a refreshed sandbox environment.

Step 2: Development Box Copy and Upgrade BW 7.x Sandbox BW 7.x Dev. Box BW 7.x QA Box BW 7.x Prod Box Now we have to freeze all development activities Normally, the work in the 7.x dev box is transported to QA for testing and the dev box is locked An Example 1 2 BW 7.4 Sandbox BW 7.4 Dev. Box Using the upgrade “runbook” and all steps collected and written during the sandbox upgrade, we are upgrading the new development box. This is intended to be a structured approach that is repeatable. The developers participate in in-depth testing of the new 7.4 dev box BENEFITS: The outage of the development box occurred after the sandbox upgrade and the development outage is minimized. This is also the second time we have upgraded the development box, so any issues should be well known.

Step 3: Production Box Copy and QA Upgrade BW 7.x Sandbox BW 7.x Dev. Box BW 7.x QA Box BW 7.x Prod Box We copy the production environment to the development box after all testing in the QA has been completed and all the objects have been transported to the production system 2 3 1 An Example BW 7.4 Sandbox BW 7.4 Dev. Box BW 7.4 QA Box Notice that no copies of Sandbox or QA are made. Instead, we get to upgrade the development box and the production box “twice.” This is a significant risk mitigation strategy, but requires that transports and client-dependent objects are switched back on the new Sandbox and QA systems BENEFITS: This approach turns the QA upgrade into a real “dress rehearsal” for the production box upgrade. Also, since we are switching the hardware, the risk to the upgrade is minimal (BW 7.x prod is not taken offline until after the upgrade).

Step 4: Production Box Copy and QA Upgrade BW 7.x Sandbox BW 7.x Dev. Box BW 7.x QA Box BW 7.x Prod Box You are now ready for the cutover weekend The best timing is to start the production box on Thursday evening after the BW system has completed data loads. A full backup is taken. The system is unavailable on Friday and is completely upgraded by Saturday 6 am Consider the time it takes for security conversion, unless already done in the 7.0/7.3 upgrade 2 1 An Example 3 4 BW 7.4 Sandbox BW 7.4 Dev. Box BW 7.4 QA Box BW 7.4 Prod Box Plan for having Basis and technical people working the night from Thursday to Friday and possibly to Saturday, depending how long the upgrade takes

Direct Migration Option (DMO) During the upgrade from BW 3.x to version 7.0 many companies decided not to complete Unicode conversions, security conversion, and other recommended steps Since these are now required for the BW 7.4 and the subsequent migration to HANA, some companies are planning first to do the upgrade and then do a migration project. That is a mistake! With the new Direct Migration Option tool you can accomplish both the 7.4 upgrade and the HANA migration in one step. DMO is a key option in the Software Update Manager (SUM), for those with older, out-of-date, BW systems that want to migrate to HANA.

Creating a DMO Migration Run-Book The best way to approach this is to start with the sandbox system and create a runbook with step-by-step lists on how each problem and software task are created. It is not unusual to have a 90-100 page word document with screenshots and documentation at the end of this first migration. The “runbook” is the key to success. You should build on this when you migrate to the Development and then the QA and the Production systems DMO now also support Unicode conversions Speed is not important in the first sandbox migration. The creation of a repeatable process is far more important.

A 108 Step Example of a DMO Migration Runbook There are many repertory task you must do before the actual migration In steps 1,2, and 3 we are reviewing the latest notes and setting up user and system access In step 4.2 you must request a migration key

DMO and UniCode For those doing a Unicode conversion, there are many additional steps. We first need to check what is already in-place. Thankfully, SAP provides programs to help you with these to check the config. You can get this report by running the report UCCHECK and seeing the installed languages in the source system by using the transaction SMLT

A 108 Step Example of a DMO Migration Runbook (cont.) The next major step is to extract the files needed for the migration. Here you will need the migration keys you obtained in step 4.2.

A 108 Step Example of a DMO Migration Runbook (cont.) If you are working with a BW system that is not heavily used, or one that has lots of processing capacity, you can minimize the downtime by using a “shadow system” during the upgrade If you use a shadow system (option 2/3), the system will be copied (not the data) and many of the upgrade tasks will happen on this “shadow’ system” while the real system is still running Only in the later stages is the system unavailable to the users while the configuration and data are moved to SAP HANA This minimizes the downtime of the system

A 108 Step Example of a DMO Migration Runbook (cont.) Now we have to tell the DMO what system we are coming from and what system we want to migrate to

A 108 Step Example of a DMO Migration Runbook (cont.) It is now time to check inside SAP HANA Studio that the BW schema has been created by DMO. You find this under “users” in the HANA navigator. We also have to decide what support packages we want to include in the upgrade. Normally we pick the latest and ignore the equivalent SPs.

A 108 Step Example of a DMO Migration Runbook (cont.) In the check phase, you may get “soft warnings” or items that have to be fixed before progressing. Pay close attention to both and make sure you understand what each mean.

A 108 Step Example of a DMO Migration Runbook (cont.) If you did not complete the in-depth cleanup tasks we recommended earlier, you can now do some basic system cleanup as well Most of the cleanup tasks are better performed prior to starting this process

A 108 Step Example of a DMO Migration Runbook (cont.) Since the “shadow system” is created, no more changes to the configuration or settings in the existing BW system can occur after this stage NOTE: Users can still access the system

A 108 Step Example of a DMO Migration Runbook (cont.) If we want to make changes to the shadow instance, we can do that by logging on as user DDIC and changing the system setting using the transaction code SE06. We can now make changes directly using the transaction code SPDD

A 108 Step Example of a DMO Migration Runbook (cont.) After the tables have been created in the HANA system, you can reorganize them This allows you to load balance the HANA system even further before completing the migration of the data from BW to HANA This is not a required step for most systems

A 108 Step Example of a DMO Migration Runbook (cont.) We now have to lock down the system and stop all jobs and access

A 108 Step Example of a DMO Migration Runbook (cont.) Before we proceed any further and start migrating the data, we should complete a full backup of the system

A 108 Step Example of a DMO Migration Runbook (cont.) We now are in the lockdown and downtime phase. The instance is running as a “remote host” and we will start moving data to the new system.

A 108 Step Example of a DMO Migration Runbook (cont.) Before we provide users and developers access to the new system and start testing, you should run another backup of the system so that valuable time can be saved if you have to revert back to a pervious system

A 108 Step Example of a DMO Migration Runbook (cont.) At this stage the users can access the new system and start the testing of the migration. We normally have both technical and functional testers involved in this phase.

A 108 Step Example of a DMO Migration Runbook (cont.) We are now ready to access the HANA system and all post-processing tasks have been completed The next step is to start the development migration using the runbook

What We’ll Cover Introductions Sizing a SAP HANA Environment for BW 7.4 HANA Environment Deployment Options Migrating and Upgrading using the DMO option of SUM BW 7.4 Upgrade Considerations Wrap-up

The SAP_BW_HOUSEKEEPING Task List If you are on 7.0 SP32 of higher, you can generate an SAP BW Housekeeping tasks list and get automated help in cleaning the system weeks before upgrading it Check BW metadata with DDIC Delete RSTT traces Delete BW statistical data Delete Aggregate data via deactivation Ensure partitioned tables are correctly indexed for PSA Ensure request consistencies in the PSA Re-assign requests written into the incorrect PSA partition Verify DataSource segments assignment to PSA Deletes the entries no longer required in table RSIXW Clear all OLAP Cache parameters Repair InfoCube fact table indices at Data Dictionary level Reorganize and delete bookmark IDs and view IDs You first have to install the program from SAP Note 1829728 before you can generate the SAP_BW_HOUSEKEEPING task list using tcode STC01

Pre-Steps: BI Content Consistency Checks (Optional) If you suspect inconsistency in the BI content, or are planning to deploy new BI content, you can run the BI Content Analyzer. This can be as a transparent table or loaded to a DSO (tcode RSBICA) The automated BI Content Analyzer Checks include: Inactive Transfer Structure checks List of InfoObjects without an InfoObject Catalog Inconsistent Roles check Routines that refer to fixed, programmed structures Query Elements with Duplicate GUIDs Several Object Collection Errors Several Object Status checks Many checks for Inconsistent Naming Conventions To help plan any testing, you can also get a list of where the objects in your SAP NetWeaver system are used (SAP Note: 28022)

Pre-Planning: BEx 3.5 Query Designer Is Obsolete BEx Query Designer 3.x is obsolete and not supported. The runtime and tools from SAP BW 3.5 are not available in version 7.4. SAP has created a tool that checks your system and will let you know what old query features you may be using that are no longer supported. The check tool can be found in SAP Note 1911469. More information on BEx 3.5 can be found in SAP Note 1932461 You can find step-by-step help to migrate your old BW BEx to 7.0 in the “cookbook note” 1807522

Other Mandatory Tasks and Gotchas with BW 7.4 Some companies did not do the recommended security migration when upgrading to BW 7.0. They now have to migrate to the “new” analysis authorization concept. The old 3.x is no longer supported. Unicode conversion was also strongly recommended with the BW 7.0 upgrade, but many companies did not compete that either. Now it is required. The maximum length of characteristic values has been increased from 60 to 250 characters. This can cause issues with key fields that are also assigned to this domain (RSCHAVL), since the max field length may be exceeded. (Look in SAP Note 1879618 to avoid issues with this). Since this domain uses the data type “SSTRING” you should also test any custom coding using this data type.

Engines, Clients, and Usage Types Based on what you are planning to use, you may need to install different clients, usage types, and standalone engines For example, for the BW Admin Cockpit, you need Enterprise Portal Core, the application portal, EP Core, and BI Java installed You will also need the Java application server (AS) installed to use the Wizard for the BW basic configuration, even though this component is ABAP based Make sure you carefully read the BW 7.4 master guide on SAP Marketplace to find out what components you are using and what you need to upgrade. There are also separate install guides for AS Java and AS ABAP on the SAP Marketplace.

JAVA Server for UD Connect and BEx Broadcasting Universal Data Connect is a tool to get data connection set up so that data can be loaded to the SAP BW 7.4 system If you want to use UD connect, you will have to install, or upgrade, the Java Application Server You will also need the Java Application Server if you want to use features such as the BEx Broadcaster For many customers, installing or upgrading the Java application server makes sense to take advantage of existing and future capabilities. For older BW systems, splitting the stack and also keeping the Java server separate from the Enterprise Portal Java sever is the recommended approach for most organizations.

Useful Hints for Older 3.x Systems If some of the InfoSets become inactive, you can still use the program RSQ_ISET_MASS_OPERATIONS to activate all InfoSets If you are still on 3.5 queries or older versions (i.e., 3.1c, 3.0B), consider running the program RSR_GEN_DIRECT_ALL_QUERIES to regenerate all queries in the system into the 7.0 release BW 7.0 had a new transformation concept that replaced transfer and update rules, but not all companies have migrated. To do so now, you can convert the DataSources and the Persistent Staging Area to the new DTP process (see SAP Note 906789). [Note: the PSA becomes less important in 7.4 when using Operational Data Provisioning (ODP), since it does not use the PSA]. To test the conversion of the DataSources you can also run: RSSM_CREATE_REQDONE_FROM_SEL; RSSM_HASH_ENTRIES_CREATE for all requests; RSSTATMAN_CHECK_CONVERT_DTA; RSSTATMAN_CHECK_CONVERT_PSA.

BW InfoCube Data Classes That Are Incorrectly Assigned DDART data classes may have been set up in your system that don’t follow standard naming conventions (see SAP Note 46272) These data classes were assigned to InfoCubes in the RSDCBE transaction. To correct a data class assignment you should use the report RSDG_DATCLS_ASSIGN. During the upgrade, if you don’t assign them correctly, these classes are lost and tables that are generated for the InfoCube may not be correctly activated To assure that all DataSources Web services run correctly after the upgrade, you could run RSDS_DATASOURCE_ACTIVATE_ALL after the upgrade (see SAP Note 1494272)

Staffing a HANA Migration Project — Small Team System Profile Raw data size: 2.7 TB Complexity: Medium DataStores: 87 InfoCubes: 63 Queries: 409 Duration: 14 weeks Environments: 4+1 Risk aversion: Medium Other usage: Integrated Planning The test team was dedicated for 9 weeks during the migration of QA and Prod environments The test team from the business was comprised of experienced users of the BW system and needed minimal training HANA Optimization of InfoCubes was done for SD reports only in this migration This organization was using BWA 7.0 and retired it as part of the HANA migration, thereby saving licensing costs for this platform

Staffing a HANA Migration Project — Medium Team System Profile Raw data size: 5.6 TB Complexity: Medium DataStores: 439 InfoCubes: 603 Queries: 1,300+ (incl. BOBJ) Duration: 18 weeks Environments: 4 Risk aversion: HIGH Other usage: None The testing of core queries in BEx and Web Intelligence was done by the business The data reconciliation and process chain testing were done by dedicated resources in each team The team must be staffed with experienced resources. HANA training for team members and hardware installs should be in place prior to project start.

Staffing a HANA Migration Project — Very Large Team System Profile Raw data size: 38TB Complexity: High DataStores: 1,300+ InfoCubes: 1,720+ Queries: 2,600+ Duration: 5 mos Environments: 4 Risk aversion: HIGH Other usage: APO, IP, BPC This assumed minimal additional functional optimization

What We’ll Cover Introductions Sizing a SAP HANA Environment for BW 7.4 HANA Environment Deployment Options Migrating and Upgrading using the DMO option of SUM BW 7.4 Upgrade Considerations Wrap-up

Where to Find More Information http://help.sap.com/nw_platform SAP BW 7.4 SAP Core help website http://scn.sap.com/docs/DOC-35096 Michaela Pastor, “SAP Business Warehouse 7.4” (SCN, April 2015). http://scn.sap.com/docs/DOC-35784 Michaela Pastor, “SAP NetWeaver 7.4  BW ABAP Support Packages” (SCN, March 2015). Jesper Christensen and Joe Darlak, SAP BW: Administration and Performance Optimization (SAP PRESS, 2014).

7 Key Points to Take Home SAP BW 7.4 has significant benefits for both HANA and non-HANA customers SAP has created many tools and checklists to make the migration and upgrade as painless as possible For HANA customers, BW 7.4 is the best release (by far!) The new Direct Migration Option (DMO) allows you to upgrade and migrate your BW system to HANA in one project The continued use of a shadow system during the upgrade minimizes the downtime Older systems may need a little more love and care as part of the upgrade, and manual interventions may be required BW 7.4 has now been available for over 24 months and is a stable, solid release to migrate to

Your Turn! Dr. Bjarne Berg