How to upgrade to SAP BW4HANA and BW

How to upgrade to SAP BW4HANA and BW 7.5 on SAP HANA — Potential pitfalls and tried and true instructions for success

Dr. Bjarne Berg

PwC

What We’ll CoverIntroductions

BW 7.5 Edition for HANA Vs. BW 7.5 on HANA

New

enterprise Data Warehousing Capabilities Hardware and Landscape Deployment OptionsThe DMO and the Logical Upgrade ApproachWrap-up

There is a Difference Between BW 7.5 “Powered

by”

&

“Edition” for HANABW 7.5 edition for HANA allows you to develop objects faster without having to use many of the old objects from BW 3.x and 7.0/7.3/ 7.4.

This allows you to run BW in a much more simplified way and use only HANA optimized objects

Why SAP BW 7.5, edition for SAP HANA

Simplified administration

Faster development time

Easier to maintain by having less replicated object and data

Smaller HANA memory footprint

Better modeling interface in Eclipse

Centralized development and admin interface.

SAP BW 7.5,

‘edition for HANA’ and ‘on HANA’

As you plan to move to SAP BW 7.5, you can still leverage the older objects, but long-term you should migrate to the new BW 7.5 edition for HANA objects

SAP BW 7.5, ‘edition for HANA’ – Compatibility Mode

Administrative tasks are

currently maintained

in the Warehousing Workbench as is some objects, such as DataSources.

Technical

BW requirements for AddOn "BW, edition for SAP HANA“

(SAP Note: 2285440)

BW

,

edition

for

HANA

-

pre-requisites/installation/ de-Installation/Update

(SAP Note: 2246699)

If you install Add-On

1.x

the system is moved to a “Compatibility Mode” to allow the migration to new objects. After that, the BW system can be switched from “Compatibility Mode” to “Operation in B4H Mode” (if you have problems, you can switch back to “Compatibility Mode”).

Getting to SAP BW 7.5, edition for HANA

For companies with BW 7.3 or 7.4 on HANA, or those who have not yet migrated to HANA, it makes sense to upgrade and migrate to BW 7.5 on HANA first, and then migrate to the new objects.

For those staring with a new implementation, it makes sense to start directly with BW 7.5

Edition

for HANA and only use the new simplified and faster objects

What We’ll CoverIntroductions

BW 7.5 Edition for HANA Vs. BW 7.5 on HANA

New Enterprise Data Warehousing Capabilities

Hardware and Landscape Deployment OptionsThe DMO and the Logical Upgrade ApproachWrap-up

Simplifying Source Connectivity Options

SAP BW 7.5 on HANA will consolidate

connectivity options so that:

Operational Data provisioning (ODP) will be used for SLT and SAP source systems.HANA Source System

will be used for other file system and database connectivity

While the

current source system connectivity option are still available

SAP is working on simplifying and consolidated HANA objects.

Advanced DataStoreObject (ADSO) – New in SAP BW 7.4

This new ADSO can be used to merge InfoCubes and

DSO into simpler data

architectures, and the ADSO can have up to 120 key fields.The new table

structure

in ADSOs means that the management and performance of frequent data loads is also improved.

In the new SAP BW 7.5

you can also combine InfoObjects and field based modeling, while leveraging SID entries can be used for query optimization

In many cases you can

even change the

usage scenario

of Advanced DataStore Objects without having to delete the data

Advanced DataStore Object – New in SAP BW 7.5

New migration tool that allows you to migrate older BW objects to ADSOs

ADSO support for planning and NLS

Improved delta calculations for non cumulative key figures (useful for areas such as inventory and headcount and more).

More dynamic tiering support

for

with change logs and data activation.

SAP has said it is planning to add streaming options in real-time to the ADSO in the future

(source: Lothar Henkes,

SAP SE)

Enhanced Composite provider in SAP BW 7.5

New improvement for BW 7.5 include CompositeProviders that now take advantage of the performance improvements introduced in HANA SP-10 and therefore executes faster.

You can also group similar output structures for easier access.

In BW 7.5 you can

also convert

existing CompositeProviders and BW MultiProvider automatically.

SAP is working on adding the support for temporal

joins

in CompositeProviders. This may allow customers to completely remove the need for InfoSets

New

Features in SAP BW

7.5 – Query Designer in Eclipse

Most BEx query developers will find this interface easier to use and can make the transition without the need for major re-training

New Workspace Query Designer in BW 7.5

In the new Workspace Query Designer you can now let key business users upload and merge data in queries with local and BW data..

It leverages the data authorization in BW.

To create SAP BW Workspaces, a business user need to have the role

SAP_BW_WORKSPACE_DESIGNER

assigned to them

Planned for future: Planned integration into SAP BI front ends (BI Design Studio Integration, Analysis Office)

BW 7.5 and Near-Line Storage (NLS)

NLS support has been available for InfoCubes with non-cumulative key figures in BW 7.4 since 2014.

In BW 7.5 you now can:

Using specific join types CompositeProviders can now use ADSOs stored on NLS.

Use BW process type to create NLS DB statistics by leveraging virtual tables.

