Skip navigation

This blog was co-written with Melchior du Boullay, Managing Director, Americas, at oXya.

 

------------------------------

 

This is the sixth and last blog in our “Outsourcing SAP” series. It focuses on questions we received regarding all the blogs in this series, as well as a few recurring questions we hear from almost every customer and prospect.

 

Our previous two blogs in the Outsourcing SAP series focused on the Planning Phase of moving your SAP environment to oXya’s datacenter, and the Technical Operations Phase of this move. Previous blogs in this series covered various aspects of outsourcing your SAP environment. In the first blog of the series, 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.

 

------------------------------

 

Questions and Answers

 

Does oXya require a minimum term length for its services?

At oXya, we don't believe in "vendor lock-in", and as such many of our services require just minimal term commitments from our customers (if at all). Often we require no more than 30 days' notice to terminate. Our industry-leading customer satisfaction ratings (> 98%) are the best testimony to the fact that our customers want us there, month after month.

 

Can I build a Private Cloud on my premises?

cloud-businessman-computer-laptop-sky-celebrate-happy (Custom) (2).jpgYes, absolutely. Many organizations, who have already invested heavily in existing datacenter facilities, want the benefits of the cloud (flexibility, resiliency, consumption-based pricing, self-service, automation, etc.) but with the peace of mind and efficiencies that come with using their existing, private floor space. At oXya we understand this and work with our customers to help build, deploy, and manage both on- and off-premises cloud solutions, based upon world class infrastructure, tools, and services.

 

Does oXya have both Private and Public Cloud options?

Yes, oXya/Hitachi can provide off-premises cloud solutions for both Private (dedicated compute, storage, LAN, and floor space) and Public (shared infrastructure, logically partitioned) options. Typically, customers with demanding production availability, performance, and security workload requirements choose the oXya private cloud model; and when short-term, cost-effective options are preferred (e.g. for a sandbox system) the oXya public cloud infrastructure is a perfect fit.

 

My team is currently working on a HANA migration project and we're under a tight timeline. How can oXya help?

Approximately 25% of the global oXya customer base has already or is currently implementing SAP HANA (from Suite on HANA, to S/4HANA, as well as custom developed applications), and over half of these customers have already gone live and are currently in Production.  The oXya delivery teams were key components of those projects. This means project management, as well as execution of numerous upgrades, migrations, and installations, plus the architecture, design, and hardware selection for the HANA landscape components, including DR solution planning and implementation. Let oXya safeguard your SAP HANA implementation, leveraging our significant experience and expertise to ensure a stable, well-designed and built platform, that will dramatically shorten your time-to-value.

 

Where are oXya support personnel and facilities located?

oXya has over 600 team members located in facilities across the US (NJ, CO, CA), Canada (Montreal, Toronto), Europe (France, UK, Belgium), and Asia (China, Japan). Additionally, 99% of oXya's delivery team members are full-time Hitachi/oXya employees (with few exceptions, we do not use sub-contractors). What this means in practice is that when you choose oXya to provide SAP Cloud and Managed Services for your landscapes, rest assured that your systems will be managed by in-country or near-shore resources (your choice) who will speak the correct language (natively) for your organization’s needs.  Unlike most other globally certified SAP service providers, we provide the right resources in the right countries, in the right time zones, speaking the right languages, based on your requirements.

 

Our organization has had some poor experiences in the past, with another SAP managed services company. What makes oXya different?

oXya2 (Custom) (2).jpgAt oXya, we understand what it's like for customers who have been mistreated by the large, offshore providers who's service is typically over-priced, inflexible, and poorly delivered. In fact, some significant percentage of our customers came from such a contract/provider!  (and they’d be happy to be a reference, and tell you about their experience at oXya, compared to their previous provider).

