SAP SuccessFactors migration to HANA begins in earnest

SUMMARY:

The long-promised SAP SuccessFactors migration to the HANA database starts now, with customer instances moving en masse over the coming months

Adam Kovalevsky SAP SuccessFactors 250px
Adam Kovalevsky, SAP SuccessFactors

This year will see the SAP HANA database face its biggest test yet, as the entire SuccessFactors customer base moves onto the platform in a series of migrations that have long been planned for the first half of 2017.

The transfer to HANA has been in preparation for a couple of years already. In late 2015 I quizzed then senior VP of product management Dmitri Krakovsky (shortly before he left for a role at Google acquisition Bebop) about the scale of the task. At the time, SuccessFactors had already become HANA’s largest user, having implemented analytics and reporting on the database. But the migration of SuccessFactors’ large-scale, multi-tenant, transactional applications was going to be a far bigger test, he told me.

Nobody runs HANA in a multi-tenant environment at this scale. That’s why we want to be careful, thoughtful — because it’s live customers in production environments.

Even then, there were a small number of customers whose core applications had already moved to HANA so that SuccessFactors could finetune and test the implementation. That’s continued throughout 2016, along with work to scale out the migration tools so that customers can be moved in tranches rather than individually.

At the company’s EMEA customer event in late November, I caught up with Adam Kovalevsky, who as Executive VP of Product Management, Engineering & Operations, has overall responsibility for the success of the project. He brought me up to date with where things stand as the company prepares to roll out the migration in earnest.

A series of migrations

Designing the bulk migration tool has been a critical piece. The company runs “in the order of 30,000 schemas,” he says — the blueprints that define the structure of each individual organization’s data. Moving them one at a time was fine for development and testing purposes, but that process has had to be automated to permit large-scale migration. That too has been carefully tested with small numbers at first before ramping up the volumes:

It doesn’t sound like a super impressive number, but we migrated nine customer environments [in October] with that [tool]. Essentially, we’re scheduling the next fifty and then, over the course of 2017, each weekend in each of the ten data centers we’ll have a series of migrations that we’re running.

Similarly, the early migrations are of less complex implementations. The largest customers will move across to HANA later on in the project, he explains.

Not surprisingly, we choose simpler examples first. The gigantic 300,000-employee company running every possible application … no that’s not the first one that we migrate.

They tend to be organizations — 10,000 employees or less with simpler configurations — that we migrate. That’s working well. We’ll see that accelerate as we go into Q1 and we go through the course of 2017.

Standardizing on HANA has given the company an opportunity to simplify its data center operations from a “hodgepodge of databases” that the SuccessFactors family of applications was originally built on, says Kovalevsky. That has already proven itself in analytics:

Honestly, we don’t think that we would be scaling our analytics and EmployeeCentral reporting at the rate that we do today if we were still on SQL Server/Hadoop. We don’t think it would have handled the volume that we have today.

Optimizing performance

The developers have been working closely with their HANA colleagues to deal with issues as they arise.

I’m running HANA at a larger scale than anyone else has ever attempted to run HANA before. Obviously we encounter issues, and we work closely with the HANA engineering teams to resolve those issues as we go forward.

With the core transactional applications, there’s been a strong focus on ensuring performance remains the same or better on HANA as it has been on Oracle. In some cases, that involves a rewrite of the original function to better optimize it for HANA, as Kovalevsky explains:

At the end of the day we can’t migrate customers to HANA for them to have a materially different performance experience.

There’s probably 10% of transactions where we see that HANA is significantly more performant than what we had in Oracle. There’s probably 85% of transactions where, honestly it’s more or less similar. And maybe there’s 5-ish percent where it’s materially slower on HANA than on Oracle.

Those are the ones where we essentially do a whole rewrite of, how do we optimize for how it can work on HANA? Then does that, in that rewrite, also change our thoughts on how do you approach the problem in the first place?

Moving to public cloud

Once the migration has been completed, a longer-term aim is to supplement SAP’s own data centers with public cloud alternatives, building on the partnership with Microsoft Azure that was announced in October. For now, the Azure option is used primarily for internal purposes — sales demos and testing by professional services — before being rolled out to customers. But it is likely to become more strategic in the future, says Kovalevsky:

If I look ten years into the future, I would imagine that our growth will predominately be in public cloud data centers, because however competent we get at buying equipment and standardizing environments, I have to think that there are bigger and larger fish out there that are even doing that at a scale that make us look like a drop in the ocean.

So, we have a partnership with Microsoft that we announced the end of Q3, beginning of Q4. We’re frankly very excited about that. It enables us to explore that as a potentially a long-term option for how we grow and scale.

My take

This is a major undertaking by SuccessFactors — which mirrors similar ongoing migrations by other products in the SAP portfolio, including Ariba and Concur. Successful completion will be a major milestone for HANA, but until the migration is complete, customers will be watching carefully for any signs that things aren’t going according to plan. So far, all seems to be on track, but we are now heading into the most critical phase of the project. Time to buckle up for the ride.

Image credit - Wildebeest migration, Mara river, Masai Mara © EcoView - Fotolia.com; headshot via SAP

Disclosure - Oracle and SAP are diginomica premier partners. SAP paid most of the author's travel expenses to attend its event in Vienna.

    1. Jarret Pazahanick says:

      Great to see a realistic perspective of when SF will be on HANA (after the 2012 announcement) plus what customers can expect. After all the marketing hype on HANA to see a 80% the same, 10% faster and 5% slower will be disappointing to some the fact they were be off Oracle is a big win for SAP overall. Now the key question is, will they pass on any savings to customers 🙂

      1. Phil Wainewright says:

        Agreed, this was a helpful update on progress.

        “5% slower” – in fairness, Kovalevsky explicitly says that they are specifically working out how to fix these aspects so that there will be no performance loss after migration.
        Therefore the overall impact will be 10% faster, 85% about the same and 5% brought up to speed.

        And a lot of the most significant performance impact of moving to HANA has already happened because it’s felt in analytics rather than transactions.

    2. Purushothama Naidu says:

      Ok nice to see the progress ..

    3. Gopinath says:

      Rather than passing on savings, I would be more happy to see performance improvement and not to see the spinning wheel again! It will be a big disappointment if the performance is the same as most of the customers are expecting huge difference in performance upon moving to HANA. If HANA migration proves to be disappointing this means SuccessFactors will be easily loosing customers to Workday!

    4. Because business models are changing to huge multi-tenancy, where even SQL Server and Oracle Database do not perform under massive concurrency. It would be Icarus like to expect HANA to fly around the sun differently than these two highly refined SQL databases.

      Perhaps SAP’s multi-tenancy engineering are able to defy the database engineering at other top software companies. Or perhaps very careful product migration can incrementally allow engineering to solve both known and unknown issues as they crop up over many years.

      Case in point look at SFDC’s OracleDB on OracleDB, the pattern provides great scalability for CRM but not for ERP. More see comment (scroll all way down) on Holger Mueller’s report for more detailing. http://enswmu.blogspot.com/2017/01/progress-report-salesforce-has-platform.html

    Leave a Reply

    Your email address will not be published. Required fields are marked *