Stability and Availability Optimization

of Distributed ERP Systems During

Cloud Migration
Gerard Christopher Aloysius1 , Ashutosh Bhatia2(B) , and Kamlesh Tiwari2
1
Schneider Electric, Bangalore, Karnataka, India
[email protected]
2
Birla Institute of Technology and Science, Pilani, Pilani, Rajasthan, India
{ashutosh.bhatia,kamlesh.tiwari}@pilani.bits-pilani.ac.in

Abstract. Enterprise resource planning is a powerful software package

that enables businesses to integrate a variety of disparate functions, it is
a concept whereby an organization enables effective communication and
data exchange within the business units and associated third parties such
as vendors and banks. SAP is the de-facto ERP software for a company
that manages business operations and customer relations. Many organi-
zations have started migrating their ERP to infrastructure-as-a-service
(IAAS) providers like amazon web services and Microsoft Azure. Though
there is a significant increase and positive sentiment to migrate produc-
tive workloads to the cloud, the availability and reliability of applications
remain a huge concern. No comprehensive study specifically examines the
stability and availability of productive ERP workload in the cloud with
large databases. Cloud brings specific advantages like faster time-to-value,
moving out of expensive hardware, ease of spinning up virtual machines,
and accessibility of the latest technologies in one place. There is a need for
a study to specifically look into moving productive ERP workload to the
cloud and a roadmap to achieve optimum stability and availability while
leveraging all the advantages we get from cloud computing. The paper’s
objective is to take in the experience of migrating several productive ERP
landscapes with a database size ranging from 2 TB to 20 TB and propose a
design roadmap to attain optimum Stability and 99.9% Availability. The
design was implemented and measured for its effectiveness post-migration
by comparing the application with the data before migration. SAP pre-go-
live and post-go-live reports show a 33% reduction in dialog response time
and a 40% improvement in response time during peak hours. The over-
all database grew from 8449 GB to 8703 GB during the analysis. When
we extrapolate the analysis to 21 days post-migration, we see that the
response time improves even further. We see 100% applications available
during the analysis period.

1 Introduction
Many customers currently using ERP Solutions on-premise would prefer to
take advantage of the benefits of the cloud, like avoiding hardware cost and
The original version of this chapter was revised: Acknowledgement has been added
below figures 1 and 2. The correction to this chapter is available at
https://doi.org/10.1007/978-3-031-28451-9 50

c The Author(s), under exclusive license to Springer Nature Switzerland AG 2023, corrected publication 2023
L. Barolli (Ed.): AINA 2023, LNNS 654, pp. 343–354, 2023.
https://doi.org/10.1007/978-3- 031-28451-9 30
344 G. C. Aloysius et al.

maintenance, labour savings, reduction in lost sales, performance improve-

