PCE Migration Guidelines for PCA Team

This is the main page for the PCAA team to understand the possible migration scenarios that we
have in RISE with SAP S/4HANA Cloud Private Edition.

This document is released as a general guidance document for SAP and It’s Authorized partner
only. This document is not intended to be used by other teams. This document does not cover the
migration procedure for Partners. And Applicable only to RISE

1. Technical Qualification Criteria - Software

Release Check
Below you can find the summary of technical criteria for customers who are running S/4HANA
on their premises to move to S/4HANA Private Cloud Edition (PCE).

Possible
Target
End of End of
Source Releases
Mainstream Extended Migration Approach
Release under
Maintenance Maintenance
PCE
Contract
SAP ERP
6.0, EHP S/4HANA
31.12.2025 n/a SYSTEM CONVERSION: System conversion using SUM DMO
0 to EHP 2022
5
SAP ERP
S/4HANA
6.0, EHP 31.12.2027 n/a SYSTEM CONVERSION: System conversion using SUM DMO
2022
6 onwards
S/4HANA
S/4HANA
Finance 31.12.2025 n/a SYSTEM CONVERSION: System conversion using SUM DMO
2022
1605
S/4HANA S/4HANA
31.12.2020 n/a Supported under Limited Maintenance Policy
1511 2022
https://www.sap.com/about/agreements/policies/cloud-service-
S/4HANA S/4HANA specifications.html?sort=latest_desc&search=limited%20maintenance
31.12.2021 n/a
1610 2022
S/4HANA SYSTEM COPY (backup/restore): This approach is possible till
S/4HANA 1709 2025
31.12.2022 31.12.2025
1709 S/4HANA UPGRADE: Upgrade to latest release is recommended as part of the
2022 migration or at a later stage

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 S/4HANA SYSTEM COPY (backup/restore): This approach is possible till
S/4HANA 1809 2025
31.12.2023 31.12.2025
1809 S/4HANA UPGRADE: Upgrade to latest release is recommended as part of the
2022 migration or at a later stage
S/4HANA SYSTEM COPY (backup/restore): This approach is possible till
S/4HANA 1909 2025
31.12.2024 31.12.2025
1909 S/4HANA UPGRADE: Upgrade to latest release is recommended as part of the
2022 migration or at a later stage
S/4HANA SYSTEM COPY (backup/restore): This approach is possible till
S/4HANA 2020 2025
31.12.2025 n/a
2020 S/4HANA UPGRADE: Upgrade to latest release is recommended as part of the
2022 migration or at a later stage
S/4HANA SYSTEM COPY (backup/restore) : Desired option as this release is
S/4HANA 2021 under mainstream maintenance until 2026
31.12.2026 n/a
2021 S/4HANA
UPGRADE: Upgrade to latest release is optional
2022

• Releases that have at least 9 months of maintenance (mainstream or extended as

applicable) 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 or extended 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.

2. RISE with SAP Transition Options

There are different transition methods for the different source and target version in RISE.

When the target version in RISE is S/4HANA, the possible transition options are the following:

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

Source Version Target Version Transition Method
ERP on anyDB S/4HANA System Conversion
ERP on HANA S/4HANA System Copy plus System Conversion
S/4HANA S/4HANA System Copy / Upgrade

When the target version in RISE is ERP on HANA, then the possible transition options are the
following:

Source Version Target Version Transition Method

ERP on anyDB ERP on HANA Migration
ERP on HANA ERP on HANA System Copy

2.1. From ECC 6.0 on anyDB or HANA To SAP S/4HANA

Cloud in RISE

• S/4HANA Conversion (SUM DMO with System Move) can be done by authorized
Partner with support from ECS Delivery
• ECC on HANA to S/4HANA Conversion and migration to PCE now supported as 1 step
using DMO with System Move SP17
• For S/4HANA 2022 availability of a suitable addon version can’t be guaranteed in all
cases.

2.2. From SAP S/4HANA to SAP S/4HANA Cloud in RISE

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • System Copy can be done by authorized Partner
• It is also now possible to combine upgrade and migration to PCE in one step using DMO
with System Move option SP17
• For S/4HANA 2022 availability of a suitable addon version can’t be guaranteed in all
cases

