Migrate SAP Systems to RISE with SAP S/4HANA Cloud

INTERNAL
Migration Scenarios
RISE with SAP S/4HANA Cloud, Private Edition
28 Feb 2023

2
INTERNAL
© 2021 SAP SE or an SAP affiliate company. All rights reserved. ǀ
The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of SAP.
Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or any other service
or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or any related
document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms directions and
functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this
presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality. This presentation is provided
without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. This presentation is for informational purposes and may not be incorporated into a contract. SAP
assumes no responsibility for errors or omissions in this presentation, except if such damages were caused by SAP’s intentional or gross
negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from
expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates,
and they should not be relied upon in making purchasing decisions.
Disclaimer

3
INTERNAL
Document Change Log
Version Section Slide # What has changed and
reason for change
Date of
update
Changed by
(first name, last name, organization)
Additional comments
1.0 All All Baseline June 4, 2021 SAP Partner PCE team Partner Architect version
1.1 All 21, 30 Bandwidth Increase during migration project & HANA Tenant Copy May 8, 2022
SAP Partner PCE team
Partner Architect version
1.2 All 31 to 35
Additional slide for BW/4HANA, partner role in HEC to HEC migration,
Estimating Export Dump Size
Aug 1, 2022
SAP Partner PCE team
Partner Architect version
1.3 All 4, 5, 15
SAP S/4HANA 1709 no longer follows LMP, IP address range to
access Migration VM
Sep 20, 2022 SAP Partner PCE team Partner Architect version
1.4 All
17, 29, 30,
33
PCE Inclusions, HANA Tenant Copy, Handling ERP PCE and
S/4HANA PCE in one contract
Nov 13, 2022 SAP Partner PCE team Partner Architect version
1.5 All 4, 6, 9, 11
Added S/4HANA 2022 in the respective slides, also a statement about
old S/4HANA releases in slide 6
Feb 28, 2023 SAP Partner PCE team Partner Architect version

4
INTERNAL
Technical Qualification Criteria – Software Release Check
Summary of technical criteria for customers who are running S/4HANA on their premises to move to S/4HANA Private Cloud Edition
(PCE).
SourceRelease
EndofMainstream
Maintenance/Extended
Maintenance*
PossibleTargetReleases
underPCE Contract
MigrationApproach
SAP ERP 6.0, EHP xx 31.12.2027 S/4HANA 2022 SYSTEMCONVERSION:SystemconversionusingSUMDMO
S/4HANA 1511 31.12.2020 S/4HANA 2022 Supportedunder LimitedMaintenancePolicyhttps://www.sap.com/about/agreements/policies/cloud-service-
specifications.html?sort=latest_desc&search=RISE+with+edition&pdf-asset=10151ebc-f07d-0010-bca6-
c68f7e60039b&page=1&source=social-atw-mailto
S/4HANA 1610 31.12.2021 S/4HANA 2022
S/4HANA 1709
31.12.2022/
31.12.2025*
S/4HANA 1709
SYSTEMCOPY(backup/restore):This approach is possibletill 2025
UPGRADE: Upgradeto latest release is desired as part of the migration
S/4HANA 1809
31.12.2023/
31.12.2025*
S/4HANA 1809 SYSTEMCOPY(backup/restore):This approach is possibletill 2025
S/4HANA 2022 UPGRADE: Upgradeto latest release is desired as part of the migration
S/4HANA 1909
31.12.2024/
31.12.2025*
S/4HANA 1909 SYSTEMCOPY(backup/restore): Desired option as this release is under maintenance until 2025
S/4HANA 2022 UPGRADE: Upgradeto latest release is optional
S/4HANA 2020 31.12.2025
S/4HANA 2021 31.12.2026
• Releases that have at least 9 months of maintenance left are only supported. For lower release, an upgrade must be executed before the migration to PCE.
Customers must upgrade to the latest version of S/4HANA well before end of mainstream maintenance.
• If a target release below 1909 is chosen, compatibility of subcomponents (such as additional SKUs deployed on top of S/4HANA) need to be manually verified.