ments, global presence, and sophisticated availability solutions [1]. These migra-
tions are typical of a “Lift and Shift” nature where there is no change in
the vendor/software though there may be changes in the target operating sys-
tems/database and hardware. The lift and Shift migration path dominates enter-
prise workload migration to the public cloud. In an IDC survey, respondents
indicated it to be the most common migration path for almost all types of
enterprise workloads [2]. Customers prefer this approach due to its simplicity in
taking their workload to the cloud. However, there is a concern that there is no
significant improvement in the performance or their availability and application
response post moving to the cloud [3]. The fundamental problem with a “Lift
and Shift” approach is that the landscape is moved “AS-IS” and retains the lim-
itations of an on-premise deployment. On the other hand, cloud infra has some
unique capabilities and advantages which should be leveraged without carrying
the limitations of an on-premise deployment. In the following, we discuss some
issues and constraints related to the on-premise deployment of ERP solutions,
which should not be carried over to the cloud.
On-premise deployment involves High Capital expenses in purchasing the
Physical hardware and much effort in building and managing the virtual systems
[4]. This results in customers preferring a central installation over a distributed
deployment. Cloud liberates the customers from these constraints by providing
a platform where they can spin up virtual machines at low cost and with less
effort, so there is no need to carry this on-premise limitation to the cloud.
Moving systems as low-availability solutions is another on-premise deploy-
ment constraint which is usually the result of a lack of flexibility and limitations
of the data center. So it does not make sense to carry over these solutions to
the Cloud but rather architect it again to leverage the high availability options
provided by Cloud [5]. Many on-premise production deployments run in a Single
Node solution without High availability but only a less efficient Disaster recovery
solution that usually has a high RTO and RPO.
Due to the lack of elasticity in scaling, the on-premise deployments are can be
oversized with a huge storage buffer to avoid the need to extend the hardware in
the near future. This means customers typically pay for something that they do
not use. The lift and shift mentality is to move the workload and size it later [6].
This is a constraint that need not be carried over to the cloud. The same applies
to many production systems that are over-utilized with no room to add more
CPU or memory, and it is typical of them to run on outdated hardware where
there is no room to scale. So overall, the sizing mentality of on-premise should
not be carried over to the cloud; hence, there is a need to approach resizing from
a cloud standpoint.
In an enterprise with internal users and customers across the globe, the infras-
tructure needs to be closer to the user base. In an on-premise scenario, that
means having to invest in multiple data centers and infrastructure components
and is extremely ineffective from a cost standpoint. However, using an enter-
prise cloud service provider with a presence across different geography makes the
 Stability and Availability Optimization of Distributed ERP Systems 345

process simple, and cost-effective [7]. For example, AWS has a presence across
regions like North America, South America, Europe, the middle east/Africa, and
the Asia Pacific, with several data centers within these regions. So, to architect
an enterprise solution for a global organization is much simpler in the cloud.
Migrating an SAP landscape cannot be done in isolation. We will still need
the integration between external systems, which will require much tweaking from
both the migrated SAP System and the external system in question. There is a
huge reliance on individuals and no systemic approach to handling this. One of
the important tasks when planning an SAP migration is to ensure SAP inter-
faces are documented. Some of the interfaces may have hardcoded IPs that need
manual correction or moved to hostnames with DNS configured as a best prac-
tice. External interfaces need to be tested, requiring coordination from exter-
nal partners, so it needs to be carefully planned [8]. There have been enumer-
able situations where external interfaces are critical but not captured as part of
the migration. Raising firewall requests and implementing them during a run is
extremely cumbersome and will directly affect availability since a non-working
functionality is still a downtime from a customer standpoint.
After several years of having a solution On-Premise with substantial money
invested in tools and solutions, customers get tied up to a solution without ques-
tioning its efficiency vs. other available technology options. Moving to the cloud
reopens this conversation; instead of carrying over their old backup and recovery
and monitoring solution, it makes much sense to work with the cloud vendor and
identify tools and solution that gives better performance and reliability [9]. In
addition, cloud vendors usually support multiple customers with a similar setup,
so they should have the performance metrics of these tools handy [10].
This paper proposes a method to ensure stability, availability, and optimum
response in the migrated system for a typical “Lift and shift” scenario with or
without Unicode conversion. The proposal significantly improves the stability,
availability, and performance of the SAP ERP environment.

2 Proposed Methodology for AS IS On-Premise to Cloud

ERP Migrations

The paper presents an approach to ensure stability, availability, and performance

in the migrated system for a typical Lift and shift scenario with or without Uni-
code conversion. This approach arrived after migrating several ERP productive
landscapes from on-premise data centers to the cloud. The effect of the migration
approach was measured after migrating the productive landscapes and signifi-
cant improvements were observed in the availability and performance of the SAP
ERP system.
The steps involved in the proposed approach are as follows:

1. Convert the Central installations to a Distributed SAP ERP landscape

2. Resize the system based on on-premise CPU usage and workload analysis.
3. Move SAP Landscape to regions closer to the Userbase
346 G. C. Aloysius et al.