2.3. From ECC 6.0 on anyDB to SAP ERP, private cloud

edition in RISE

• SoH Migration can be done by authorized Partner

• It is highly recommended to have ECC 6.0 EhP8 as the target release in PCE
• Only Unicode version is supported in PCE

3. Limited Maintenance Policy (LMP)

Customer with S/4HANA release versions 1511 and 1610 are supported under Limited
Maintenance Policy. You can check the information The RISE LMP Guideline at

https://www.sap.com/about/agreements/policies/cloud-service-
specifications.html?sort=latest_desc&search=limited%20maintenance

Highlights of this policy :

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

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

Note: Existing HEC/STE/EX customers with releases which are already out of maintenance
such as S/4HANA 1610, will have to upgrade to latest S/4HANA version before they can be
converted to RISE contract. They can use EMS hours for the upgrade as per the HEC R&R.

3.1. LMP - Who does what

Below we can find a summary table about the options that can be done in LMP

Migration from On- Upgrade to latest Go-

Scenario Go-live 1
Prem to PCE S/4Hana Version live 2
Where Migration Handover to Only ECS can do (as
Partner can do ECS
Partner is involved ECS per R&R)
Where SAP Services is Handover to Only ECS can do (as
SAP Services can do ECS
involved ECS per R&R) *

*Only in complex cases like SLO project etc, SAP Services can do the upgrade.

4. Support of specific S/4HANA versions

• S/4Hana 1709

Customers on S/4HANA 1709 with customer specific maintenance for a very limited
period can migrate to PCE.

Note: Solution Management has not defined the term "very limited period" and hence
there is no limit currently. In future this may change.

• Simple Finance 1503

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

5. Private Cloud Edition Migration Process
5.1. Migration Sever Method
In order to perform the migration process to RISE, the 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.

The migration server process has been tested by ECS for ECC to S/4HANA conversion scenario
only.

For Azure/ AWS / GCP / SAP DC deployments, the migration server process (VM concept)
will be also used.

*Migration Server Method cannot be used for certain DB types and certain solutions and for
those Migration Assisted Service has to be used.

5.1.1. Costs Included in Base Costs

Block Storage Storage on Migration Server

