SAP SuccessFactors HANA migration is done – hyperscale is next

After two-and-a-half years in the making, on March 26th this year, SAP finally completed the migration of all instances of SuccessFactors to the HANA database platform. But this long-running story has a cliffhanger ending, with a sequel already lined up. For its next move, SAP SuccessFactors is heading to the world’s four largest hyperscale cloud platforms.

We’ve been following this evolving story since SuccessFactors first turned to HANA for analytics and reporting back in 2015. As one of the world’s largest multi-tenant SaaS applications, the prospect of moving the whole of SuccessFactors to HANA was always going to have a blockbuster billing, as then SuccessFactors President Mike Ettling told us:

There’s an element of, we’re going where no man has gone before. Running this scale of multi-tenant code in memory, we don’t know what’s going to happen.

Even with analytics and reporting, I’m the biggest HANA user in the planet. We’re in Star Trek territory.

The HANA migration saga

Historically, SuccessFactors had run on the battle-hardened Oracle database platform, whereas the SAP HANA database was as yet unproven in such a challenging environment. Our verdict at the time was that this was going to be a story worth following:

There are many varieties of multi-tenancy but none are more challenging than multi-tenancy at the enormous scale of global cloud application vendors like SuccessFactors. Proving it can be done will be a major coup for HANA.

It certainly didn’t happen overnight. The initial timeframe proposed for the migration was the first half of 2017. A handful of instances – or schemas, to use the correct database term – had been migrated the year before as an initial test, but the project then went on hold pending an upgrade to the HANA platform, which rolled out in mid-2017. The migration started again in earnest in early 2018.

It was important to get everything right to make sure customers were not impacted, explains Amar Singh, VP of Operations at SuccessFactors, who updated me on the current state-of-play last month:

We took two-and-a-half years to make it, from October 2016 when I started – and at that time there were a small 8 or 9 schemas that were migrated – till in total we did about twenty-seven thousand or so.

We went through a lot of diligence. All the validation and each and every test took up the longest piece of it, before we touched anything from a customer point of view.

[Updated to add:] To be clear, this migration refers to EmployeeCentral and ancillary SuccessFactors applications, but does not include payroll, which is on a different development track, as diginomica’s Jon Reed explored in his write-up last November on the future of SAP payroll.

Next up comes hyperscale cloud

As a result of all this preparation, the only issue was the failure of a small number of custom reports, which SAP then worked with customers to fix. There was no impact on transactions, even though the largest part of the migration took place between September and March, which due to seasonal factors is the peak period for SuccessFactors usage, says Singh:

Those are our highest transaction days, and transaction-wise it was flawless. It was only reports we bumped into – reports which were custom reports for a few customers.

Now that the migration is complete, SAP has its proof point for multi-tenant HANA at scale. But this isn’t the end of it, as Singh explains:

Today, we are running the biggest cloud in the world on HANA … We are running about a billion transactions a day on HANA …

The next building block is the hyperscaler piece of it.

The move to run on any of the four hyperscale clouds – Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and China’s Alibaba – was always seen as the next step in the plan. The aim is to give customers freedom of choice while taking advantage of the reach and scale of these four global public cloud providers. The ability to switch to another cloud will be a configuration change, says Singh.

It’ll be just a simple migration from AWS to Azure [for example], because the stack underneath stays exactly the same.

We need to have that option. What if tomorrow Amazon goes out of business? We want to make sure that we are covered.

Containerization, Kubernetes and microservices

Perhaps the most significant aspect of this next move is that it involves re-engineering the stack to run on containers under Kubernetes. This journey is under way, and as a well-beaten path should not take as long as the move to HANA, says Singh:

Containerizing this stuff is probably another six months to nine months. The journey’s already started. It’s just a matter of maturing certain areas, and then rolling it out.

The beauty of new technology, it is not reinventing the wheel. The world has already done it. It’s already been baked and it’s pretty structured, stable. We are running certain environments already on that.

Containerization allows the platform to adopt a microservices architecture, which provides a foundation for further changes. Most notable among these are a move to an API-based integration landscape with other components of SAP’s Intelligent Enterprise, and greater fluidity in the user experience (UX) across Web, mobile and conversational interfaces. From that perspective, the migration to HANA and then on to a containerized architecture in the hyperscale cloud together provide a foundation to deliver new value, says Singh.

First we need to do performance, stability, resilience and all the pieces which are table stakes. That is going to be there.

Now what are the new opportunities opening up? Intelligent Enterprise, we are coming back with it. The experience management ecosystem, we can provide those services on top of this baseline …

The strategy is to make it modular so we can plug in the value-adds. This is the foundation we’ve built.

My take

One thing you can be sure of in the cloud is that things never stand still. No sooner has SuccessFactors completed its long-awaited HANA migration than a new adventure begins.

In many ways, this new venture into microservices on public cloud is even more exciting for customers than the one just ended. Moving to HANA is really just SAP’s own internal housekeeping, in much the same way that its competitors have overhauled their own underlying database platforms.

The next move into a more fluid, microservices-based and API-enabled architecture should allow for much faster innovation at the application layer. That’s going to be of significant interest to customers, who are increasingly demanding a new, more modern style of enterprise application.