5
INTERNAL
S/4HANA 1511, 1610 – Limited Maintenance Policy
Supported under Limited Maintenance Policy
https://www.sap.com/about/agreements/policies/cloud-service-
specifications.html?sort=latest_desc&search=limited%20maintenance
Highlights of this policy :
• Non PRD systems (on old S/4HANA releases) can be migrated to PCE
• Before the migration of PRD system, the Non PRD systems have to be upgraded to latest S/4HANA versions
• After the migration of PRD system, it has to be upgraded to latest S/4HANA version within 2 weeks
• The migration of the systems can be done by Partners and Upgrade (Technical Tasks) will be done by ECS as
per PCE R&R.

6
INTERNAL
S/4HANA 1709, 1809, 1909
Customers on S/4HANA 1709, 1809, 1909 should have Extended Maintenance for their on-premise systems.
Only then the systems can move to PCE.
If customer has not purchased Extended Maintenance for their on-premise systems but are on customer specific
maintenance then the move to PCE can only happen using Limited Maintenance Policy.

7
INTERNAL
Limited Maintenance Policy – Who does what
Scenario Migration from
On-Prem to
PCE
Go-live 1 Upgrade to latest
S/4Hana Version
Go-live 2
Where Migration
Partner is
involved
Partner can do Handover to
ECS
Only ECS can do
(as per R&R)
ECS

8
INTERNAL
RISE with SAP Transition Options
Source Version Target Version Transition Method
ERP on anyDB S/4HANA System Conversion
ERP on HANA S/4HANA
Perform system conversion on-prem to
S/4HANA followed by a system copy to
RISE infrastructure.
S/4HANA S/4HANA System Copy / Upgrade
RISE with SAP S/4HANA Cloud, Private Edition

9
INTERNAL
Source Release – ECC 6.0 on anyDB
Target – RISE with SAP S/4HANA Cloud, private edition
ECC 6.0 EhPxx
Any supported DB
Customer specific
Infrastructure
Any supported OS
S/4HANA 2022
HANA
Private Cloud
Infrastructure
Suse Linux
System Conversion
• S/4HANA Conversion (SUM DMO with System Move) can be done by authorized Partner with support from ECS Delivery
• For S/4Hana 2022 availability of a suitable addon version can’t be guaranteed in all cases
https://wiki.one.int.sap/wiki/pages/viewpage.action?pageId=3138617005
SAP S/4HANA, private cloud edition infrastructure

10
INTERNAL
Source Release – ECC 6.0 on HANA
Target – RISE with SAP S/4HANA Cloud, Private Edition
There is no direct transition method from ECC 6.0 on HANA to S/4HANA. There could be different options to handle such customers
Option 1: [Recommended]
Step 1 – S/4HANA conversion at on-premise [Customer will have to consider any OS upgrade/Hana 2.0 upgrade etc]
Step 2 – Copy S/4HANA from on-prem to Private Cloud
Both the steps can be done by partner in one downtime.
Option 2: [Not Recommended]
Step 1 – Copy ECC on Hana from On-prem to Private Cloud
Step 2 – S/4HANA conversion
Both the steps can be done together by partner in one downtime. Drawback is it will require very long downtime (of days) and hence this might
not meet any customer’s requirement.

11
INTERNAL
Source Release – S/4HANA
Target – RISE with SAP S/4HANA Cloud, private edition
S/4HANA
(1709 to 2022)
HANA
Customer specific
Infrastructure
Any supported OS
Linux x86/Power
S/4HANA
(1709 to 2022)
HANA
Private Cloud
Infrastructure
Suse Linux
System Copy
SAP S/4HANA, private cloud edition infrastructure
• System Copy can be done by authorized Partner

12
INTERNAL
Private Cloud Edition Migration Process
Migration Server method will be used primarily for Hana based systems*. The migration server method has
to be used for System Conversion and System Copy scenarios. This process can be used by a partner to
deliver end to end migration.
Azure/ AWS / GCP / SAP DC deployments
The migration server process (VM concept) will be used
*Migration Server Method cannot be used for certain DB types and certain solutions and for those Migration
Assisted Service has to be used (see next slide).