Use NLS for ADSOs and also display reporting value help from NLS

(note 2215265

)

SAP BW 7.5 Dynamic Tiering - Enhanced support

Dynamic tiering of data in BW has been available since BW 7.4. This means that:

Data that is infrequently used automatically gets off-loaded to disk and thereby saving memory for more important tasks.

Saves memory (and money) by moving traditional write-optimized DSOs and PSAs to ‘warm’ storage.

New BW 7.5 features:

Data movement to dynamic tiering automatically as remodeling tasks

ADSO dynamic tiring support for change logs and activations

As first

introduced

in HANA

in 2015,

BW 7.5 now takes more advantage of Dynamic Tiering, thereby keeping more of low usage data in BW on disk instead of memory (costs savings

).

Operational Data Provisioning You can distribute your data using OData capabilities in BW 7.5.

You can even use OData for

Delta data loads

from ADSOs in BW 7.5You can create access by generating a NetWeaver Gateway

Service based on an

Data Provider. This can be used by other SAP and non-SAP applications using standard HTTP/OData.

With OData, SDI, SDA, ODBC, JDBC, DBSQL and standard SAP interfaces, SAP BW 7.5 on HANA is a truly

open

data platform

SAP BW

7.5 - Smart

Data

Integration (SDI) on HANA

New SDI features for BW

R

eal-time

streaming possibleReal-time direct access, ETL and replication from traditional landscapes and the cloud.Twitter, files and OData support in

SDA

BW can be a source system using SDI

HANA Source system in BW have unified connections to SDA, SDI and local HANA sources

(see note: 2175904)

What We’ll CoverIntroductions

BW 7.5 Edition for HANA Vs. BW 7.5 on HANA

New Enterprise Data Warehousing Capabilities

Hardware and Landscape Deployment OptionsThe DMO and the Logical Upgrade ApproachWrap-up

Hardware Options 2016 Onward

IBM Power 880

Key Hardware Options 2016 Onward

Note:

Power8 servers from IBM are now also approved to run HANA

Also, new Intel Broadwell processors are now emerging with 20-24 cores

Key Cloud Options

HANA

Sizing

Tool for

Existing BW Implementations

Using the BW Automated Sizing tool in the Migration Cockpit

HANA

Sizing

Tool for

Existing BW

Implementations

SAP

has 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

To increase speed, you can

suppress

analysis tables with less than 1 MB

size

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.

This program is

referenced in SAP Notes

1909597 and

1736976

on the Service Marketplace

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

Historical Landscape Deployment Planning Options

Virtualization MCOS MCOD Technical Co-Deployment

Deployment

Scenario

HANA DBs

Multiple

Multiple

One

One

DB Schema

Multiple

Multiple

Multiple

One

Availability

Supported for

DEV & QA systems

Supported for

DEV & QA systems

Defined by:

White List

1661202 for BWWhite 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 ledgerERP 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)

MCOS Example from Real Company

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

MCOS

APPLICATIONS

New Deployment Option –

Multitenant

Database

Containers (MDC) Deployments

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

MDC became available with SP-9 of HANA in 2015

SAP HANA

Tenant Database

Tenant Database

Application A

Application B

System Database

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 privilege “

Database Admin

” allows you to separate admin access to each database

You can convert a HANA system to MDC, but it cannot be converted back

(command:

hdbnsutil –convertToMultiDB

)

What We’ll CoverIntroductions

BW 7.5 Edition for HANA Vs. BW 7.5 on HANA

New Enterprise Data Warehousing Capabilities

Hardware and Landscape Deployment OptionsThe DMO and the Logical Upgrade ApproachWrap-up

Optional: The SAP_BW_HOUSEKEEPING Task ListIf 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

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

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

You first have to install the program from

SAP Note

1829728

before you can generate the SAP_BW_HOUSEKEEPING

task list

using

tcode

STC01

Optional: 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.5

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

Optional: Pre-Steps: BI Content Consistency Checks 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 checksList of InfoObjects without an InfoObject CatalogInconsistent Roles checkRoutines that refer to fixed, programmed structuresQuery Elements with Duplicate GUIDsSeveral Object Collection ErrorsSeveral Object Status checksMany 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.5.

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.x

in the

“cookbook note”

1807522

BW to HANA Readiness Check

You can run the

BW to HANA

readiness

check found in the

HANA

migration

cockpit your BW system

BW to HANA Readiness Check – Findings – p1

This is a real example of typical checklist findings at a company.

Yours may differ, but having some items flagged is common and a plan should be developed to address these

Real Example

BW to HANA Readiness Check Findings – p2

There are some steps that have to be completed before the migration can occur.

The Precheck program outlines these as:

Real Example

Other Mandatory Tasks and Gotchas with BW 7.5

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. For non-unicode compliant systems, you may have to go to BW 7.4, and do the Unicode conversion during that upgrade, before moving to BW 7.5

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.

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 InfoSetsIf 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.5 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 c

ould

run

RSDS_DATASOURCE_ACTIVATE_AL

L after the upgrade

(see

SAP Note 1494272)

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