And now, let’s answer the direct question, about “what makes oXya different?” The oXya delivery model provides teams of named resources who are assigned to your account and dedicated to your satisfaction. By design, your assigned and dedicated team will:

  • Be located on/near shore and provide 24x7 support.
  • Be your primary point of contact for ALL platform performance and availability issues (we will coordinate and drive support with 3rd party vendors as required, so you don't have to).
  • provide you with their email addresses and cell phone numbers (so you can contact them directly when required; we do not have a call center – you call directly to your dedicated support team).
  • Work to understand your unique business processes and requirements.
  • Have in-depth knowledge of your systems and landscapes.
  • Have working knowledge of every layer of your platform stack (SAP Basis, Database, Operating System / VM, Compute/Storage Hardware, LAN).
  • Have access to a global team of oXya consulting experts (for level 3 and 4 issues which require an additional level of knowledge).
  • Work with you from migration to renewal (to ensure consistency).

 

AWS seems like a cheap and effective alternative. Why wouldn't we just use Amazon?

At oXya, we provide support for the entire SAP platform (from SAP Basis through the datacenter floor), not just Infrastructure-as-a-Service (IaaS). We have several current customers who began their SAP S/4HANA implementation with AWS and found, for a variety of reasons, that oXya provided measurably better monthly service costs, performance, and support of their SAP stack. Additionally, some of our customers are concerned that other providers simply can't provide the security and data privacy that their enterprise applications (and auditors!) demand.

 

Most hosting providers just source labor from offshore. We simply can't trust (or even know) who has access to my data, or when.

At oXya, with very few exceptions, ALL of our delivery personnel are full-time Hitachi employees, not sub-contractors. In addition, you can choose which oXya region and facility will deliver your services (for example, US customers can choose between teams and facilities located in NJ, CO, or CA).

 

How many SAP HANA customers do you have?

oXya has more than 330 SAP customers (and hundreds of thousands of SAP users), as of March 2016. More than 25% of our customer base are currently implementing SAP HANA; of these, more than 50% have already gone live.

 

How many SAP S/4HANA customers do you have?

oXya has over a dozen customers who are currently implementing SAP S/4HANA (several are now live), and many other customers who are currently investigating how/when/if to proceed with their own implementations, relying heavily on input from the oXya team members regarding various upgrade, migration, installation considerations and options. Obviously, S/4HANA is in its infancy, so adoption has been somewhat methodical and slow-paced to-date, as customers take their time to examine and evaluate their business cases. We expect to see a significant increase in customer S/4HANA projects through the remainder of 2016. One of the many benefits of becoming an oXya customer is the ability to collaborate and knowledge share with other customers (often with similar landscapes, projects, and implementation challenges).

 

 

------------------------------

 

This is our final blog in the “Outsourcing SAP” series. If you have additional questions that were not answered in the series, including in the current Q&A, please post them to the Comments below or send us an email, and we’ll answer your questions. If we get enough additional questions, we may post another Q&A blog in the future. Our emails are: Scott LaBouliere <SLaBouliere@oxya.com> or Melchior du Boullay <MduBoullay@oxya.com>.

 

------------------------------

Scott LaBouliere is VP Business Development at oXya, a Hitachi Group Company. As an SAP professional with more than 15 years of experience in the SAP market, Scott possesses in-depth knowledge and experience in architecting, selling, implementing, and managing Cloud-based solutions across the entire SAP application suite (SAP HANA, ERP, BW/BOBJ, SCM/APO/CRM, NetWeaver components, BPC, etc.) for a wide variety of industry verticals in the Large Enterprise and Mid-Market spaces – Pharmaceutical, Retail, Wholesale, CPG Manufacturing, Energy, High Technology. Scott came to oXya after nearly 7 years at FIT, where he served as the Chief Operating Officer. Prior to that, Scott was VP of Managed Services with SAP America, Inc.

 

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_HGC_logo.png

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 330 enterprise customers with hundreds of thousands SAP users around the world.

Over the last several months, ESG Research has been performing a research project on oXya’s managed services for SAP. We hired ESG—a reputable IT research firm—to validate our services and unique offerings, including a dedicated team that is assigned to each customer, and our ‘all inclusive’ offering for a fixed monthly fee.

 

The end result can be seen in the below brand new video, but it wasn’t a fast nor easy process to get there. For those who think “OK, oXya paid them so they’ll say anything asks them to”, my answer is – no, it doesn’t work this way. As a reliable research company, ESG won’t say anything we ask them to, just because oXya hired them. We needed to prove to ESG, every step of the way, that we indeed deliver everything we claim. In fact, it’s similar to how we needed to pass multiple tests by SAP Corp over the past year, in order to get SAP’s GLOBAL certifications for SAP HANA® Operations Services, Cloud Services, Hosting Services, and of course – an SAP Global Partner certification. We just recently received all these global certifications (we already had certain certifications for many years, but not globally), and are very proud of that. See our SAP certification logos in this blog and in the video.

 

(oops, not sure I’m supposed to talk about the certifications… I may have just revealed something that we planned to release next month, before SAPPHIRE Orlando, to attract more people to come visit us at the large and amazing Hitachi booth; marketing won’t be happy…)

 

 

Let me tell you a little about the “behind the scenes” that led to this video; we worked really hard to prove to ESG that oXya does deliver on what we claim.

 

SAP_GlobalPartner_grad_R.png

Nik Rouda, Senior Analyst with ESG Research, was skeptical about two main things:

  1. Personal Touch & Dedicated Team. Our commitment is to assign a dedicated team with all relevant expertise (Basis, DB, OS, HW, etc.) to each of our customers. This is what we’ve been doing since oXya was founded, back in 1998. Nik was especially skeptical about our ability to grow globally and continue with that approach. After all, none of our global competitors operates this way; when you call them with an issue, you get a different support person each time, from somewhere around the world; often they don’t know you nor your SAP systems, and your ticket circulates between various silo teams, until your issue was resolved. This kind of service significantly delays the time to resolution, and make customers unhappy (I wrote last month about the oXya unique delivery model, versus the standard model).
  2. ‘All Inclusive’ Service. Another thing that Nik was doubtful about is our commitment for an ‘all inclusive’ service for a fixed monthly fee. Many people believe this sounds insane from a financial perspective, and especially since we don’t suggest multiple change management ideas to customers, like many of our competitors do (and they also charge you and arm and a leg for that, of course). For oXya, having long-term customers who are happy and renew their service with us, time and time again, is worth all this. First, it’s our company values of Commitment, Trust, and Service that are driving us. But even more so, if you think of the acquisition cost for a new customer, or the cost of customer churn, you’ll understand why our approach also makes perfect sense from a financial perspective.

SAP_Certified_inSAPHANAOperations_Services_R.png

 

BTW, as part of the background work preparing for interviews with Nik, we wanted to learn what is our real customer churn, and how happy our customers are with oXya’s services. Here are the results:

  • As of this month, March 2016, oXya has ~335 enterprise customers around the world.
  • Over the last 5 years, oXya lost 2 customers who did not renew their services with us (yes, that’s not a mistake – just 2 customers in 5 years!). That’s a churn rate of 1% in five years!
    • One of these two customers, BTW, did not renew its service contract with us since they were acquired, and the acquiring company worked with a different SAP managed services provider. That loss of a customer felt bad, but it had nothing to do with our service, and there was nothing we could have done to keep that customer.

SAP_Certi_inCloudServices_R.png

 

Let’s back to the “behind the scenes” story. In order to prove our service commitments and claims, Nik asked to meet with our customers, and he did. He held long interviews with customers, and heard from them exactly what we tell the market and what every prospect hear from us – about our great and committed service, which includes a dedicated team that knows the customer very well and the customer knows all team members; the 'all inclusive' service and the fact that we don’t look for ways to overcharge our customers; and much more.

 

We also proved to Nik how, nearly a decade ago, oXya expanded its services beyond the EMEA market, and built successful service and hosting centers—with local teams—in Americas and APAC (our Americas operations will celebrate 10 years next year). Over the last year, since Hitachi acquired oXya, we’ve been expanding more rapidly, yet we are still passionate about maintaining our service levels, personal touch and dedicated team, which are what brought us thus far and have been the basis of our amazing success and happy customers.

SAP_Certi_HostingServices_R.png

 

At the end of the process, Nik acknowledged that we indeed managed to grow and expand significantly, on a global basis, while still maintaining our unique service offerings. Still, he was a bit hesitant and skeptical whether we will be able to continue growing at this fast pace, and still maintain the same type of services and levels of service. You can hear that in the video, when he talks about our future growth, and that’s understandable – he is an analyst, so he needs to be cautious.

 

For us at oXya, on the other hand, there’s no question that we’re moving forward exactly like we operated thus far, and that we’re not going to let anything harm or change our amazing service, not even continued fast growth. Customer satisfaction is in our core DNA, and we’ve proven that time and time again. We also have a unique, internal model for how we train new SAP experts and build our teams for fast growth, but that’s something for a different blog.

 

So enjoy this video, and I hope to see many of you at SAPPHIRE – stop by the Hitachi booth, look for the oXya team, and feel free to discuss your SAP challenges with us. You can also email me at any time, to mduboullay@oxya.com.

 

Yours,

 

Melchior du Boullay

Managing Director, Americas

oXya, a Hitachi Group Company

 

 

 

-------------------------

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 335 enterprise customers and hundreds of thousands of users around the world.

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.

 

----------------------------------------

Outsourcing SAP 4 - Planning Phase - screen shot (Custom).jpg

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:

  1. 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.
  2. 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

biz-people-data-center-140821-2379-high (Custom).jpg

 

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.

 

Weekend Downtime

 

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.

 

Minimal Downtime

 

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.

 

hourglass-620397 (Custom).jpg

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:

  1. We first switch to an identical system at oXya (using the DR method), and later switch components in the system (OS, DB, etc.).
  2. 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.

biz-people-data-center-140821-2982-high (Custom).jpg

There are essentially 3 types of other systems:

 

  1. Systems virtualized using VMware. If the customer already has a system virtualized using VMware, we will use one of the following two methods:
    1. 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).
    2. 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.
    3. 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.

  2. 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.

 

  1. Non-virtualized systems. The last type of servers are physical servers. If the customer has these, there are two options:
    1. 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.
    2. 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:
      1. 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.
      2. 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.
      3. 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 <smekhsian@oxya.com>,  Dominik Herzig <dherzig@oxya.com> or Melchior du Boullay <mduboullay@oxya.com>.

 

 

