This blog was co-written with Dominik Herzig, VP of Delivery for US & Canada at oXya, and Melchior du Boullay, Managing Director, Americas, at oXya.
Our previous blog in the Outsourcing SAP series focused on the Planning Phase of moving your SAP environment to oXya’s datacenter. That blog was the 4th in our “Outsourcing SAP” series, covering various aspects of outsourcing your SAP environment. In the first blog, we asked should we outsource our SAP environment, and suggested a few directions to think about. In the 2nd blog we wrote about choosing the right partner that would manage our SAP environment, and listed various criteria and tips for choosing that partner. The 3rd blog discussed various infrastructure and headcount considerations that each and every customer has, when considering whether and how to outsource their SAP.
Today we present the second part dealing with moving your SAP landscape to oXya’s management. Last week we wrote about the Planning Phase, and this time we focus on the Technical Operations Phase.
As a reminder, when providing managed services for our customers’ SAP landscape, oXya has two high-level types of offerings:
- Run Management only: oXya provides only the managed services portion, while customer chooses to maintain responsibility for their hardware and for hosting SAP. In this case, oXya requires a quick and reliable link between oXya and the customer’s datacenter, to provide the support services. We covered that option in previous blogs in this “Outsourcing SAP” series.
- Full Cloud Delivered service: oXya takes full ownership and responsibility for the customer’s infrastructure and hosting, and the infrastructure is installed at one of oXya’s datacenters.
This blog and the previous one, about the two phases of moving your SAP landscape to oXya datacenter, focus on the second option—the process of moving your datacenter and infrastructure to the oXya private cloud. The blog is based on past experience with multiple North American customers, where we’ve migrated these customers’ full SAP landscape, plus all of their servers (including non-SAP servers), to the oXya cloud.
The previous blog ended with oXya and the customer finishing the Planning Phase, we had all the necessary workshops and coordination done with the customer, the hardware was prepped, and everything is ready for actual transfer of the servers. This is where the Technical Operations phase begins. This phase includes the actual transfer, dry runs, and all actions until we go live, and oXya accepts full responsibility over all systems.
At this point, it’s important to note that there are differences between migrating SAP servers and migrating non-SAP servers (which oXya also runs for its customers).
Migrating SAP Servers
This is our main expertise, we’ve been performing SAP migrations and hosting for hundreds of enterprise customers over many years. There are several migration options; the specific process depends on the customer’s sensitivity to downtime – some customers are OK with having their SAP servers down over a weekend, while others are extremely sensitive to downtime, and need it minimized. Generally speaking, and this is true for any type of migration (both SAP and non-SAP systems) – every time you want to minimize the downtime, there’s a tradeoff to be had, a balance of pros and cons.
Whichever process is chosen, there are some common operations for any SAP system. We will:
- Begin with Development & Quality, make sure the process completes smoothly, from start to finish.
- Then we execute a dry run and test the process for the Production environment, get validation from the customer that everything works fine and all the data is there, and they can access and perform basic operations.
- If customer is happy with the dry run, we can perform the actual systems migration and Go Live on the following weekend.
- We will then finish with a test, to validate that everything is OK and everyone can do their job.
If the customer is not happy with the dry run (step 2), then we’ll do the necessary modifications, perform another dry run to validate that this time everything is OK, and perform the Go Live migration afterwards.
The way we actually migrate each SAP system depends on the criticality and sensitivity to downtime of the specific customer. I’ll list them from the most standard process, that of a customer who is the least sensitive to downtime and can afford taking the systems down over a weekend; and ending up with the most sensitive customer, who needs the systems to be down for the shortest time possible.
If the customer is ok with having 2-3 days of downtime over the weekend, there are two methods that can be used. The difference for using which one to use, depends on whether we want to change the operating system and/or database during the migration, or we continue to use the same OS and database as in the original customer SAP system:
- Systems Copy. This method supports changing the OS and/or DB as part of the migration process, so the OS and/or DB on the new oXya systems are different from what customer runs before the migration. Systems Copy is done via export and import, using SAP’s “R3Load” tool. The result will be the customer’s SAP system, is running on a different OS and/or database
- Backup. If we’re not changing the OS and database, we can build an entirely new system on the oXya side, with the same OS and database, take a backup on the customer side, and ship the backup to oXya. Then, at the oXya datacenter, we’ll apply that backup to the blank SAP setup we prepared, and start the system from the backup. The result will be an exact copy of what the customer has at their datacenter.
The above methods are the simplest approaches to a SAP migration, given that the system can be shut down for several days. However, if you need to perform the migration with minimal downtime, there’s one method that trumps all others – the DR method.
Disaster Recovery-like mechanism. If downtime is really an issue, the easiest method is to use a DRP-like mechanism for SAP. We will set up an SAP system at our datacenter, which is an exact replica of the customer’s system (same hardware, OS and DB), and configure it as a DRP (asynchronous) of the customer’s existing SAP system. This method enables us to shorten the downtime to a very short time period (half an hour, if everything goes well), of switching from the primary system (customer’s datacenter) to the DR system (oXya datacenter). We will still follow the common procedure described earlier – first do a dry run and a test with customer’s users to validate everything, make any necessary corrections, and then perform the real migration.
The dry run is done over one weekend. We will simulate the exact same system as the customer’s primary system. If successful, we will repeat the process on the following weekend. The purpose of the dry run is to make sure the process works, and everyone can validate and test the new system.
Once the dry run is finished we will shut it down, bring back the primary system on the customer’s side, rebuild the DR system on oXya’s side during the week, and repeat the operation on the following weekend, for the Go Live. This process significantly reduces downtime, to almost nothing (in a nutshell, the dry run is exactly the same operation as doing a DR test, and the Go Live is the same operation as switching to a DR system in a real crisis situation).
The main thing to remember regarding a DR-like mechanism – the new SAP system, in the oXya datacenter, must be the same (hardware, OS and database) as the current system on the customer side. The DR method only works if you’re not changing your SAP landscape (i.e. keeping the same DB/OS platform and SAP application versions, etc.).
What if you need to change the system?
We mentioned the DR method doesn’t work if you want to change either the hardware, OS or DB between the current customer system, and the new system at the oXya datacenter. If you want to perform such a change, there are two options:
- We first switch to an identical system at oXya (using the DR method), and later switch components in the system (OS, DB, etc.).
- We use the first method mentioned, Systems Copy, to perform an export/import, in which case the OS and database can be changed. However, this approach requires a longer downtime (you cannot configure the new system as a DR).
The bottom line: if you want to change your landscape—hardware, OS or DB—there’s no going around a longer downtime period, typically a weekend. What can be done, to minimize the risk of “all at once”, is to perform the migration in two steps: first migrate the system “as is” to oXya using DR, and then perform the OS or DB migration over another weekend. However, it doesn’t matter whether you’re moving from the customer datacenter to the oXya datacenter, or you do the change within oXya’s datacenter – whenever you change your landscape, you’ll need a longer downtime.
Migrating non-SAP Servers
As already mentioned, we have many customers for which oXya manages their entire IT infrastructure, not just their SAP systems. With regards to migrating non-SAP servers, it depends on the type of the system.
There are essentially 3 types of other systems:
- Systems virtualized using VMware. If the customer already has a system virtualized using VMware, we will use one of the following two methods:
- Migrate the VMs to oXya using the VM container (this option is when customer already has SAP virtualized with VMware, and the system stays with the exact same server names, VLAN, IP addresses, etc. – no change as part of the transfer).
- Export of the VMs and ship them to oXya (this option is the SAP system is already virtualized, but the move to oXya involves some type of transformation/change within the VMware system, such as changing the host name, or an IP address). If the system is small enough, we can ship it over the network; if too big, we will put it on a fast disk and fly it over to the oXya datacenter.
- If a very short downtime is required, there’s a 3rd method when migrating VMware-based systems, using a tool such as Veeam Backup & Replication. This tool creates a backup, moves it to oXya, and keeps it in sync with the original/customer system, using the Veeam tool. This allows us to “bypass” the transfer time to oXya, significantly shortening downtime. This method obviously has a cost.
- Systems virtualized with a different hypervisor. The second type of migration is for servers that are virtualized, but not using VMware (for example, with Hyper-V). At oXya, we typically use VMware, though there are some exceptions. If the customer’s servers are virtualized using Hyper-V, and oXya servers are typically virtualized with VMware, then we will perform a Virtual to Virtual (V2V) migration, using the VMware vCenter Converter tool.
- Non-virtualized systems. The last type of servers are physical servers. If the customer has these, there are two options:
- If the server can be virtualized, we’ll perform a Physical to Virtualized (P2V) migration using the VMware converter, and ship the newly created VMware container to oXya.
- Some servers cannot be virtualized. If this is the case, then the situation is a bit trickier, and requires a conversation with the customer about what to do with this server. There are a few solutions:
- Sometimes the application needs to be upgraded, in order to be compatible with VMware. This is seemingly the easiest solution, but it’s not always possible.
- Another seemingly easy solution is to physically move the server to the oXya datacenter. However, it’s often not as easy as it sounds. The downside to physically moving a server is that it takes time, both planning and the transfer itself, plus there are inherent risks involved. Timing wise, we will use a specialized moving company that does these things—take the server from the customer’s datacenter, put it in a truck, and move it to the oXya datacenter. Once we receive it at the oXya datacenter we will install it, and bring it back up. The risk is that whenever you physically move a server like that, some components may break, or the server will not start after the move, and that kind of things.
- If physically moving the server is not an option, then we need to get a bit creative. IT all depends on the specific application, the reason why it cannot be virtualized, and what the customer wants to do with that application. These are the type of discussions we hold with the customer, when we face the case of a server which is physical, and can’t be virtualized. When migrating a customer’s entire IT infrastructure to the oXya cloud, these servers are the most complicated to handle.
What has been your experience, regarding SAP landscape migrations?
Did you experience any difficulties and issues? Where exactly?
How sensitive to planned downtime is your organization?
What do you think about this entire topic?
Our last blog in the “Outsourcing SAP” series, to be published in 1-2 weeks, will be a Q&A, based on questions we receive from customers, on all the topics covered in this blog series. Send us questions about any aspect of “Outsourcing SAP”, either by posting them to the Comments below, or sending them directly to us, Sevag Mekhsian <firstname.lastname@example.org>, Dominik Herzig <email@example.com> or Melchior du Boullay <firstname.lastname@example.org>.
Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group Company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of team of ten SAP professionals, at oXya’s service center in New Jersey.
Dominik Herzig is VP of Delivery for US & Canada at oXya. Dominik has 10 years of SAP experience, starting as a Basis Admin, and then moving to SAP project management and to account management. Dominik was one of the first few people to open oXya’s US offices back in 2007.
Melchior du Boullay is Managing Director, Americas at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.
oXya, a Hitachi Group Company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~600 SAP experts, who service more than 260 enterprise customers with more than 250,000 SAP users around the world.