Cloud Computing | SAP

SAP Heterogeneous Migration

  1. Home
  2. >
  3. Blog
  4. >
  5. SAP Heterogeneous Migration

Migrating SAP Systems to AWS

Homogeneous SAP migrations

(in the operating system and database remain the same):

•  Physical-to-virtual migrations: tools to help organizations shift from on-premises physical hardware to AWS.

• Virtual-to-virtual migrations: solutions to help companies migrate from virtualized on-premises infrastructures to AWS.

• Server migration service (SMS) that enables companies running VMware-based environments to replicate their environments directly into AWS.

Heterogeneous migration

(in which the operating system or database changes):

  • SAP heterogeneous system copy, potentially with options that minimize downtime, such as SAP NZDT or Shareplex.

AWS Server Migration Service (AWS SMS)

SAP Database Migration Option for migrations to SAP HANA and Sybase. AWS Server Migration Service (AWS SMS) is an agentless service that migrates your on-premises VMware vSphere or Microsoft Hyper-V virtual machines to the AWS Cloud. In this blog post, I’ll discuss some of the main benefits of AWS SMS and explain how you can use this service to migrate your virtualized, on-premises (or private cloud) SAP workloads to Amazon Elastic Compute Cloud (Amazon EC2) instances on the AWS Cloud.

Here are some of the keys benefits of using AWS SMS:

Simplified migration: After you configure the source environment, you can migrate your virtual machines easily by scheduling replication jobs in the AWS Management Console. Replication to Amazon Machine Image (AMI) creation is a four-stage process that’s handled automatically when the replication job is executed.

Incremental migration: AWS SMS can replicate a live environment incrementally, which can speed up the migration process significantly. You can continue to run your production environment while it’s being replicated to the AWS Cloud.

Minimized downtime: There is no impact on production operations during incremental replication. However, final replication (cutover) does require downtime.

• Parallel migration: With AWS SMS, you can migrate multiple virtual machines in parallel. With this capability, you can migrate your complete landscape (for example, migrate all your development systems at one time, and then quality assurance systems, and so on).

System Copy and Migration

 A system copy can be either Homogeneous or Heterogeneous

Heterogeneous System Copy

One of the following is changed during the system copy

• Operating System (In this case, system copy is called OS migration)

• Database system  (In this case, system copy is called DB migration)

• Operating system and database system (in this case, system copy is called OS/DB migration)

The real value of migrating to the cloud is not the “lift and shift” aspect. Moving to AWS makes it easier and faster to augment and enhance SAP environments with new technology innovation.

Database Migration Key Concepts

One of the key reasons businesses choose AWS for SAP is because it offers a complete cloud environment for business innovations. The fact that SAP and AWS have been working together since 2011 means that businesses have access to a set of solutions that have been honed over the years to anticipate and solve real customers needs around application performance and agility. So we have:

• A range of Amazon EC2 instances optimized for specific SAP workload needs. One of these is X1, which has been purpose-built with Intel® Xeon® E7 processors. It meets the strict performance requirements for in-memory databases such as SAP HANA and other big data and enterprise workloads.

• Pre-built system images are available on AWS for certain SAP solutions, allowing businesses to deploy a ready-to-go, preconfigured SAP system in a matter of minutes.

• Dedicated SAP customer support for businesses running SAP on AWS.

Up-gradation

Organizations deem it fruitful to move the large amounts of data stored in legacy systems to newer and more reliable current systems. This may be done to make use of the advanced features and functionalities that current systems offer. Further, legacy systems are continually on the decline and moving to contemporary systems make sense when seen in terms of service support, use of latest technology etc.

Total Cost of Ownership (TCO)

Because legacy systems require experienced DBAs and Application Developer, the total cost incurred is high. Therefore to bring down the cost, organizations move on to a single contemporary system with greater functionalities and low total cost of ownership (TCO).

Technology

One of the major reasons for organizations to decide to migrate is to capitalize on the latest technology. There is always a risk with legacy systems that vendors may withdraw its support and make the system obsolete. This motivates organizations to move to new suitable systems. Another motivation could be business demand. The business may expand beyond the capabilities of the current system forcing the need to move to a new system. For example, a leading insurance company used a character-based application driven by an 8-year-old Informix database. The business demands changed and they decided to opt for an e-business and ERP integration, with a single vendor providing for all the requirements. To exploit the extant technology and its capabilities, the organization migrated from the Oracle 8i to SAP S/4 HANA

Database Unification

It is most often the case that organizations have their data stored across multiple databases. Different applications run on different databases. But managing and tracking multiple databases is a logistical nightmare. Multiple licenses, multiple vendor support, source feed synchronizations etc. takes up the cost and effort many folds. Thus consolidating the data as far as possible makes sense. For example, an airline company had its data and corresponding applications running on 9 different databases. When running costs and data management came into question, they decided to migrate their data and applications to just two database platforms.

Conclusion

Database migration cannot be overlooked as a simple step of retiring an existing platform and moving on to a new one. It is a complex process with many phases and every migration process is unique. This makes it prone to failures. Thorough knowledge of what is required out of the migration, proper migration design and predicting the possible issues that might come up during the migration can bring down the chances of failures drastically.

 

This website stores cookie on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy. If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference not to be tracked.