----------------------------------------

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.

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.

---------------

 

In previous blogs of this series we covered various aspects of outsourcing your SAP environment. We started by asking should we outsource our SAP environment, and suggested a few directions to think about. Then, in the 2nd blog, we dealt with choosing the right partner that would manage our SAP environment, and listed various criteria and tips for choosing that partner. In the 3rd blog, we discussed various infrastructure and headcount considerations that each and every customer has, when considering whether and how to outsource their SAP.

 

The next two blogs of this series focus on the entire process of moving your datacenter to oXya.

 

When providing managed services for our customers’ SAP landscape, oXya has two high-level types of offerings:

  1. 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.
  2. 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.

 

The next two blogs focus on the second option, and specifically on the full process of moving your datacenter and infrastructure to the oXya private cloud. These blogs are 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.

000045034298_high (Custom).jpg

The oXya migration process entails two main phases:

  1. Planning – covered in this blog
  2. Technical Operations – to be covered in next week’s blog

 

The project as a whole may seem a bit daunting, and like it’s going to take a lot of time, yet both impressions are untrue. Leveraging oXya’s processes and experience, our customers experience a well-defined and streamed process, which can be done relatively quickly.

 

How quickly?

 

For example, let’s take one of our customers, for which we’ve migrated their entire datacenter, consisting of ~100 servers (both SAP and non-SAP servers), to an oXya datacenter. The entire project, from the moment the contract was signed, and until the last server was moved and started running within the oXya datacenter, took 4 months (and BTW, there’s a difference in process between migrating SAP and non-SAP servers; we will cover these in next week’s blog).

 