13
INTERNAL
Migration Assisted Service
Migration Assisted Service will be required for
• ASE Migrations
• Java System Migrations
• BO System Migrations
• Content Server System Migrations
For ASE Migrations the SWPM tool cannot be executed from the Migration VM.
ASE DB import can be achieved by launching SWPM from DB server itself.
Partner has to take support of Migration Assisted Service for copying the software/dump to the DB
server and launching the tool from the DB Server.
For Java stack migrations as well partner cannot execute the tool from Migration VM and hence
Migration Assisted Service will be used.

14
INTERNAL
Costs included in Base Costs
Method MigrationVM Object Store
BlockStorage
(Storage on HanaDB)
* Storage on Migration
Server forExport Dump
(applicable for migration or S/4
Conversion)
Migration Server
(Azure/AWS/GCP/SAP DC) Included Included
Not Included
(Needs to be priced using
Additional Storage SKU)
Not Included
(Needs to be priced using
Additional Storage SKU)
For both Block storage (storage on the DB server) and storage on the Migration Server, CAA will price the
storage using SKU SAP Additional Storage, private cloud edition – 8008794 (This is only for Migration Scenario)
The storage on the DB server can be moved from DEV to QAS to PRD for sequential migration scenario so you
can price as per the largest DB size.
* Storage mounted on Migration Server cannot be moved to other servers

15
INTERNAL
Handling Additional Storage in PQA
The additional storage which is part of PQA/DED should be maintained with usage details as well.
If the storage is for Migration purpose then please maintain under usage details as “/migration” so that block
device would be provided as /migration mount point.

16
INTERNAL
Migration Server Method – some Inputs
1. Customer IP range / subnet to access Migration VM
During the Sales to Delivery Handover session, ECS Project Lead or the Build Team might ask the PCA for the
customers IP range/subnet which is required to be whitelisted with port 22 to access the Migration VM. PCA is
not required to ask customer separately about the IP range/subnet required to be whitelisted for Migration VM.
Instead, SAP ECS colleague can retrieve the required IP range from the Network Connectivity Questionnaire
(refer to the “Customer On-Premises Network IP Ranges” field).
2. Additional requirements for AWS
Additional network segment needs to be created for deploying IAAS VM (Migration server) on AWS
TDD team must create an entry in PQA with the required Network segment
Customer IP : X.X.X.X/22
New network entry: X.X.X.128/28
First 3 Octets in IP address must be taken from customer range and fourth octet is slandered 128/28
This new network can deploy 14 IP addresses out of which delivery will use 2 IP addresses for each IAAS VM.
Maximum of 5 IAAS VMs can be created in this Network segment (with 14 IPs).

17
INTERNAL
Migration Server Method – Additional Requirements for SAP DC
Additional /27 network segment needs to be created for deploying IAAS VM (Migration server).
It needs to be described in PQA for usage of Migration VM
Additional storage needs to be added to IAAS server with volume “/migration” of 200 GB minimum size. The
PCE base cost already considered 100 GB of storage so CAA needs to price additional 100 GB to meet the
minimum size. If the export dump size is larger than 200 GB then the delta needs to be priced as well.

18
INTERNAL
PCE Inclusions
Costs included in base offering:
• Object Store type storage is included in base costs as below:
• HANA size 256 GB or 512 GB – 1 TB Object Store storage
• HANA size >512 GB and <2 TB – 2 TB Object Store storage
• HANA size 2TB and up – 3 TB Object Store storage
The 1-3 TB size is a commercial consideration and there will be no restriction to customers if they want to copy a backup
of larger size.
• Migration VM cost for 6 months (Virtual-128GiB-D32s_v3 + 100GB storage).
• The VM will be available to the customer for the duration of the migration project (even if the project is more than 6
months).
• VM will be deployed as Linux server.
• One migration VM per deal has been included in base costs. [In cases where customers need more than 1 VM for
their migration project then the same would be provided without any charge. There will be no need to execute Upsell
transaction for the same. ECS will define a process to handle such requests without any CAA involvement]
• Migration VM will be deployed if all three conditions are true
• RISE deal [applicable for S/4HANA SKU, Standalone SKUs, Upsell SKUs (such as Solman etc) and ERP PCE SKU]
• Brownfield Scenario
• Partner Led Migration