Migration Object for Export Dump (applicable
Method
VM Store (Storage on Hana for migration or S/4
DB) Conversion)

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 Not Included
Migration Server
Not Included (Needs to be priced
Included Included (Needs to be priced
using Additional Storage SKU)
(Azure/AWS/GCP) using Additional
Storage SKU)
Not Included
Not Included
Migration Server
Included N/A (Needs to be priced
(Needs to be priced using
(SAP DC) using Additional
Additional Storage SKU)
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

Costs included in base offering:

• Object Store type storage is included in base costs as below:

o HANA size 256 GB or 512 GB – 1 TB Object Store storage
o HANA size >512 GB and <2 TB – 2 TB Object Store storage
o 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. Note: All migration data stored in Object Store will be
deleted after 45 days.

• Migration VM cost for 6 months (Virtual-128GiB-D32s_v3 + 100GB storage).

o The VM will be available to the customer for the duration of the migration project
(even if the project is more than 6 months).
o VM will be deployed as Linux server.
o Two migration VMs per deal has been included in base costs. [In cases where
customers need more than 2 VM for their migration project then the same
need to be requested as exception request from David Yawalkar]
• Migration VM will be deployed if all three conditions are true
o RISE deal [applicable for S/4HANA SKU, Standalone SKUs, Upsell SKUs
(such as Solman etc), ERP PCE SKU and Customer Evaluation System SKU]
o Brownfield Scenario
o Partner Led Migration

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

5.1.2. Migration Server Method - Additional Requirements for AWS

During the migration to AWS, additional network segment needs to be created for deploying
IAAS VM (Migration server)

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

5.1.3. Migration Server Method - Additional Requirements for SAP DC

Additional /27 network segment needs to be created for deploying IAAS VM (Migration server)
on SAP DC.

It needs to be described in PQA for usage of Migration VM

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

Additional storage needs to be added as below:

• 80 GB for /usr/sap/<SID>
• 20 GB for /sapmnt
• 100 GB for /migration*

*The PCE base cost already considered 100 GB of storage so CAA must price required
migration storage according to customer needs, with a minimum of 100GB.

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

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

6. Additional Storage During Migration
During the migration project if it is found that the initial storage calculated by CAA for the PCE
contract is not sufficient and there is a need for more additional storage 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. The storage
provided will be for the duration of the migration project only.

However note the following:

1. The storage calculation has to be accurate to the extent possible. In cases where the
migration partner has not been identified or the migration plan has not been finalized we
need to clearly call out that these quantities are estimates and subject to change based on
the migration plan. Any change needs to be handled via change requests
2. In case we have the correct estimates from migration partner then we can apply the
justified additional requirement without any CR.
3. The upper limit for the additional storage is currently under Management Review. Any
additional storage allocation is not unlimited and subject to Fair Use Policy.

6.1. 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:

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 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.

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

Note (for both scenarios): As per update, for Azure the Blob Storage is already connected via
NFS to the RISE backend servers like S/4HANA, Migration server etc, so there is no need for
ECS to manually transfer any content from the Blob Storage to the S/4HANA DB server

6.3. Object Store - Lifecycle Policy

ECS will set the lifecycle policy for the object store accounts to “Cool” after 30 days, “Archive”
after 60 days and “Delete” after 180 days of the last “access” to stop unnecessary costs. The
standard retention of other storage accounts is not affected, and in case more time is needed for
dry runs as an example, the data can just be accessed, the lifecycle setting can be changed to a
higher number of days, or in case it is needed permanently another storage account can be used.

This means by default all files on the migration object storage will be deleted after 180 days
without any access.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

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

6.5. RISE with SAP Transition Options - Storage

Requirements
RISE with SAP S/4HANA Cloud, private edition:

Source Target Storage Requirement (Not

Transition Method
Version Version included in Base cost)
1.Storage for Export dump on
Migration server
System Conversion
1. ERP on
S/4HANA (DMO w System
anyDB 2.Storage for taking Backup on
MOVE)
database server (at least twice of
HANA DB size)
Step 1

1.Storage for copying source

System Copy
database Backup on ERP on HANA
(backup / restore) –
DB server (same size as HANA DB)
2. ERP on step 1
S/4HANA
HANA
Step 2
System Conversion
(SUM) – step 2
1.Storage for executing Backup on
database server (at least twice of
HANA DB size)
System Copy
3. Step 1
(backup / restore) –
S/4HANA
step 1
S/4HANA 1.Storage for storing source database
(1709 & Backup on S/4HANA DB server
S/4HANA upgrade
above) (same size as HANA DB)
(optional) – step 2

SAP ERP, private cloud edition:

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 Source Target
Transition Method Storage Requirement
Version Version
1.Storage for Export dump on Migration
server
ERP on ERP on Migration (DMO
anyDB HANA with system MOVE) 2.Storage for executing Backup on database
server (at least two, therefore twice the HANA
size)
1.Storage for copying source database Backup
ERP on ERP on System Copy
on ERP on HANA DB server (same size as
HANA HANA (Backup / restore)
HANA DB)

6.6. Summary of Storage Requirement

Hyperscalers(AWS, Azure, GCP):

Object Store Migration Server Hana DB Server

Migration
Method
(included in Base Cost) (to be priced) (to be priced)
1TB included (256GB -
512GB) HANA

2TB included (>512GB - /migration = 1x HANA

System Copy -
<2TB) HANA backup

3TB included (> 2TB)

HANA
1TB included (256GB -
512GB) HANA

System 2TB included (>512GB - /migration = 1x DB

2x HANA Backup
Conversion <2TB) HANA Export*

3TB included (> 2TB)

HANA

SAP DC:

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 Object Store
Migration Server Hana DB Server
Migration
Method (included in
(to be priced) (to be priced)
Base Cost)
SFTP or RSYNC to
System Copy N/A - /migration = 1x HANA
backup
System SFTP or RSYNC to
N/A 2x HANA Backup
Conversion /migration = 1x DB Export*

7. Bandwidth Increase during migration

project (applicable for Hyperscalers only)
• 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.

8. ECS Post Processing

8.1. 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,

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 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.

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

8.3. ECS Support during Mock Runs

During Sandbox / Mock Cycles, System Status will not be set to Live in ECS tools, hence
Customer and Partner should be aware of below limitations -

• SAP Alerts / Monitoring will not be active. It will be reactive support from SAP ECS
side based upon the request received from Partner/Customer on the Technical-Infra
topics.
• No System Availability SLA’s will be followed for SAP systems which are not in LIVE
state.
• Customer / Partner would be responsible for the backup/ restore of the systems
• Customer would get limited support, such as availability of Infra, storage and standard
Assisted service requests of build which are listed in launch pad.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • ECS support teams would have zero visibility what Migration /customer team are
performing activities on the systems until they are set to live. So, Partner need to manage
all the required support till the customer gives sign off to set systems to Live status in
ECS.
• ADS Setup / config can only be performed once System is Live. ECS can only perform
ADS once per SID.
• Any other SAP RISE offering which is part of the deal can only be implemented on the
systems which are set to LIVE in ECS and can be implemented only once per SID.

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

9. SID Issues
9.1. DMO with System Move
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:
o use DMO with system move and
o 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.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

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.

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

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

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

10. Tenant Copy

ECS now supports HANA Tenant Copy method.

While this can be used by partners we 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]

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 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

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

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