When possible, you should consider using the single system option, thereby making the upgrade and migration much faster (may require more outage).

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.

Shadow System During the Upgrade

BW 7.0

(or higher)

Shadow System

Application Data

SPDD

Application

Data

BW

7.x

Shadow System Installation

Application Data

Target Release

SAP

NW BW 7.5

Import &

Data Conversion

XPRA

You

use

a shadow system to reduce the system

outage

Source

Release

Target

Release

Target Release

System

Source Release

System

Target Release

System

Target

Release

-

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

NOTE:

during the lock, only

certain types of BW objects for which

changes are explicitly

allowed

can be changed (see note

337950).

Step 1: Hardware Install, Dev Copy, and Sandbox Upgrade

1

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

BW

7.x

Sandbox

BW 7.5

Sandbox

BW

7.x

Dev. Box

BW

7.x

QA Box

BW

7.x

Prod Box

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.

An Example

Step 2: Development Box Copy and Upgrade

2

1

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

BW

7.x

Sandbox

BW 7.5

Sandbox

BW

7.x

Dev. Box

BW 7.5

Dev. Box

BW

7.x

QA Box

BW

7.x

Prod 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.5 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.

An Example

Step 3: Production Box Copy and QA Upgrade

3

2

1

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

BW

7.x

Sandbox

BW 7.5

Sandbox

BW

7.x

Dev. Box

BW 7.5

Dev. Box

BW

7.x

QA Box

BW 7.5

QA Box

BW

7.x

Prod 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).

An Example

Step 4: Production Box Copy and QA Upgrade

4

2

1

3

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/7.4 upgrade

BW

7.x

Sandbox

BW 7.5

Sandbox

BW

7.x

Dev. Box

BW 7.5

Dev. Box

BW

7.x

QA Box

BW 7.5

QA Box

BW

7.x

Prod Box

BW 7.5

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

An Example

Database 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

NOTE:

If you are already on BW 7.3/7.4 on HANA, you must

have at

least HANA SP-10 before migrating to 7.5 using DMO

Since

these are now required for the BW 7.5 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 database migration option tool you can accomplish both the 7.5 upgrade and often all the HANA migration in one step

. DMO

is a key option in the Software Update Manager (SUM), for those that want to migrate to HANA.

Software Update Manager – SP 16

To do a migration of your existing SAP BW system, you should first look at the Product Availability Matrix (PAM) at the SAP Marketplace.

The DMO option support for SAP BW 7.5 was recently released, but required SUM ServicePack 16 (or higher). In

SPS-16, the

brand new “Zero

downtime

option”

(ZDO) available on

request

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.

Speed is not important in the first sandbox migration. The creation of a repeatable process is far more important.

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 also support Unicode conversions to BW

7.4

DMO and Unicode (may have to goto 7.4 before 7.5)

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

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 weeksEnvironments: 4+1Risk aversion: Medium

Other usage:

Integrated Planning

This organization was using BWA 7.0 and retired it as part of the HANA migration, thereby saving licensing costs for this platform

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

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 weeksEnvironments: 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 mosEnvironments: 4Risk aversion: HIGH

Other usage:

APO

, IP,

BPC

This assumed minimal additional functional optimization

Last Hint

: De-Clustering of Tables for products based on NW 7.5

To take of advantage of the new table structures of HANA, pooled and cluster tables in legacy databases are declusters and depooled as a default in NW 7.5

You will have the option to keep the cluster and pooled tables if you want. However, for the vast majority of customers this is a step that will simplify table structures and increase speed in HANA

What We’ll CoverIntroductions

BW 7.5 Edition for HANA Vs. BW 7.5 on HANA

New Enterprise Data Warehousing Capabilities

Hardware and Landscape Deployment OptionsThe DMO and the Logical Upgrade ApproachWrap-up

Where to Find More Information

www.sap-press.com/sap-hana_3687

Bjarne Berg and Penny Silvia,

SAP HANA: An introduction (SAP PRESS, 3rd Ed.)http://scn.sap.com/docs/DOC-70034

SAP SCN SAP BW 7.5 Frequently Asked

Questions

http

://scn.sap.com/docs/DOC-68023Update to SAP BW 7.5 by Roland Kramer, SAP SEhttp://sapexperts.wispubs.com/BIThe Future of SAP BW: SAP BW 7.5, Edition for SAP HANA by Ned Falk

https

://

help.sap.com/nw75

SAP NetWeaver

7.5 Help Portal page

7 Key Points to Take Home

BW 7.5 on HANA and BW 7.5 Edition for HANA are different

BW 7.5 has major benefits in terms of object simplification and faster development times

A migration to BW 7.5 for older BW systems will normally be to BW on HANA firstUnicode conversion is mandatory for BW 7.5 systemsMigrations can be done in as little as 8-10 weeks for smaller and mid-sized systems

Staffing should be a mix of test teams; strong HANA and BW skilled basis people are essential

BW 7.5 removes many of the old ‘legacy’ objects and simplifies modeling and query development in the new Eclipse based modeling interface.

Your Turn!

How to contact me:

Dr.

Berg

Bjarne.Berg@PwC.com