19
INTERNAL
Storage Guidelines
Approach 1 : Migration/Conversion
A system is migrated using export/import or using SUM DMO with system move. In both cases the source database is exported using SAP
tools and imported into HANA in the S/4HANA cloud.
For this approach the following additional storage needs to be contracted with the customer:
1. Storage needed for the export dump on the Migration Server. This needs to be analyzed and calculated depending on the source
systems database size. As the Migration Server will be reused for every system (DEV, QAS, PRD...) it should be calculated for the
biggest source database. This link provides some estimation on how to calculate the export dump.
2. Storage needed on the HANA DB server for backups (also known as Block Storage). There should be additional storage twice the
HANA size calculated. This storage will allow the Migration Team to trigger local backups (at least two, therefore twice the HANA size)
at milestones during the migration/conversion
Approach 2 : System Copy
A system that is already on a supported S/4HANA release or running on the HANA database and export/import is not possible anymore. In
this case backup/restore is the method to be used.
For this approach the following additional storage needs to be contracted with the customer:
1. Storage needed on the HANA DB server for the backup transferred (also known as Block Storage). There should be additional
storage one time the HANA size calculated. To this storage the transferred backup will be moved so SWPM can trigger the restore.

20
INTERNAL
Object Store Requirement
S/4HANA Conversion Scenario :
In case a fast and reliable connection such as Azure ExpressRoute is used then the export data can be
directly copied to the Migration Server. However Object Store such as Azure Blob Storage is still required.
The object store will be used by partner to upload the log and trace files of SUM/SWPM to be used by ECS
Delivery team.
In case VPN connection is used then also the export data can be directly copied to the Migration Server.
However the speed could be slow. To overcome any challenges with VPN connection the export data can
be copied to Object Store first and from there it will be copied to Migration Server.
S/4HANA Copy Scenario :
In case of backup/restore scenario it is mandatory that the backup is copied to Object Store first and from
there the ECS Delivery team will copy it to the Hana server. This is because partner don’t have access to
the Hana server.

21
INTERNAL
Bandwidth Increase during migration project
• Supporting Customers with temporary higher bandwidth requirements to handle migration workload is
supported for RISE deals by the ECS operations team at no additional costs to customer.
• This can be requested for the entire duration of migration project
• Bandwidth increase would need to be performed at an agreed time frame and roughly take a hour and would
need to be requested by the customer via raising a service request
• While SAP takes care of Hyperscaler gateway port and bandwidth speed, customer would also need to work
with their ISP connectivity providers to increase the bandwidth
• Once the migration is completed the connectivity will need to be reverted back to the original state.
• Example for Azure (same is applicable for all Hyperscalers) : Bandwidth upgrade of ExpressRoute is
seamless, to revert back, the SAP network team would need to delete existing ER circuit, connections
(whole configuration related to ER), and create a new one. This is the same as new ER setup, where ECS,
Customer, and their provider need to be are involved. This part is downtime-based and coordination of all
parties is required to minimize downtime.

22
INTERNAL
RISE with SAP Transition Options - Storage Requirements
Source Version Target Version Transition Method Storage Requirement (Not included in Base cost)
1. ERP on anyDB S/4HANA
System Conversion (DMO w System
MOVE)
1. Storage for Export dump on Migration server
2. Storage for taking Backup on database server (at least twice of
HANA DB size)
2. ERP on HANA S/4HANA
System Copy (backup / restore) – step 1
System Conversion (SUM) – step 2
Step 1
1. Storage for copying source database Backup on ERP on HANA
DB server (same size as HANA DB)
Step 2
1. Storage for executing Backup on database server (at least twice of
HANA DB size)
3. S/4HANA
(1809 & above)
S/4HANA
System Copy (backup / restore) – step 1
S/4HANA upgrade (optional) – step 2
Step 1
1. Storage for storing source database Backup on S/4HANA DB
server (same size as HANA DB)
RISE with SAP S/4HANA Cloud, private edition