Based on the confirmation from Solution Owner ( Karsten Ruf ) 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

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

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 1. SAP Services
2. 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
1. During the period of the conversion customer has to have S/4HANA licenses
(minimum quantity) to run the Non PRD S/4HANA systems.
2. The minimum license also entitles the customer to an infrastructure but that
infrastructure is of no use in case
1. Customer is doing in place conversion (default option) OR
2. 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.

License Overlap Example:

• In this example during the period of the conversion customer pays for ERP full license
and S/4HANA minimum license
• The S/4HANA minimum license allows the customer to access the non Prod systems
which will be converted from ECC on Hana to S/4Hana

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • From the day of S/4HANA go-live customer needs to have the full S/4HANA license
• For the temporary license customer can also use Swap rights thereby reducing the license
on ERP side and increasing on S/4 side during the conversion project.

Example of License Swap 1:

In this example customer has 571 FUE in ERP and wants to swap 60 FUE to S/4HANA

Reducing 60 FUE will bring down the ERP system to a lower tier so it has to be balanced with
additional system extension

Sys Sys
ERP Tier Month S/4 Tier
Ext Ext
…
571 10 XL M20
571 10 XL M21
S/4+
511 11 XL M22 Minimum 60 0 -
SKU
S/4+
511 11 XL M23 Minimum 60 0 -
SKU
S/4+
511 11 XL M24 Minimum 60 0 -
S/4 SKU
conversion S/4+
511 11 XL M25 Minimum 60 0 -
SKU
S/4+
511 11 XL M26 Minimum 60 0 -
SKU
S/4+
511 11 XL M27 Minimum 60 0 -
SKU
S/4 Full
M28 571 10 XL
BOM
S/4 Full
M29 571 10 XL
BOM

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 S/4 Full
M30 571 10 XL
BOM
….

This option may not be commercially viable as 1 system extension price could be costlier than 60
FUE

Example of License Swap 2:

In this example customer has 551 FUE in ERP but are using all the FUEs

So for S/4HANA temporary license additional FUE need to be purchased

ERP Sys Ext Tier Month S/4 Sys Ext Tier

…
551 10 XL M20
551 10 XL M21
551 10 XL M22 S/4+ Minimum SKU 60 0 -
551 10 XL M23 S/4+ Minimum SKU 60 0 -
551 10 XL M24 S/4+ Minimum SKU 60 0 -
S/4 conversion
551 10 XL M25 S/4+ Minimum SKU 60 0 -
551 10 XL M26 S/4+ Minimum SKU 60 0 -
551 10 XL M27 S/4+ Minimum SKU 60 0 -
M28 S/4 Full BOM 611 10 XL
M29 S/4 Full BOM 611 10 XL
M30 S/4 Full BOM 611 10 XL
….