4. Design a High availability solution leveraging Cloud

5. Approach interface setup by Scanning ports and testing using pre-emptive
tools
6. Measure the effectiveness of Load distribution, High-availability, and Appli-
cation response post-migration.
We take an example scenario of migrating an SAP ERP system running with
an 8 TB database and five application servers. The system is built using an SAP
central installation with the central instance and database running on a single
node with five application servers. We implement the proposed methodology in
this box. Migration methodology is purely system specific and is irrelevant to
our discussion here.

2.1 Converting the Central Installations to a Distributed SAP ERP

Landscape
In a Distributed SAP system design, the following components of the SAP
instance will be built on dedicated virtual machines. Since the central instance
and database are installed on a single node that will be separated as part of the
target system build. We will have the following components installed separately
on dedicated virtual machines.
• The Primary application server (PAS) - 16 cores/128 GB RAM
• Central services (SCS) - 2 Cores 16 GB RAM
• Application servers - 16 Cores/128 GB RAM
• Database Server - 64 Cores/128 GB RAM
This ensures that they do not serve as a bottleneck to each other. The fol-
lowing file systems are shared across the VMs using NFS share; 1) /sapmnt -
SAP Mount directory, which holds the SAP profile/ kernel, 2) /usr/sap/trans -
SAP Transport directory. The components are separated and will be installed
in dedicated virtual machines in a private subnet. The firewall is set at the VM
level so that each instance can communicate with the other (Table 1).

Table 1. Production server inventory

SN SAP ver. AWS instance System type Cores Memory (GB)

1 SAP ERP6 r5.large ASCS 2 16
2 SAP ERP6 r5.large ERS 2 16
3 SAP ERP6 r5.4xlarge AAS1 16 128
4 SAP ERP6 r5.4xlarge AAS2 16 128
5 SAP ERP6 r5.4xlarge PAS 16 128
6 SAP ERP6 r5.4xlarge AAS3 16 128
7 SAP ERP6 r5.4xlarge AAS4 16 128
8 SAP ERP6 r5.4xlarge AAS5 16 128
9 DB Server Primary c5a.16xlarge Primary DB 64 128
10 DB Server Secondary c5a.16xlarge Secondary DB 64 128
ASCS: Abap Central Services, PASS: Primary Application Server, ERS: Enque
Replication Server, AAS: Additional Application Server
 Stability and Availability Optimization of Distributed ERP Systems 347

2.2 Advantages of Building a Distributed System Deployment

• Every instance of the application servers, as well as the central services and
database server, will have dedicated memory and CPU and will not create a
resource crunch.
• DB node will need High IO, CPU, and memory to run on a separate large
instance so that it is not deprived of system resources. The diagram above
shows that the database host will run on a separate host. It also shows the
instance type/Sizing details of the system: All the app servers will be running
on “xlarge” AWS instances, and the central services will run on a “Large”
environment.

2.3 Resize the System Based on On-Premise CPU Usage

