Skip to main content

SAP system migration blog series - part 1: migration overview



Summary:


This blog is part 1 of the blog series on SAP system migration. In this blog, we will provide overview about SAP migration, types of migration, their differences and usage scenario.


SAP migration overview: 


As the Greek philosopher, Heraclitus, said: “change is the only constant.” Same goes within SAP world too, often customer have to change the SAP systems along with its underlying components to meet the changing requirements, be it change from old hardware to new one, changing operating system, database. This change in SAP system components (DB, OS or Hardware) is termed as migration.


Before we go into details of migration, let’s understand architecture of a typical SAP system. 


An SAP system consist of SAP application instances, running on database (DB), hosted on operating system (OS), provisioned on hardware. Change in any one or more of these underlying components (DB, OS or hardware) warrant us to perform migration.



Types of migration: 

Broadly, there are two types of migration: Homogenous migration and Heterogenous migration


1. Homogenous migration: When an SAP system is moved to new hardware of similar architecture while keeping the underlying operation system and database same as source SAP system. 

Homogenous migration is often referred as AS-IS migration because we keep the target system configuration same as source system.




Important points to note: 

    • As rule of thumb, if SAP kernel type is not changing on the target system, then this type of migration falls under homogenous migration.
    • In homogenous migration, OS and Database type remains same in source and target system; however, their version may differ. For example, 
      • Source and target database is HANA but source is on HANA1.0 and target on HANA 2.0.
      • Source and target OS is SUSE Linux, but target OS SUSE version is higher.
      • Source OS version: Windows 2008, target OS version: Windows 2012 R2.
    • Change OS from SUSE Linux x86_64 to RedHat Linux x86_64 (or vice versa) is considered as homogenous migration as both are Linux based.
    • Hardware architecture of source and target server must be same. Thus, homogeneous migration is only possible with the following operating system platforms:

                                            Table 1: Source hardware type vs target in homogenous migration

                 Note: Endianness means the order in which a sequence of bytes is stored in the                                                         computer memory. For more information, see SAP Note 552464.

    • For homogenous migration, DB dependent method (backup/restore, HANA system replication in case of HANA DB, etc.…) or DB independent method (export/import) can be used. We will discuss homogenous migration in detail in upcoming blog.


Examples of homogenous migration: 


    • Shift from on-premises physical hardware or virtual infrastructure to virtualised environment on cloud or another datacenter but keeping OS, DB same.
    • Migrating system from old hardware (e.g., HP RX2800) which is not supported for S/4 HANA to new hardware (e.g., Superdome Flex 280) supported by S/4HANA
    • Conversion from on-premise ECC on HANA to S/4HANA cloud.
    • HANA Migration from scale-up server to scale-out server
    • Migration of SAP HANA from an existing AWS EC2 instance to an EC2 High Memory instance. Similar migration in other cloud providers like Azure and GCP.

2. Heterogenous migration: When an SAP system is moved to new hardware of similar or different architecture while changing either operating system or database or both.

Heterogenous migration is often referred as OS/DB migration.

 



                                                                    *Target has OS/DB/Hardware different than source


Important points to note: 


    • As rule of thumb, if SAP kernel type has to be changed on the target system, then this type of migration falls under heterogenous migration.
    • Hardware architecture of source or target can be different. For any combination other than table 1 shown in homogenous migration section, heterogenous migration is mandatory.
    • For Heterogeneous migration, DB independent method (export/import) is necessary. Also, migration key must be entered into the migration tool. Each OS/DB Migration requires its own key. It is assigned on the basis of the installation number and additional system-specific information. We will discuss heterogenous migration in detail in upcoming blog.

Examples of heterogenous migration: 


    • Change DB from HANA to anyDB (or vice versa)
    • Change OS from AIX to HP-UX or Solaris (or vice versa)
    • Change OS from Unix to Linux (or vice versa)
    • Change OS from Windows to Linux (or vice versa)
    • Change OS/DB from Windows/MSSQL to Linux/ASE (or vice versa)
    • Change from SAP HANA Big Endian to Little Endian (or vice versa).
    • The processor on the target host and source host does NOT use the same byte sorting.                        (little endian -> big endian; big endian -> little endian) like Intel-based to IBM Power Systems (Big-Endian) or vice versa.


Interesting trivia: 


Words- System ‘copy’ and ‘migration’ are often interchangeably used in SAP world. SAP uses mostly the word ‘copy’ (be it ‘homogenous system copy’ or heterogenous system copy’) and terms ‘Heterogeneous system copy’ as synonym for migration.


However, there is slight difference between system copy and migration: 


System copy:  It’s a process where you are copying an existing SAP system to another system which is either already there (like copy production system to quality system, often called system refresh) or copy into a new system like creating test, demo or training system or do homogenous migration to new hardware.


