In this blog I wish to discuss about the basic usage of migration server(VM) / Import Server during a brownfield system migration to SAP S/4HANA Cloud,private edition.
Below are the questions that this blog is targeted in addressing.
1. What is a migration server / Import server in RISE with SAP S/4HANA cloud,private edition?
2. What is the configuration of migration/Import server?
3. Why should the customer subscribe for additional storage while using Migration server?
4. How many migration/import server are needed to complete a 3 system landscape migration to SAP S/4HANA Cloud,private edition?
5. How should we decide upon the amount of temporary storage that are needed that will be linked to Migration / Import server ?
6. Does the migration server host any temporary HANA DB?
7. Can a customer continue to use the import server post migration ?
8. What are the scenarios where we can not use migration server during a brownfield implementation of RISE ?
9. What are the high level steps involved with migrating an S/4HANA on-premises to private edition?
1. What is a migration server / Import server in RISE with SAP S/4HANA cloud,private edition?
This is a temporary SUSE Linux VM with root access that a customer must subscribe for usage in brownfield implementation of RISE with SAP. This is used by the partner during migration. This migration can be either be a system conversion or a system copy to S/4HANA. This is also called as Import server .
NOTE:Migration Server/ Import Server is not valid for a green field implementation
In case of a homogenous migration, this temporary VM acts similar to RDP server from where HANA studio or SWPM can be invoked.
In case of a system conversion ,partner installs a temporary PAS which connects to DB that runs on a fully protected S/4HANA target /skeleton system. Partners use this PAS to complete the remaining migration tasks such as continuing the executing SUM DMO with system move in target private cloud.
This can be used in Azure/ AWS / GCP / SAP DC deployments IaaS providers
NOTE:In the private edition, installation of target S/4HANA skeleton system is fully under the control of SAP. Neither partner nor the customer get OS or DB or client 000 access to target skeleton environment. However, as partners are responsible for migration and conversion, usage of temporary VM with root access is mandatory to completing many basic tasks during migration / conversion.
2. What is the configuration of migration/Import server?
The virtual SUSE Linux server comes with 128GB memory and 32 vCPUs
The server comes with 100GB storage provided as:
/sapmnt 20GB
/usr/sap/ 80GB
3. Why should the customer subscribe for additional storage while using Migration server?
The customer along with migration server (temporary VM), also need a additional storage.
In case of a homogenous migration from on-premises to private cloud, partner need a temporary storage to move the backup dumps from on-premises to this VM. Post this, SAP will move this dump to the server that host the target S/4HANA skeleton system. This server can be used to trigger a restore on the skeleton S/4HANA target system.
In case of a system conversion, we need more space to copy the SUM-DMO with system move’s SUM folder to continue the execution in target environment. This will also host the required kernels etc and hence we need additional storage.
4. How many migration/import server are needed to complete a 3 system landscape migration to SAP S/4HANA Cloud,private edition?
As this migration/import server is a temporary VM, only 1 server is ment to be used for the whole migration project. Many SAP tools that will be copied to this VM will be reused in the subsequent systems.. If needed we can perform a cleanup on this and reuse the same for DEV,QA,Mock runs and production.
Note:There are up to 4 rounds of SAP cloud post processing (development, quality, productive dryrun,productive) included in the customer’s contract.
5. How should we decide upon the amount of temporary storage that are needed that will be linked to Migration / Import server ?
Incase of a homogenous system copy , as this will be reused for every system (DEV, QAS, PRD…) it should be calculated based on the biggest source database.
For a heterogenous migration, if the source dump is expected to be 150GB export dump plus a 30GB buffer, then the storage that must be attached to the import server/migration server can be around 200GB.
6. Does the migration server host any temporary HANA DB?
No.This server will not have any database installed.
7. Can a customer continue to use the import server post migration ?
The migration server will be decommissioned as soon as the migration project is completed. SAP can not continue to provide this server access as this allow direct access to systems on target private cloud environment
8. What are the scenarios where we can not use migration server during a brownfield implementation of RISE ?
Import Server is only valid in case of a target HANA DB. This is not applicable in case of below migrations.
◉ ASE Migrations
◉ Java System Migrations
◉ BO System Migrations
◉ Content Server System Migrations
Eg. In case of a ASE Migrations the SWPM tool cannot be executed from the Migration VM. Also ASE DB import can only be achieved by launching SWPM from DB server itself. In this case partner must rely on SAP for tasks that involves OS/DB access. This support is provided by the SAP in the name of Migration Assisted Service (MAS).
With MAS, SAP’s MAS team helps with 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.
9. What are the high level steps involved with migrating an S/4HANA on-premises to private edition?
High level steps involved with System conversion to private cloud:
1. As a first part of DMO with system move, partner executes uptime activities in the source on-premise system
2. To continue the conversion in the target private cloud, partner transfers the required dumps to import server . This includes SUM/SWPM/SAP Kernel
3. Partner installs a temporary PAS on the migration server which is connected to the target HANA DB that runs on the private cloud.(This skeleton system is installed and managed by SAP)
4. Partner continues to execute the technical conversion in target from import/migration server
5. Post completion,PAS is stopped/uninstalled by the partner and they informs SAP on the same.
6. SAP starts SAP application that they have installed in private cloud that connects to the HANA DB in the private cloud.
7. Partners executes the post conversion steps in the target private cloud (which does not need a OS/DB or client 000 access)
8. SAP executes the post activities such setting up monitoring tools,backups schedule etc before handing over the system to the customer
High level steps involved with homogenous migration to private cloud:
1. Partner perform a backup of HANA DB on the on-premise environment
2. Partner transfers the required backup dumps to the import server. Partner installs other tools on this server like HANA studio or place SWPM dump that are required to trigger the restore of HANA
3. SAP copies this dump to the HANA DB server which runs on the private cloud
4. Partner from the import server, trigger a restore to the specified HANA DB in private cloud
5. Post completion,partner informs SAP.
6. SAP starts SAP application that they have installed in private cloud that connects to the HANA DB in the private cloud.
7. Partners executes the post steps in the target private cloud (which does not need a OS/DB or client 000 access)
8. SAP executes the post activities such setting up monitoring tools,backups schedule etc before handing over the system to the customer
No comments:
Post a Comment