While other vendors may try to sell you on a shorter cycle, or you may have business pressures which demand otherwise, remember that a timeframe of 4 months is considered extremely quick in the industry. Obviously, if the customer does not have extreme time constraints, then we can allow for more time and buffers within the process; still, if the customer requires that, oXya is able to make the entire transition very quickly.

 

Important First Steps

 

Timing is the first thing you think about, when starting such a project. Some things take a long time to order, so they need to be handled immediately upon signing the contract.

 

MPLS connection. Most customers prefer to have a fast and reliable internet connection (MPLS) between their location and the oXya datacenter; MPLS is a dedicated line, between these two locations. The challenge is that getting the MPLS connection in place takes (relatively) a lot of time, and so do other things that involve the ISP. When a customer asks an ISP for a date commitment, the ISP will usually commit to anything between 45 and 90 business days, meaning the minimum time to wait is more than 2 months, and it can sometimes also be more than 4 months (sometimes actual delivery is a bit sooner, but these are the timeframes that ISPs are willing to commit to). Hence, ordering an MPLS connection must be done as early as possible.

It’s important to understand that MPLS is not a must. oXya has customers who do not have MPLS; these customers access the data via VPN connection only. The difference between the two is that VPN goes over the public Internet, hence it is not as reliable as an MPLS connection.

 