Example of License Swap 3:

In this example customer has 600 FUE in ERP but have shelfware so the shelfware can be
swapped for the S/4HANA temporary license

ERP Sys Ext Tier Month S/4 Sys Ext Tier

…

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 620 10 XL M20
620 10 XL M21
560 10 XL M22 S/4+ Minimum SKU 60 0 -
560 10 XL M23 S/4+ Minimum SKU 60 0 -
560 10 XL M24 S/4+ Minimum SKU 60 0 -
S/4 conversion
560 10 XL M25 S/4+ Minimum SKU 60 0 -
560 10 XL M26 S/4+ Minimum SKU 60 0 -
560 10 XL M27 S/4+ Minimum SKU 60 0 -
M28 S/4 Full BOM 620 10 XL
M29 S/4 Full BOM 620 10 XL
M30 S/4 Full BOM 620 10 XL
….

13. Migration Scenarios Updates – SUM 2.0

SP17 release
13.1. Major updates with SUM 2.0 SP17 - Introduction
SUM 2.0 SP 17 (available as of May 26th 2023) offers a homogeneous option for DMO

1. DMO with system move: Homogeneous database migration option: SAP HANA to
SAP HANA
1. For combined ECC conversion & transition to PCE, "DMO with system move"
option is used
2. With “system move” option, till SP16 DMO was always heterogenous, meaning
the database type was always changed, for example from source DB2 or Oracle
database to SAP HANA database.
3. Disadvantage with “only heterogenous” option was that source systems like ECC
on HANA could not be used in a 1 step conversion / transition project to
S/4HANA in PCE
4. Now with SUM 2.0 SP 17, Homogeneous database migration option is made
available for DMO with system move
5. The Target system will always be S/4HANA, ERP on HANA is not supported in
the target environment
6. Earlier approach of using "DMO with system move“ with source database as
anyDB and target as HANA, remains unchanged
2. DMO move to SAP S/4HANA: DMOVE2S4

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 1. Disadvantage with SYSTEM MOVE approach is that it does not allow downtime-
optimization techniques like downtime-optimized DMO (doDMO) or downtime-
optimized Conversion (doC) for the conversion and transition to hyperscaler
2. Alternative approach "DMO move to SAP S/4HANA (on hyperscaler)"
(DMOVE2S4) is been made available under specific requirements and conditions
like low latency and better bandwidth
3. This works for both HANA and non-HANA database at source
4. R3load pipe mode is used, not file mode, so no dump files are created unlike for
"DMO with system move"

13.2. Source – S/4HANA, Target – RISE with SAP

S/4HANA Cloud, private edition (SP17 versus prior to SP17
approach)
Possible
Target
End of End of
Source Releases
Mainstream Extended Migration Approach
Release under
Maintenance Maintenance
PCE
Contract
S/4HANA S/4HANA • Option 1 – 2 Step process
31.12.2020 n/a
1511 2022 o Step 1 - SYSTEM
COPY
(backup/restore)
followed by
o Step 2 - S/4HANA
upgrade per
supported under
S/4HANA S/4HANA LMP, i.e the
31.12.2021 n/a Limited
1610 2022
Maintenance Policy:
• Option 2 (recommended) -
System Copy + S/4HANA
upgrade using DMO
SYSTEM MOVE option

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • Option 1 – 1 or 2 Steps
process
o Step 1 - SYSTEM
COPY
(backup/restore):
This approach is
S/4HANA possible till 2025
1709 o Step 2 – UPGRADE
S/4HANA (optional): Upgrade
31.12.2022 31.12.2025
1709 to latest release is
recommended as part
of the migration or at
a later stage

Option 2 (recommended) - System