23
INTERNAL
ECS Post Processing Scope
Standard PCE scope includes the following:
• Refer R&R Task Basic_1.8.03 : If the initial set-up is a migration, One (1) additional test run of the production (PRD) system
is included. If the initial set-up is a conversion to S/4HANA, Two (2) additional test runs are included: One (1) for a non-
production (QAS, DEV, etc.) system and One (1) for the productive (PRD) system). Additional test runs are available as a
billable service
• In case the dryrun is executed using the PRD hardware then there is no need to rebuild the target system. For the final run
Partner can drop the database in the target system and continue the migration.
• Customer can perform any number of dryruns using the Migration VM process however ECS specific post migration/build
activities will not be included for more than what is mentioned in the R&R
* For SBX run customer can use the QA or PRD tier. The above conditions apply for the SBX run as well.
* ECS Post Processing Tasks are done once Partner completes the Migration and Post System Copy Tasks. ECS Post
Processing tasks are related to internal ECS setup.
For DMO with System Move scenario take note of the following:
• The SID of the app server in that target environment has to be same as SID of the app server in the source landscape.
• The SID of the app server in PCE cannot be changed without additional rebuild costs.
• Hence for SBX or Dryrun, customer should set the SID of the app server in the source landscape same as that of the target
system in PCE.

24
INTERNAL
ECS Post Processing Scope
ECS Post Processing Duration:
Post processing duration is as below –
• For Non-prod : 4 Working days
• For Prod : 14 hr (12 Hr Post processing + 2 hr Validation checks by ECS)

25
INTERNAL
Backups during Migration
Local Backups during migration of the system will be taken by the migration team (SI or SAP Services
depending on who is doing the migration)
ECS delivers the system after disabling the backup to migration team.
ECS do not want touch the system where migration is going on to just avoid any issues.
Hence its not possible for ECS to take a backup till the migration team sends system to ECS for post migration
activities.

26
INTERNAL
DMO with System Move problem – 1/2
Problem Statement :
• Brownfield Customers need the App Server SID in PCE to be same as that of the App Server SID at on-
prem when they:
• use DMO with system move and
• use QAS/PRD system hardware in PCE for the Sandbox migration or
use PRD system hardware in PCE for the Dryrun migration.
• Once the systems are built and handed over to customer any change of SID is not possible and ECS
needs to rebuild the App Server with additional cost.
* This problem will not occur for DEV, QAS and PRD system migrations. This problem will only occur when
there is no dedicated system in PCE for the Sandbox or the Dryrun migration.
Solution 1 :
One possible solution could be that when customer builds the Sandbox system or the Dryrun system at on-
prem they use the SID same as that of the target system in PCE.
Lets say customer wants to use QAS system in PCE for the Sandbox run then they should try to create the
Sandbox system at on-prem with the SID same as QAS system in PCE.
In case customer wants to use PRD system in PCE for the Dryrun then they should try to create the Dryrun
system at on-prem with the SID same as PRD system in PCE.

27
INTERNAL
DMO with System Move problem – 2/2
Solution 2:
• For migration being done by partners, they can use the Migration VM to install the App Server temporarily
with the SID same as that of on-prem. If additional Migration VMs are required then the same can be
provided under PCE.
• For migration being done by SAP Services, they can use Managed IaaS Server to install the App Server
with the SID same as that of on-prem. Managed IaaS Server (same configuration as Migration VM) can be
provided in PCE without any additional cost.
Note: There will be no change allowed in the target
Database.
The Tenant SID will not be changed. Migration team
will use the same SID in SUM DMO tool as the target
SID in PCE

28
INTERNAL
SID Issue – System Copy
There are three <SID>s that we need to consider.
1. SAP Application System <SID>
2. HANA System DB <SID>
3. HANA Tenant DB <SID>
Guideline from ECS with respect to the above SIDs in PCE :-
• SAP Application System <SID> and HANA Tenant DB <SID> should be same.
• HANA System DB <SID> should be different to HANA Tenant DB <SID> and thereby the SAP Application
System <SID>.
In case Customer has different SAP Application SID and HANA Tenant DB SID at source then Customer will
have to rename the Tenant DB SID to the same SID as the SAP Application SID using SWPM or HANA
Studio. This can be done in the target system as part of the System Copy process.
Detailed procedure is in the next slide.

