S/4HANA to Cloud Migration
- Danica Esteban
- Linh Nguyen
- Ashish Gaurav (Unlicensed)
Background
Migrating S/4HANA to the cloud through IT-Conductor can be accomplished using a process definition. This automation feature in the platform simplifies the migration process from the provisioning of virtual machines (VMs) to the installation of the database and application in the cloud environment.
Process Definition
To access the process definition developed for this demo scenario, navigate to the Tenant Service Grid > Process Definitions > AWS S4 HANA 2021 and HSR Setup -ag.
Figure 1: AWS S4 HANA 2021 and HSR Setup -ag Process Definition
Also, we used our tenant called “OZSoft” but the process can be cloned and applied to any customer after being onboarded to IT-Conductor as a tenant. IT-Conductor creates and clones the Git repository for each tenant who needs to leverage these types of automation runbooks.
Additionally, the "Provision s4 hana node" and "Provision s4 hana node - Secondary" activities can be run simultaneously, allowing for the provisioning of both VMs in parallel and reducing overall migration time.
Now, let's look into each step/activity of this process definition in more detail.
Provision S4HANA Node
The "Provision s4 hana node" and the "Provision s4 hana node - Secondary" activities are responsible for the provisioning of the VMs for the primary and secondary nodes respectively using Terraform scripts.
Before provisioning the VMs, it is important to ensure that the necessary authentication details, including the access key and secret access key, are in place to enable successful authentication with the AWS cloud environment.
Below are the available fields that you need to define prior to running the process definition.
Variables field (in below screenshot) contains the access and secret keys.
Root Directory contains the Github directory and main file contains the terraform (.tf) file.
Figure 2: Provision S4HANA Node (Terraform Configurations)
Install S4HANA DB
The "Install S4 HANA DB" and the "Install S4 HANA DB - Secondary" activities are responsible for the installation of the S4HANA database using Ansible.
Below are the available fields that you need to define prior to running the process definition.
In the Root Dir, we provide the GitHub directory where ansible files are placed.
Playbook field contains parent playbook (sap-deploy.yml) which will be used for S4HANA database installation. The Execution Config contains variables the installation, which can be modified per your needs such as System ID (SID), System Number (sysnr), etc.
Figure 3: Install S4HANA DB (Ansible Configurations)
Install S4HANA App
The "Install S4 Hana App" and the "Install S4 Hana App - Secondary" activities are responsible for the installation of the S4HANA application using Ansible.
Below are the available fields that you need to define prior to running the process definition.
In the playbook field, we provide the parent playbook (s4-app-deploy.yml) for installing S4HANA App.
Similar to the HANA DB installation, the Execution Config contains variables the installation, which can be modified per your needs such as System ID (SID), System Number (sysnr), etc.
Figure 4: Install S4 Hana App (Ansible Configuration)
The VM provisioning and the DB and app installations on both primary and secondary nodes/servers can be done in parallel. Once both VMs are provisioned, and the HANA database and S4 app are successfully installed, the workflow will proceed to trigger the “Join” activity.
Figure 5: Primary and Secondary Activities
Confirm to Begin HSR
Following the completion of the "Join" activity is the “Confirm to Begin HSR” activity. This is a manual task that can be triggered once the customer is ready to perform system replication.
To do that, click Confirm to Begin HSR > General tab. Select "Completed" as the status to confirm that you are now ready to proceed to the next activity. Then click the Save button.
Figure 6: Confirm to Begin HSR Activity (General Detail)
Pre-configure Secondary Host
The "Pre Configure Secondary Host" activity is responsible for preparing the secondary host or node/server prior to the system replication using Ansible.
Below are the available fields that you need to define prior to running the process definition.
Figure 7: Pre-configure Secondary Host Activity (Ansible Configurations)
Replicate
The "Replicate" activity is responsible for performing the system replication using Ansible.
Below are the available fields that you need to define prior to running the process definition.
Figure 8: Replicate Activity (Ansible Configurations)
Note:
It takes time to replicate the data depending on the size of the database and network bandwidth.
Just keep refreshing at regular interval until all activities turn GREEN which indicates that they have been successfully executed.
You can further perform validation using execution logs and/or checking the replication state directly from the primary and secondary host/node/server.
Video
Do you have a question about the content on this page? E-mail us at support@itconductor.com.