S/4HANA
Copy + S/4HANA upgrade using
2022
DMO SYSTEM MOVE option
• Option 1 – 1 or 2 Steps
process
o Step 1 - SYSTEM
COPY
(backup/restore):
S/4HANA
This approach is
1809
S/4HANA possible till 2025
1809 31.12.2023 o Step 2 – UPGRADE
S/4HANA
31.12.2025 (optional): Upgrade
1909
S/4HANA 31.12.2024 to latest release is
1909 recommended as part
of the migration or at
a later stage

Option 2 (recommended option) -

S/4HANA
System Copy and S/4HANA
2022
upgrade using the DMO option

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • Option 1 – 1 or 2 Steps
process
o Step 1 - SYSTEM
COPY
(backup/restore):
This approach is
S/4HANA possible till 2025
S/4HANA 31.12.2025 2020/ 2021 o Step 2 – UPGRADE
2020/ n/a (optional): Upgrade
2021 31.12.2026 to latest release is
recommended as part
of the migration or at
a later stage

Option 2 (recommended option) -

S/4HANA
System Copy and S/4HANA
2022
upgrade using the DMO option

• Releases that have at least 9 months of maintenance (mainstream or extended as

applicable) 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 or extended 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.

13.3. RISE with SAP S/4HANA Cloud, private edition -

Summary of Transition Method & Storage Requirements
Storage Storage
Transition Transition
Source Target Requirement Requirement
Method (Till Method
Version Version (Not included in (Not included in
SP17) (Post SP17)
Base cost) Base cost)
1.Storage for 1.Storage for
Export dump on Export dump on
Migration server System Migration server
System
Conversion
ERP on Conversion
S/4HANA 2.Storage for (DMO w 2.Storage for
anyDB (DMO w
taking Backup on System taking Backup on
System MOVE)
database server MOVE) database server
(at least twice of (at least twice of
HANA DB size) HANA DB size)

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 Step 1

1.Storage for
copying source
database Backup
1.Storage for
on ERP on
Step 1 - System Export dump on
HANA DB server 1 Step -
Copy (backup / Migration server
(same size as System
restore)
ERP on HANA DB) Conversion
S/4HANA 2.Storage for
HANA (DMO w
Step 2 - System taking Backup on
Step 2 System
Conversion database server
MOVE)
(optional) (at least twice of
1.Storage for
HANA DB size)
executing Backup
on database
server (at least
twice of HANA
DB size)
Step 1 - System
Copy (backup /
restore)
1.Storage for
Step 2 - Step 1
Export dump on
S/4HANA
Migration server
S/4HANA upgrade 1.Storage for 1 Step -
S/4HANA
(mandatory) storing source System copy
1511 / 2.Storage for
(1511 & database Backup + S/4HANA
1610 taking Backup on
1610) For S/41511, on S/4HANA DB Upgrade
database server
1610 step 1 and server (same size
(at least twice of
step 2 need to as HANA DB)
HANA DB size)
be executed in
same project as
per LMP
guidelines
1.Storage for
Step 1 - System Step 1 Export dump on
Copy (backup / Migration server
1 Step -
S/4HANA restore) 1.Storage for
S/4HANA System copy
storing source 2.Storage for
(1709 + S/4HANA
(1709 Step 2 - database Backup taking Backup on
onwards) Upgrade
onwards) S/4HANA on S/4HANA DB database server
(optional)
upgrade server (same size (at least twice of
(optional) as HANA DB) HANA DB size)
(optional)

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

13.4. From ECC 6.0 on HANA To RISE with SAP S/4HANA
Cloud, private edition SYSTEM MOVE (old versus new
approach) – Scenario 1

• Option 1
o 1 Step - System Conversion (DMO w System MOVE)
▪ 1 Step RISE Migration together with S/4HANA conversion using “system
move” with one execution of SUM tool, 1 downtime, 1 SIT / UAT etc, so
all benefits of running 2 projects versus 1 project

• Option 2
o Step 1 – Copy ECC on Hana and go-live with ECC on Hana. [ERP PCE SKU is
required]
o Step 2 – S/4HANA conversion after few weeks

This option can still be chosen by customers with very complicated and big source setup
like multiple SAP systems, lot of custom code, many SAP/non-SAP Interfaces etc who
would like to reduce the overall risk and downtime by executing 2 projects, 1. Technical
consolidation followed by 2. Business consolidation