29
INTERNAL
●S/4HANA PAS
●SAPSID=PR1
System
DB
Tenant DB =
HR1
●Pre-installed skeleton PAS
●SAPSID=PR1
System
DB
Pre-installed
skeleton
Tenant DB =
PR1
●Migration Server PAS
●SAPSID=PR1
HANA
Tenant HR1
Backup file
(2) Backup tenant DB HR1.
Additional Storage
HANA
Tenant HR1
Backup file
(3) Transfer to HANA Server.
(4) Restore tenant DB as PR1
using SWPM or HANA Studio.
(Do not restore as HR1.)
(1) ECS delivers the skeleton system
with the same SID for SAP SID & Tenant.
(5) Switch Migration
Server to official PAS.
PCE
Customer-side on-premise
In case Customer has different SAPSID and HANA Tenant Name at source then Customer will have to rename the
Tenant name to the same SID as the SAPSID using SWPM or HANA Studio.
(4) Run System Copy Target
system installation using SWPM.
HANA Server
HANA SID = HR0
HANA Server
HANA SID = HP4
Eg:
Source and Target SAPSID: PR1
Source HANA Tenant Name: HR1
Target HANA Tenant Name: PR1

30
INTERNAL
HANA Tenant Copy – (1/2)
HANA Tenant Copy method is supported for PCE
While this can be used by partners, the Partner cloud Architect need to consider the storage requirements for
this scenario.
To calculate the storage the below formula needs to be considered:
[initial “copy” of the database]
Used Size of source DB + ((amount of daily log creation in source) * (number of estimated days the copy runs)
* 1.x)
[where x is the percentage of buffer we want to see]
For pricing the storage for this scenario the DB storage SKU has to be used -
8011367 - SAP Additional Database Storage, private cloud edition

31
INTERNAL
HANA Tenant Copy – (2/2)
Alternatively the storage requirement can be requested only after doing a mock run on production system.
Only if the migration execution team sees that the log space full during mock run, they have to request the storage
based on the defined formula. This may mean that CR for storage may be required for the mock run.
Recommendation:
• Storage requirement for the tenant copy should be estimated by the migration partner by doing a mock on the copy
of production system.
• Tenant copy initialization should be executed after business hours.
• Based on the results of the mock, Migration partner/customer can decide to whether to request the storage or not

32
INTERNAL
BW/4Hana
As per the Conversion Guide, “remote conversion” scenario will require both source (on-premise BW) and target
(BW/4 PCE) to have this DMIS add-on installed. There is no additional license or SKU required for DMIS add-on for
the BW/4HANA System Conversion.
BW/4Hana FAQ ->
https://dam.sap.com/mac/app/asset/preview/6d66bd8e78072b895e7f86defb0a808c057b167b

33
INTERNAL
Migration Scenario – SAP DC to Hyperscale DC
In cases where we position RISE to existing HEC customers and there is a migration required to be done from
SAP DC to Hyperscale DC or from one Hyperscale DC to another Hyperscale DC the migration cannot be done
by partners as they will not have access to the source landscape.
The migration in these scenarios can be done by
1. SAP Services (aka DBS)
2. ECS

34
INTERNAL
Handling ERP PCE and S/4HANA PCE in one contract
If we have ERP PCE and S/4HANA PCE SKUs in one quote then we need to consider the following points:
1. The initial migration of ERP on anyDB to ERP on Hana (on-prem to PCE) can be done by partner.
2. The S/4HANA conversion at a later point in time can be done by
a) SAP Services
b) ECS (using Additional Services)
3. The S/4HANA conversion will be done using “in place” conversion method.
4. In case customer wants parallel or additional landscape for the conversion then the same will have to be handled via
upsell.
5. Licensing Overlap
a) During the period of the conversion customer has to have S/4HANA licenses (minimum quantity) to run the Non
PRD S/4HANA systems.
b) The minimum license also entitles the customer to an infrastructure but that infrastructure is of no use in case
• Customer is doing in place conversion (default option)
(or)
• The source ERP system size is larger than XS. In this case if customer wants to use the minimum license
infrastructure (XS tier) as a parallel landscape for the migration then additional memory extension will be
needed for the S/4 parallel landscape.