and Workload Analysis
Rightly sizing the virtual machines based on current performance metrics is
extremely important. This can be done in tandem with the vendor’s proprietary
sizing tools. One reason for inefficiency is the mindset to overprovision that many
IT professionals bring with them when they build their cloud infrastructure.
The traditional mindset of overprovisioning is unnecessary in the cloud. Cloud
provisioning happens based on average usage rather than peak usage, so by
rightly sizing, organizations can save up to 70% percent on their monthly bill [11].
By right-sizing before migration, you can significantly reduce your infrastructure
costs. Improper sizing can result in higher cloud infrastructure spending for a
potentially long time.
• Take a monthly average and peak CPU usage/memory usage and add the
buffer to ensure there is at least 40% average idle CPU time/memory usage.
For example (if an 8 CPU/64 GB RAM machine has an average CPU utiliza-
tion of 80–90% and average/peak memory usage of 80/90%, it makes sense
to move the target instance to a 16 CPU/128 GB).
• Take SAP workload analysis data (ST03n) and look at the Dialog and Back-
ground response times. If the response times are unsatisfactory, there could be
a CPU/Mem or DB Bottleneck. So it is important to find the bottleneck and
add additional resources to the target system to mitigate this. For example,
if we observe an application response time of 2200 ms with a high database
response time contributing to 80% of the response time. It makes sense to
bump up the resources in the database server and reduce the overall response
time to less than 1000 ms.
• Look at SAPS (SAP Application Performance Standard (SAPS) which is a
hardware-independent unit of measurement that describes the performance of
a system configuration in the SAP environment. Calculate the SAPS delivered
by the On-premise system and optimize the target system to ensure it delivers
the calculated SAPS with adequate CPU and memory buffers.
• Estimate the IOPS usage (baselines IOPS required) and maximum through-
put on the on-premise Database server and ensure adequate idle time and
sufficient throughput on the target database servers.
348 G. C. Aloysius et al.

2.4 Move SAP Landscape to Regions Closer to the Userbase

Cloud migration can be a great opportunity to enhance the overall user expe-
rience because you can move the services closer to your user base. Based on
migration done across different regions in Europe, Asia, and the Americas, we
clubbed the landscape based on regions. For example, Europe was placed in
“Paris” as the primary region and “Ireland” as the Disaster recovery center.
Singapore served as the primary region for Asia and “Sydney” as the disaster
recovery. For the landscape built-in “Paris,” Since the user base was predomi-
nantly based out of Europe, this enhanced the overall user experience, and this
is a unique advantage of the cloud since you are not tied to a dedicated data
center in a single region. Further, the latency can be tested with utilities such
as ping to ensure the server is placed in a region with acceptable latency.

2.5 Design a High Availability Solution Leveraging Cloud

The action aims to build an SAP application using a highly available architectural
pattern. This will involve identifying a “Single Point of Failure” in the system
and ensuring redundancy for those components. High availability usually entails
having a “zero” for the Recovery point objective (RPO) and several minutes as a
recovery time objective (RTO) as shown in Fig. 1. The SAP production environ-
ment was built, considering the system could handle spikes in workload. At the
same time, the infrastructure is positioned to fail safely in case of failures at any
layer, be it a database, application, hardware, or a complete data center failure.

Fig. 1. Design a high availability solution using AWS single region architectural pat-
tern: adapted from Pattern 1: A single Region with two AZs for production mentioned
in [12]
 Stability and Availability Optimization of Distributed ERP Systems 349

Key Features of the Architecture

The Architecture will provide redundancy to the following single point of failures
in the system
• SAP Central services (holds the message server and Enque)
• Application Servers
• Database Instance
• /sapmnt file system

SAP HA Components
As shown in Fig. 2, the SAP production system is built across two separate data
centers (let us call them DC1 and DC2) in Paris (Region) as active/passive. The
compute deployed for the productive Database, SAP central services, and applica-
tion servers are of the same type on both data centers. SAP Central services (SAP
ASCS) is a single point of failure, so it will be replicated by building Active central
services in DC1 and a passive central service in DC2. Central services also hold
the application locks through the Enqueue service; this is a single point of failure
and will be addressed by building an active Enqueue replication service in DC2. In
the event of a failure, the cloud network load balancer will relocate the Enqueue
service to the active enqueue replication service. This will ensure the locks are
not lost in the process. As noted here, we are not leveraging any OS-level cluster
solutions for auto-failover but rather a replication solution used in tandem with

Fig. 2. SAP HA components diagram Adapted from “SAP ASCS High Availability
using ERS explained” https://blogs.sap.com/2021/10/28/sap-ascs-high-availability-
using-ers-explained/
350 G. C. Aloysius et al.

the cloud network load balancer to move between nodes manually. The solution
deployed in a Single region - Multiple data center architecture with redundancy
built within the region. If we need an auto-failover to datacenter2, we can add a
cluster solution into the mix. There are specific services like FTP, SFTP, and spe-
cific ports which can be set up for redirection in the cloud network load balancer.
This can be used as an additional application service load balancing tool along
with sap logon groups. The load balancing between the application servers is man-
aged using a standard SAP logon group solution (SMLG). Redundant application
servers will be available in both data centers and will serve as a backup to each
other. Database instances will be replicated by a synchronous replication setup
between the databases in both data centers. Logs from the primary database are
shipped across the network and applied to the secondary database in real time.
So if the primary database fails, the secondary is ready to handle the load. This
requires reliable network availability between the two data centers.
Assumptions in the Architecture We require a minimum availability of
99.9%. This will require the system to be replicated to another node within the
same region. Since the zones are within the Paris region, we will use a Sync

Table 2. CCMS: load distribution

Instance St Resp. time Threshold User Thrshd Sample Quality Dialog

(ms) steps
1 393 60000 99 600 14:23:12 578 100
2 774 – 143 – 14:23:17 577 124
3 741 – 150 – 14:20:23 576 115
4 0 – 0 – 00:00:00 0 0
Summary – – 392 – – – 339

Table 3. Workload overview: average time per step in ms - 21 days of data

Task type name # steps Time Avg. proc. time CPU time DB time Wait time
ALE 210,570 59,6 32,0 9,6 14,9 0,3
AUTOBAP 22,746 1.364,7 599,6 266,5 599,7 1,9
AUTPCCMS 113,618 2,7 2,6 0,3 0,0 0,1
AUTOTH 101,705 2,6 1,3 0,4 0,0 1,3
BACKGROUND 3204,851 6.660,6 2.291,2 931,2 4.262,9 0,0
BUFFER SYNC 56,846 11,7 3,2 1,9 8,4 0,1
DOLOG CLEANUP 56,846 14,1 2,1 0,3 12,0 0,1
DEL. THCALL 581 235,2 173,4 48,5 61,3 0,5
DIALOG 3986,076 848,2 144,9 98,2 441,6 0,8
HTTP 307,392 61,4 17,7 8,1 18,2 0,6
OTHER 145 15.206,0 157,8 140,8 2,5 0,2
RFC 16228,825 2.259,5 433,7 59,9 351,9 0,9
RPCTH 1,861 94,7 49,0 34,6 45,7 0,0
SPOOL 530,113 198,5 128,8 25,2 28,0 38,5
 Stability and Availability Optimization of Distributed ERP Systems 351

replication to ensure immediate data availability on the other node. We assume

Business is fine with the additional cost incurred by deploying the same set of
systems with the same capacity in an additional data center. This is the price
that we are paying to ensure a stable system. We assume Business has approved
the data transfer cost incurred by replicating the data across the data centers.
In the event of a failure of a single data center, we are fine with running the
productive system on the compute of the alternate data center.

2.6 Approach Interface Setup by Scanning Ports and Testing Using

Pre-emptive Tools
The migrated ERP system cannot function in silos. All the connections to the
external interfaces directly or through the middleware should work. The first
step is to develop a diagrammatic representation of the interfaces using existing
documents and inputs from the stakeholders. As a best practice, we recommend
starting with the SAP RFC connection using transaction code SM59 and using
the data as a starting point to develop the integration diagram.
Capture Ports On-Premise
Set up Port scanners for one month on the on-premise environment to capture
incoming and outgoing ports; cloud vendors have their proprietary tools to do
this. This will give a list of used ports/IP addresses of incoming and outgoing
connections.
Retain On-Premise Fully Qualified Domain Name (FQDN)
Retaining the same FQDN as a source for migration ERP system can save a
lot of effort because as long as the firewall is raised and the DNS is modified to
reflect the new IP, there won’t be any changes required in the backend systems
to redirect to the new VM. Since the FQDN is retained, they should be able to
talk to the migrated system without any backend reconfiguration. This can lift
a lot of burden during interface testing.
Raise Firewall Requests
Based on how the network is configured, we need firewall requests raised to
open the ports to allow connection unidirectionally or bi-directionally. All the
requested rules need to be implemented by the network focal.
Test Firewall Rules Beforehand
Once the Firewall rules are implemented and the virtual machines are ready, we
can test whether the implemented rules are working by using a simple telnet/curl
test to check for the response on specific ports since the SAP system is not
installed at this point. In addition, we can use scripts to listen on specific sap
ports like 32XX 33XX 5XX00, etc., and test the incoming from backend systems.
This will ensure that the implemented rules are working.
Perform Interface Testing
As part of the mock migration, we can get all the interfaces tested beforehand; the
final testing can follow this during the cutover. In addition, performing a mock
migration helps to ensure the interfaces are talking from and to SAP ERP.
352 G. C. Aloysius et al.

2.7 Measure the Effectiveness of the Road Map

The best part of the road map is that all the attributes addressed can be effec-
tively measured using standard application tools. Performing this productive
ERP migration, we measured the attributes as shown below.
Load Distribution
The CPU Load on the app servers and DB server are below the threshold and
well distributed across the landscape.
Table 2 shows SAP Workload distribution during peak business hours as we
can see, the workload is optimally distributed across the application servers.
Availability Measurements
There was not a single unscheduled downtime since the start of the application
on April 7, 2022–April 23, 2022 (day of measurement). HA Movement Drill was
carried out, and the total time to move to Node 2 was measured as less than 5 mins.
Measurement since April 7th till date: Total Uptime = 372 h, Total time = 372 h
Application Availability = Total Uptime/Total Time * 100 = 100% Availability.

Table 4. Pre migration performance indicators and values

Area Indicators Value

System Performance Active users (>400 steps) 455
System Performance Avg. Availability per week 100%
System Performance Avg. Response Time in Dialog Task 1442 ms
System Performance Max. Dialog Steps per Hour 31114
System Performance Avg. Response Time at Peak Dialog Hour 1298 ms
System Performance Avg. Response Time in RFC Task 2162 ms
System Performance Max. Number of RFCs per Hour 52712
System Performance Avg. RFC Response Time at Peak Hour 2602 ms
Hardware Capacity Max. CPU Utilization on DB Server 64%
Hardware Capacity Max. CPU Utilization on Appl. Server 25%
Database Performance Avg. DB Request Time in Dialog Task 1136 ms
Database Performance Avg. DB Request Time for RFC 496 ms
Database Performance Avg. DB Request Time in Update Task 92 ms
Database Space Management DB Size 8449.04 GB
Database Space Management DB Growth Last Month 206.44 GB

Analysis of Response Time Post Migration

Table 4 and Table 5 show the migration analysis performed by SAP AG (Pre and
Post migration). The report shows a 33% reduction in Dialog response time and
a 40% improvement in response time during peak hours. Furthermore, when
we extrapolate the data for 21 days, we see the dialog response shows a 41%
reduction as indicated in Table 3. We see this response pattern in almost all the
migrations done using the same road map and architectural pattern.
 Stability and Availability Optimization of Distributed ERP Systems 353

Table 5. Post migration performance indicators and values

Area Indicators Value Trend

System Performance Active users (>400 steps) 466 −→
System Performance Avg. Availability per week 100% −→
System Performance Avg. Response Time in Dialog Task 957 ms −→
System Performance Max. Dialog Steps per Hour 27602 −→
System Performance Avg. Response Time at Peak Dialog Hour 777 ms −→
System Performance Avg. Response Time in RFC Task 2412 ms −→
System Performance Max. Number of RFCs per Hour 51183 −→
System Performance Avg. RFC Response Time at Peak Hour 1086 ms −→
Hardware Capacity Max. CPU Utilization on Appl. Server 28% −→
Database Performance Avg. DB Request Time in Dialog Task 472 ms −→
Database Performance Avg. DB Request Time for RFC 432 ms −→
Database Performance Avg. DB Request Time in Update Task 47 ms −→
Database Space Management DB Size 8703.88 GB −→
Database Space Management DB Growth Last Month 224.84 GB −→

3 Conclusion

The proposed method to migrate workloads from different regions has consis-
tently resulted in sustained stability and availability of the ERP system, showing
significant improvement in the application performance. These migrations were
of a “Life and shift” nature, but the underlying principles can be applied across
any migration of productive workload to the cloud. Gartner Says More Than
Half of Enterprise IT Spending in Key Market Segments Will Shift to the cloud
by 2025, which translates to a significant workload moving to the cloud in the
coming years. The lessons learned and the proposed method can serve as a start-
ing point to make the project, investment, and technical decisions for companies
venturing into moving their productive workload to the cloud.

Acknowledgement. This dissertation was carried out as part of requirement for

Mtech (Software Systems) program under Work integrated learning program (WILP)
in BITS Pilani, I would like to thank my reporting manager Xavier Deprat (Head of
Global SAP operations, Schneider Electric) for his tremendous support throughout the
process.

References
1. A Forrester Total Economic Impact™ study commissioned by Amazon. https://
pages.awscloud.com/Amazon Connect Forrester TEI Report.html. Accessed 06
Jan 2023
2. Subramanian, S.: Whither Goest Thou, Enterprise Workloads? IDC (2020).
https://blogs.idc.com/2020/03/02/whither-goest-thou-enterprise-workloads/.
Accessed 04 Jan 2022
354 G. C. Aloysius et al.

3. Upadrista, V.: Formula 4.0 for Digital Transformation: A Business-Driven Digital

Transformation Framework for Industry 4.0. CRC Press (2021)
4. Khajeh-Hosseini, A., Greenwood, D., Smith, J.W., Sommerville, I.: The cloud
adoption toolkit: supporting cloud adoption decisions in the enterprise. Softw.
Pract. Experience 42(4), 447–465 (2012)
5. Lin, M., Wierman, A., Andrew, L.L., Thereska, E.: Dynamic right-sizing for power-
proportional data centers. IEEE/ACM Trans. Netw. 21(5), 1378–1391 (2012)
6. Shen, D., et al.: Stochastic modeling of dynamic right-sizing for energy-efficiency
in cloud data centers. Futur. Gener. Comput. Syst. 48, 82–95 (2015)
7. Tang, L., Dong, J., Zhao, Y., Zhang, L.J.: Enterprise cloud service architecture. In:
2010 IEEE 3rd International Conference on Cloud Computing, pp. 27–34. IEEE
(2010)
8. Morgan, N., Jarkowski, B.: SAP on Azure Implementation Guide: Move Your
Business Data to the Cloud. Packt Publishing (2020). https://books.google.co.
in/books?id=OAdYzQEACAAJ
9. Gastermann, B., Stopper, M., Kossik, A., Katalinic, B.: Secure implementation
of an on-premises cloud storage service for small and medium-sized enterprises.
Procedia Eng. 100, 574–583 (2015)
10. Rashid, A., Chaturvedi, A.: Cloud computing characteristics and services: a brief
review. Int. J. Comput. Sci. Eng. 7(2), 421–426 (2019)
11. AWS Whitepaper: Right Size Before Migrating. https://docs.aws.amazon.com/w
hitepapers/latest/cost-optimization-right-sizing/right-size-before-migrating.html.
Accessed 07 Jan 2022
12. AWS General SAP guide: Single Region architecture patterns. https://docs.aws.am
azon.com/sap/latest/general/arch-guide-single-region-architecture-patterns.html.
Accessed 06 Apr 2022