Even if the customer ordered an MPLS connection and the ISP is slow in providing it, we can still perform the migration and provide the customer with a connection to their servers, using a VPN connection. It won’t be as reliable as an MPLS connection, but it will get the job done while waiting for the MPLS.

 

denver_140821_3561_hi (Custom).jpg

Hardware. For the hardware we have two options, with two different timeframes. Customers can either leverage oXya’s already-available Hitachi-based hardware (UCP) for shared / on-demand needs; or they can ask for other, specific hardware they would like their IT environment to run on:

  1. Hitachi UCP hardware: oXya had standardized on Hitachi hardware long before we were acquired by Hitachi, and we recommend customers to base their SAP on Hitachi UCP. Whether it is a dedicated infrastructure that you need, or share/on-demand infrastructure—and choosing between the two usually depends on size of landscape, needs, and additional criteria—oXya has a large pool of Hitachi UCP hardware, so we’re able to offer these options immediately.
  2. Other vendors hardware: oXya is open to accepting other types of hardware—per customer’s request—as we explained in detail in our previous blog. The challenge is it takes quite some time to get other vendors’ hardware. From our experience, and depending on the specific hardware vendor, we’re talking about a minimal timeframe of 4-6 weeks to get hardware from some vendors, and often significantly longer from others. Then, when we get the hardware, we need another couple of weeks to setup everything (to be explained later). Unfortunately, there is no working around the hardware. Until the other vendors’ hardware arrive, there is no technical action that can be performed; we do perform other preparation actions.

 

Two Approaches for a Datacenter Move

 

When you think about moving your infrastructure and your datacenter to a partner, there are two main options to perform this move:

 

The “Big Bang” move. You move all servers at once, from your datacenter to the oXya cloud (or to another datacenter). It is not easy to do, especially when you have many servers, because each server is unique. Using the “big bang” will likely result in lots of headaches, trying to troubleshoot various issues; furthermore, it will be challenging to pinpoint where the issues come from. For that reason, oXya typically do not recommend this approach. We prefer the phased approach.

 