13.5. From S/4HANA To RISE with SAP S/4HANA Cloud,

private edition SYSTEM MOVE (old versus new approach)
– Scenario 2

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

13.6. Homogenous DMO - Requirements and Restrictions
Requirements and Restrictions

• Supported source systems

o SAP for Banking
o SAP ERP
o Systems based on SAP NetWeaver ABAP
o SAP S/4HANA
o SAP BW or SAP BW/4HANA systems are not supported

• Supported target systems

o SAP S/4HANA (on-premise deployment)
o SAP S/4HANA Cloud, private edition
o Systems based on SAP S/4HANA Foundation

• Supported SAP HANA database revisions

o Source database: SAP HANA 1.0 revision 1.00.122.05 or higher, or SAP HANA
2.0
o Target database: SAP HANA 2.0 (Note: If SAP HANA 2.0 is already on the
source system, SAP HANA revision on target system must be equal or higher)

• Scale-out scenarios are not supported

• An existing table partitioning in the source database is taken over to the target database if
no field name changes have been made for the table. Otherwise, manual activities are
required as described in the DMO guide.

13.7. “DMO with system move” and "DMOVE2S4" Overview -

Choosing the right approach

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

When to use what:

Source Target DMO with

DMOVE2S4
Version Version system move
ERP on Yes (when downtime optimization techniques
S/4HANA Yes
anyDB like doDMO, dOC are needed)
ERP on Yes (when downtime optimization techniques
S/4HANA Yes
Hana like doDMO, dOC are needed)
Yes (when downtime optimization techniques
S/4HANA S/4HANA Yes
like doDMO, dOC are needed)

13.8. DMO Move to SAP S/4HANA: DMOVE2S4 -

Requirements and Restrictions
DMOVE2S4 Requirements and Restrictions:

• Technical requirements:
o A low latency with less than 20 ms
o A high bandwidth of more than 400 MBit/s

Note - The Software Update Manager checks the latency and writes the result to the
DBSTAT.LOG file. If the latency is too high, a warning is additionally written to the
CHECKS.LOG file.

• The approach can lead to longer uptime processing.

• If the technical requirements are not met:

o SAP recommend using "DMO with system move" instead of the DMO Move to
SAP S/4HANA approach.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • The downtime optimization techniques are currently only allowed for source systems on
non-HANA database
o plan is to support this with a later SUM SP version, like SP 18 in October 23
o with SUM 2.0 SP 17, we accept pilot projects for homogenous DMO with
doDMO or with doC

• For DB2 ("IBM DB2 for LUW" or "IBM DB2 z/OS") as source database type, target
product version must be SAP S/4HANA 2022 (or higher)

• Some restrictions apply for schemas and partitioning

o documented in SAP Note 3296427 on DMO

13.9. Important links for further information