In short, system copy = system refresh/new system build using copy of source/homogenous migration



System migration: It’s a process of moving an existing SAP system to new host for example, moving on-premise SAP system to cloud infrastructure or any other datacenter, moving SAP system from old hardware, OS, database to new ones. 


In short, system migration = homogenous migration/heterogenous migration



Conclusion: 


Hope you have got the clear idea about SAP migration and its type. In the part2 of this blog series, we will talk in detail about homogenous migration, its various migration patterns, pros and cons, usage scenarios and tools to be used.


References and links for further study: 


    • System Copy Guide:
                  https://support.sap.com/en/tools/software-logistics-tools.html
                  ->System Provisioning
                  ->System Copy Option of Software Provisioning Manager


Comments

  1. I generally check this kind of article and I found your article which is related to my interest. Genuinely it is good and instructive information. Thankful to you for sharing an article like this. How to start Educational Migration.

    ReplyDelete
  2. Excellent blog post! Keep sharing this type of post Thank you very much for this one. custom erp development

    ReplyDelete

Post a Comment

You might find these interesting

Notes for Build Resilient Applications on SAP BTP with Amazon Web Services [ Week 1]

Welcome back to the next chapter in our ongoing series dedicated to unraveling the dynamic interplay between SAP Business Technology Platform (BTP) and Amazon Web Services (AWS). For those just joining us, this blog serves as an invaluable resource for individuals delving into the world of SAP BTP or seeking a comprehensive reference guide. SAP BTP, or SAP Business Technology Platform, is a comprehensive platform that brings together various essential capabilities for application development, automation, data management, analytics, planning, integration, and AI. These features are all integrated into a unified environment, making it user-friendly for both professional IT developers and citizen developers. Image Credit  Key Features of SAP BTP: Application Development: SAP BTP offers a range of tools for development. For instance, SAP Build enables low-code development, while the SAP Business Application Studio caters to core developers, providing services like document management a...

8 Must-Know Questions About Object Store on SAP Business Technology Platform

What is the problem that Object Store solves ? Modern enterprise systems increasingly deal with massive volumes of unstructured data such as documents, logs, media files, and backups. Traditional relational databases are not optimized for such workloads. What is Object Store ? Object storage—commonly referred to as blob storage—addresses this gap by providing scalable, durable, and cost-efficient storage for unstructured data. Object storage is a storage architecture designed to manage unstructured data as discrete units called objects.  Each object consists of: Binary data (file content) : Image , File etc Metadata (descriptive attributes) : File size, Content type, Last modified timestamp, Storage class (hot, cool, archive) Unique identifier (key or URL) : unique path-like string used to locate a blob inside a bucket Unlike file systems or relational databases, object storage does not rely on hierarchical file structures or schemas. The SAP BTP Object Store service is a managed, ...

Understanding SAP BTP Global Accounts, Directories, Subaccounts, and Entitlements

In SAP Business Technology Platform (BTP), organizing your resources effectively is crucial for efficient management and scalability. This blog provides a comprehensive overview of global accounts, directories, subaccounts, and entitlements within SAP BTP. What is a Global Account in SAP BTP? A global account in SAP BTP represents the contractual agreement you have with SAP. It serves as the top-level container for managing various resources, including directories, subaccounts, members, entitlements, and quotas. Within a global account, you receive entitlements and quotas for platform resources, which can be allocated to subaccounts for actual consumption. How Do Directories Function in SAP BTP? Directories in SAP BTP allow you to organize and manage your subaccounts based on your technical and business requirements. A directory can contain other directories and subaccounts, enabling you to create a hierarchical structure. This hierarchy can be up to 7 levels deep, with the global ac...

How to properly Start/Stop SAP system through command line ?

Starting/stopping an SAP system is not a critical task, but the method that most of us follow to achieve this is sometimes wrong. A common mistake that most of the SAP admins do is, making use of the 'startsap' and 'stopsap' commands for starting/stopping the system.  These commands got deprecated in 2015 because the scripts were not being maintained anymore and SAP recommends not to use them as many people have faced errors while executing those scripts. For more info and the bugs in scripts, you can check the sap note 809477.  These scripts are not available in kernel version 7.73 and later. So if these are not the correct commands, then how to start/stop the sap system?  In this post, we will see how to do it in the correct way. SAP SYSTEM VS INSTANCE In SAP, an instance is a group of resources such as memory, work processes and so on, usually in support of a single application server or database server with...

KPIs for Recovery in HANA Database Administration