The Phased Approach. We define groups of servers that work together, and build “migration groups”, where each migration group consists of servers to be migrated together. Each group is migrated separately, usually over a weekend, so the entire migration takes multiple weekends. In the case of the customer I mentioned earlier, for example, the 100 servers were divided into 5 migration groups. The phased approach requires some work from the customer on a functional level – we need to identify which servers work in conjunction with each other; at this early stage of the process, the customer still has a much better understanding than oXya on their servers. We work with the customer to help identify possible issues that may occur with respect to each group of server.

Timeline for the Planning Phase

 

The following steps are needed to prepare the hardware before we can begin moving servers from the customer to the oXya datacenter:

  • Install all the hardware components (not relevant if you use our Hitachi UCP hardware, only for other vendors)
  • Prepping the servers
  • Installing vOS (typically in a VMware environment you need to thread the images that you’re going to use for the other servers)
  • Network setup (typically VPN, unless MPLS has already been installed)

 

Above steps are the beginning of the Technical Operations phase, on which we’ll expand in our next blog. What’s important to understand regarding this stage is the following:

  • Above steps are relevant when customer wishes to use a non-Hitachi hardware
    • In such a case, the hardware preparation stage typically takes two weeks, from the time we get the hardware.
  • When using our available Hitachi UCP hardware, some of these steps are not relevant, hence the prep work is very fast, and server transfer can begin almost immediately.
  • At this stage, no data has yet been sent; these steps are just to get the hardware ready for actual transfer of data.

 

Knowledge Transfer & Planning

 

Another important part of the Planning Phase is around knowledge transfer and planning. This is where a joint team from the customer and oXya define the migration groups: find what each server does, how it works, what it communicates with, etc.

 

In addition, oXya will have some joint workshops with the customer (typically 5-6 workshops), to cover specific topics around the migration process:000038046066_high (Custom).jpg

  • Network & Security. Covers customer’s requirements, so we can implement in our datacenter. The Network & Security is sometimes split into two separate workshops, depending on the specific customer and their systems.
  • Servers Migration. Discuss what servers do, with what they communicate, and define the migration groups mentioned earlier.
  • Communications. Define how oXya team will work with the customer’s team. Covers how customer prefers to submit tickets: via email, or phone calls, or a ticketing tool (oXya’s or customer’s). We also address the escalation process, and everything around defining how we will work together.
  • Monitoring. Define how monitoring is going to work for every specific customer. Includes what needs to be monitored, what actions to perform if one of the checks fails (do we call someone or send an email), etc.
  • Global Governance. Overview of the project and follow-up every week, to make sure the project is on track.

 

The workshops are spread over the entire length of the project. Some workshops are more urgent than others; Servers Migration is one of the most urgent ones, and so is Security. On the other hand, the Communications and Monitoring workshops can be done later in the project, right before we move the servers.

 

All of these workshops are customized for each and every customer. We may create another workshop, should there be another subject that requires a deep dive with the customer and a thorough discussion. The overall goal of all these workshops, and of everything else that oXya does, is to make sure the project is a success.

 

It’s important to note that the same team who will manage your systems long-term, is the one that also drives and executes all the migration phases, including the workshops. This personal touch & dedicated team approach, in which oXya is unique at, ensures both consistency and proficiency in the details of your landscapes, throughout your relationship with oXya. Our approach also builds the relationship from day one, and ensures that your team knows the oXya support team who will handle your systems going forward, and vice versa. We are very proud of this personal touch & dedicated team approach, and it has been one of the cornerstones to our great success over the years.

 

 

What has been your experience, regarding SAP landscape migrations?

 

Did you experience any difficulties and issues? Where exactly?

 

Does your vendor also provide the same personal touch and dedicated team approach? Or each phase of the project is done by a different team, and each ticket you open is handled by different people?

 

 

---------------

Our next blog in the “Outsourcing SAP” series will cover the Technical Operations stage of moving your datacenter to oXya. Then, the blog after that 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 <smekhsian@oxya.com>,  Dominik Herzig <dherzig@oxya.com> or Melchior du Boullay <mduboullay@oxya.com>.

 

---------------oXya_HGC_logo.png

Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Data Systems company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a 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.