35
INTERNAL
R3load (DMO with System Move /SWPM) based migration dump is
higher than expected, what could be the reason ?
• Source DB size compression (Full DB, set of tables, index only,
etc.)
• Large Cluster tables (CDCLS, RFBLG, EDI40, KOCLU etc.) If the
cluster tables are large in your database, then it will impact the
overall estimated compression factor
• Source DB statistics not up to date
• Large LOBs and Hybrid LOBS - Large Object is a data type used
to store large record (e.g. tables SOFFCONT1, DBTABLOG)
Migration Dump is Higher Than Estimation

36
INTERNAL
1. Source: Suite on HANA Sizing Report
How to estimate migration dump size ?
• Migration Dump Estimation = 25% of Column store data + Hybrid LOBs
Migration Dump Estimation = 535.75 + 2056 = 2591.75 GB
• SoH HANA DB Backup Size = 4384.2 GB
2. Source: S/4HANA Sizing Report
• Migration Dump Estimation = 25% of Column store data + Hybrid LOBs
Migration Dump Estimation = 1767.25 + 1084 = 2851.25 GB
• S/4HANA HANA DB Backup Size = 8993 GB

38
INTERNAL
Migration Assisted Service
ECS will provide resources to execute the tasks which need OS/DB access
GSSP will
• use SAP standard tools for the migration (SWPM, SUM/DMO)
• will have complete accountability and responsibility for the migration.
• will be responsible for following up and fixing the issues related to migration
• will be responsible for raising the support Service and raising request for change of OS and DB parameter if needed.
• will be responsible for any follow-up with the SAP product team or outside SAP
• will be responsible for completing the custom code checks and necessary adjustments
•Migration Execution
on the source system
•Migration Execution
on the target system
except for those tasks
which need privilege
access.
GSSP
•PL will coordinate the
communication
between GSSP and
ECS delivery.
ECS (CDE)
•Execute the migration
tool in the target
system and handover
to GSSP.
•Execute commands
which need privilege
access on behalf of
GSSP
ECS (L2
Basis)

39
INTERNAL
Migration Assisted Service - Scope
High Level Scope: GSSP
• will execute the migration tasks on the source system
• will contact the ECS (Client Delivery Management) for starting
the activities on the target system.
• will access SUM/DMO tool in the target system.
• will use Monitoring User in the target system to monitor the
SUM/DMO tool progress.
• will have OS read only access in the target system using
chrooted jail
High Level Scope: ECS
ECS Customer Delivery Engagement & ECS Delivery:
• PL will be coordinating the migration with GSSP and ECS Delivery (L2 Basis Migration Support)
ECS L2 Basis Migration Support:
• Run the SAP migration tool using at target system in the HEC as directed by the GSSP team
• Share the logs with GSSP team on demand other than SUM tool logs
• Run any command provided by GSSP team on the OS level and share the output with GSSP
team
• Handover the system to GSSP team for post migration activities
• Coordinate with ECS support teams for the server and DB related issue for HEC system during
migration
• Availability will be 24x7
Out of Scope: ECS will not be responsible for the following activities:
➢ Any troubleshooting of any issues during migration, related to application, migration tool etc.
➢ Joining the Bridge call and providing the update to customer.
➢ Any follow-up with team in the SAP or outside SAP.

© 2021 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of
SAP SE or an SAP affiliate company.
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its
distributors contain proprietary software components of other software vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or
warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials.
The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty
statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or
any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation,
and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platforms, directions, and
functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason
without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or
functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ
materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they
should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names
mentioned are the trademarks of their respective companies.
See www.sap.com/copyright for additional trademark information and notices.
www.sap.com/contactsap
Follow us

Migrate SAP Systems to RISE with SAP S/4HANA Cloud

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Migrate SAP Systems to RISE with SAP S/4HANA Cloud

Semelhante a Migrate SAP Systems to RISE with SAP S/4HANA Cloud (20)

Último

Último (20)

Migrate SAP Systems to RISE with SAP S/4HANA Cloud