Introduction: In the dynamic landscape of database administration, ensuring the robustness of a system is paramount. One crucial aspect that demands meticulous attention is the recovery process following a system failure. Two key performance indicators (KPIs) stand out in this realm – Recovery Point Objective (RPO) and Recovery Time Objective (RTO) . In this technical blog, we will delve into the significance of these KPIs for HANA database administrators and explore strategies to optimize them. Recovery Point Objective (RPO): RPO is a critical metric that defines the maximum acceptable data loss in the event of a system failure . For HANA database administrators, establishing an RPO involves a careful balance between data consistency and the overhead of continuous data replication. Continuous Data Backups: To meet stringent RPO requirements, implementing continuous data backups is imperative. Utilizing HANA's native backup capabilities and integrating them with a robust backup s...

Huge Multiversion Concurrency Control (MVCC) Versions in HANA

What is MVCC? MVCC is a database concurrency control method that allows multiple transactions to occur concurrently without conflicting with each other. In a nutshell, it ensures that each transaction sees a snapshot of the database at a specific point in time, even if other transactions are making changes concurrently. MVCC in SAP HANA: SAP HANA uses MVCC to manage concurrent access to data. Each transaction in HANA sees a consistent snapshot of the data at the time the transaction began. This is achieved by maintaining multiple versions of a data row, each associated with a specific transaction or point in time. The Issue of Huge MVCC Versions: Now, the term "Huge MVCC Versions" indicates a situation where there is a significant number of these versions for a particular set of data. Here's why this might become a problem: Increased Memory Usage: Each version of a data row consumes memory. As the number of versions increases, the overall memory consumption by the databas...

Execute HANASitter for hang situation analysis

The SAP HANAsitter is configured to perform default checks once every hour to ascertain the online and primary status of SAP HANA. Upon confirmation, it initiates tracking procedures, which involve regular responsiveness assessments (typically every minute). If SAP HANA becomes unresponsive, the HANAsitter commences recording activities, potentially capturing call stacks of active threads, run-time dumps, index server gstacks, and/or kernel profiler traces, although, by default, no recording occurs. When SAP HANA is responsive, the script scrutinizes critical features, including a standard check for more than 30 active threads. If this threshold is exceeded, the script triggers recording. Upon completing the recording process, the script exits, with an option to be configured for restart using the command line. Setup Steps Overview: Begin by creating an SAP HANA user with the desired name (e.g., HANASITTER) and assign the CATALOG READ privilege to it. Establish a user key in the hdbuse...

Deploying SAP on Google Cloud : Part 1

 Connect to Google  Connection Method To be Used for Speed Explanation Example Uses Cloud VPN Proof of Concept Variable, up to 3 Gbps Connects on-premises network to Google Cloud securely over the internet using IPsec VPN tunnels. Creating a Cloud VPN tunnel between on-premises and Google Cloud. Encrypted IPsec tunnels Dedicated Interconnect For Enterprise level connect 10 Gbps to 100 Gbps Provides a dedicated, private connection between on-premises and Google Cloud through Google's network. Provisioning a dedicated interconnect connection. Direct physical connection between on-premises and Google Cloud network infrastructure Partner Connect If you have a data center which cannot be reached to Dedicated Google facility. Variable, up to 100 Gbps Allows connecting to Google Cloud through supported service providers. Establishing a connection with a supported service provider. Utilizes service provider's network infrastructure. Configure Tunnels with Google Cloud Platform IPsec

Building the Foundation of the PO System: Architecture and some terminologies

1. Loosely Coupled and Tightly Coupled Services : Loosely Coupled Services : These services interact with each other with minimal dependencies. Changes in one service don't significantly impact others. Pros include flexibility, easier updates, and better scalability. A common example in PO is when a shipping service communicates with an inventory service. Changes in the inventory service won't necessarily disrupt shipping. Tightly Coupled Services : These services are interdependent, so changes in one service can affect others. While they might provide faster communication, they can be less flexible and harder to maintain. For example, tightly coupling an order processing service with a payment service means any change in payment could ripple to order processing. 2. SOA - Service-Oriented Architecture : SOA is an architectural approach where everything is treated as a service, encapsulating specific functionality. Service Orchestration Example (Banking Transaction) : Consider ...

Work Process and Memory Management in SAP

Let’s talk about the entire concepts that are related to memory when we talk about SAP Application. Starting with few basic terminologies, Local Memory :  Local process memory, the operating system keeps the two allocation steps transparent. The operating system does the other tasks, such as reserving physical memory, loading and unloading virtual memory into and out of the main memory. Shared Memory :  If several processes are to access the same memory area, the two allocation steps are not transparent. One object is created that represents the physical memory and can be used by various processes. The processes can map the object fully or partially into the address space. The way this is done varies from platform to platform. Memory mapped files, unnamed mapped files, and shared memory are used.  Extended Memory : SAP extended memory is the core of the SAP memory management system. Each SAP work process has a part reserved in its virtual address space for extended memory...