• SAP Note 3296427 for DMO with SUM 2.0 SP 17 (sections on "Homogeneous database
migration")
• DMO Guide for SUM 2.0 SP 17 (sections on "Homogeneous database migration")
• https://help.sap.com/docs/SAP_S4HANA_CLOUD_PE (PCE documentation)
• DMO Move to SAP S/4HANA (on Hyperscaler) | SAP Help Portal (DMO Guide)
• SAP Note 3296427 for DMO with SUM 2.0 SP 17 (sections on "DMO Move to
SAP S/4HANA")
• 3296427 - Database Migration Option (DMO) of SUM 2.0 SP17
• https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html:
(White paper: "Converting from SAP ERP on Premise to SAP S/4HANA on Microsoft
Azure“)
• “DMO to Azure”: combine SAP S/4HANA conversion with the move to Azure (without
“DMO with System Move”) | SAP Blogs (Blog post in SAP Community)
• https://blogs.sap.com/2023/05/31/two-major-news-with-sum-2.0-sp-17/ (Two Major
News with SUM 2.0 SP 17)

14. SAP Forms Service by Adobe (ADS)

compatibility with PCE
As per SAP Documentation, ADS has minimum backend Source system requirements as below:

• SAP NetWeaver 7.50 SP24 or higher

• S/4HANA on-premise 1809 (SP8+), 1909 (SP6+), 2020 (SP4+), 2021, or higher
• ABAP environment on SAP BTP

ERP PCE Form as service by Adobe support - this is not supported for EHP7 (which is based on
NW740) and supported only EHP8 (which is on NW 750) from the particular patch level.

Also, it has restrictions for source S/4HANA releases as well.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

https://help.sap.com/docs/forms-service-by-adobe/sap-forms-service-cf/use-cases-sap-forms-
service-by-adobe

15. BOBJ System Copy

1. BOBJ Content Export using Promotion Management Tool on Source-BOBJ.
2. Copy BOBJ Content to blob storage.
3. Copy BOBJ Content to the Additional File Storage*, mounted on BOBJ App Server.
4. BOBJ Content Import using Promotion Management Tool on Target-BOBJ from the
Customer Network.

System copy to BOBJ, private edition, shared responsibilities:

SAP:

• Provides BOBJ Greenfield System along with the Additional File Storage on Target.
• Provides Object Storage to the Customer/Partner and mounted on the BOBJ APP Server.
• SAP executes monitor tools, backup schedule and validation.
• Copy the BOBJ Content (LCM Biar Files) from Object Storage to Block Storage
provisioned on BOBJ APP Server. This is requested via Service Request.

Customer/Partner:

• Executes all required preparation activities On-premise BOBJ

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 • Perform BOBJ Content Export using Promotion Management Tool at Source.
• Transfers the BOBJ Content (LCM Biar files) to the Object Storage provided by SAP.
• Execute BOBJ(Target) Promotion Management Tool from Customer Network and
perform Content Import using the copied LCM Biar Files. This step is done using BOBJ-
ADMIN user provided by ECS.
• Executes all the post system copy steps and activities in the target private cloud system

16. Migration Dump Estimation

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)

How to estimate migration dump size?

• Source: Suite on HANA Sizing Report

•
o Migration Dump Estimation = 25% of Column store data + Hybrid LOBs

Migration Dump Estimation = 535.75 + 2056 = 2591.75 GB

•
o SoH HANA DB Backup Size = 4384.2 GB

• Source: S/4HANA Sizing Report

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

 •
o Migration Dump Estimation = 25% of Column store data + Hybrid LOBs

Migration Dump Estimation = 1767.25 + 1084 = 2851.25 GB

•
o S/4HANA HANA DB Backup Size = 8993 GB

Benefits:

• Estimate the additional storage Size for Migration

• Estimate the runtime for copying dump to cloud

17. Sizing Example

Hana Sizing Output

For as-is migration (without growth estimation etc.), PCE Template (XL) – 4 TB

e.g. Azure

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

e.g. AWS

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

After clean-up as well, not much changes in the DISK requirements

PCE Template Storage Info : PCE Std. template has pre-defined data storage

AWS HANA-Virtual-4096GiB-x2iedn.32xlarge

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

Azure HANA-Virtual-3892GiB-M128ms_v2

Key Takeaways

• Always check disk size requirements in particular from the sizing report
• In case of disk size requirement is higher than HANA memory then couple of LOB
(Hybrid LOBs / Large Objects e.g. attachment tables) tables are in large in size e.g.
SOFFCONT1
• Additional HANA DB Size is to be considered with below SKU to cover additional disk
size in addition to the template covered storage
o 8011367 - SAP Additional Database Storage, private cloud edition (PCE
Packaged)
o Additional Storage - HANA DB (Tailored for QT Tool)
• Specify the correct Storage class in PQA and provide necessary information during S2D
for extending /hana/data volume with above storage allocation

18. Migration Process for Partners

(Content from Partner Management Team)
Latest version can be found on PCE Migration Folder ( PartnerMigrations_RollOut-
v1.PDF)

19. Migration Assisted Service

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

ECS will provide resources to execute the tasks which need OS/DB access

GSSP or any other Partner 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

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)

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)

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.

SAP Internal – Authorized for Partner ( DO NO REDISTRIBUTE)