Skip to Content

Updates to the SAP SuccessFactors release cycle for 2017

At SuccessFactors, we periodically review our release processes, specifically the schedule and frequency of software releases, to see how we can make it easier for customers to adopt the innovations we bring to market.

In 2015, we adjusted our quarterly release cycle to first apply releases to customer Preview/Test environments, and four weeks later, apply the same release to customer Production environments. This simplified the release process for customers who until then were either on a Standard or Premium release schedule. The new approach brought all customers on the same release schedule. This model also allows all customers to test release features in Preview environments over four weeks prior to the Production upgrade. Since this change, we have tracked customer activity in the Preview environments, and have seen that customers are indeed taking advantage of the opportunity to test new releases. For our Q3 2016 release, we tracked more than 27 million customer logins in the Preview environments prior to the Production upgrade.

In 2017, we will introduce a new adjustment to our release cycle. We will continue with the quarterly release schedule, but the Q1 and Q4 releases will have deliberately restricted content. In those releases we plan to only include features that are additive to existing functionality, generally opt-in by nature. And we do not plan to include redesigns of existing functionality in the Q1 and Q4 releases. So for example, we may release new features for Recruiting, Learning and Employee Central, but we will exclude architectural improvements for modules from the Q1 and Q4 releases. We are taking this approach to reduce the amount of regression and integration testing that customers perform. For the Q2 and Q3 releases, we will continue to include new functionality as well as architectural improvements to existing capabilities. We expect the Q2 and Q3 releases to be larger in content. And we generally expect that customer release testing will be lighter for the Q1 and Q4 releases, and more intensive for the Q2 and Q3 releases.

Why did we select Q1 and Q4 for lighter releases with only additive functionality? Why not have an alternating release schedule with one release lighter, next release heavier, and so on? Our choice of schedule is completely based on our observations of customer usage of our solutions. The most intense HR processes tend to be concentrated in Q4 and Q1 when most of our customers are conducting performance reviews/focal cycles, goal setting, compensation reviews, succession plans, and talent reviews. As a result, customers have lower capacity to perform deep testing of new releases in this period. On the other hand, customers tend to have more flexible capacity to test new releases in Q2 and Q3. These updates to the release cycle are part of the customer commitments we made at SuccessConnect 2016.

We anticipate that the Q2 release will likely be the largest in our calendar year, as that’ll be the first opportunity to introduce features and designs postponed from Q4 and Q1. The Q1 2017 release (known internally at SuccessFactors as “1702” because it will be deployed to customer Preview environments in February 2017) will be the first under this new model, with scope deliberately restricted to additive features only. And the Q2 2017 release (internally called “1705”) will be the first release of the year with both architectural changes and additive features.

I welcome your questions about the SuccessFactors release process, and your feedback on the 2017 release cycle as the year progresses.

You must be Logged on to comment or reply to a post.
  • Adam, this is an well-thought-out response to customer concerns over possible disruption to core HR processes  - like the compensation planning cycle. I think most customers have seen more change than they are able to absorb effectively. I look forward to the quarterly updates to come and further understanding how those will enable innovation in moderation. I am interested next in understanding how Country Legal Changes might be incorporated in the cloud release cycle for the future. Great to have your expertise on this topic.


      Sherryanne - Let's discuss your thoughts about the legal changes offline. Do you mind sending me an email on the topic?
      Thank you,

  • Hi Adam
    Thank you, as mentioned above already, this was an extremely much needed process change. Clients just could not keep up with the amount of changes being rolled in, and the cracks was starting to show, especially seeing how the Support hub around the SF products has been failing in regards to turn around times for issues. Clients spend more time on problem resolution and retesting then actually using the system. I assume that this change would not divert the weekly rolling patch updates process either - that is another area that needs to be remapped into a sustainable process for clients.
    Thanks for updating us on this. Client is very appreciative.


      Jean-Pierre - You are correct that the 2017 release process change does not alter the weekly patch process. To be honest, given 6,000 customers, a dozen products, in 10 data centers, it's pretty much guaranteed that somebody, somewhere needs a code update that can't wait until the next quarterly release. That said, our Engineering team have significantly tightened down the rules on what should be considered for patching and, despite transactional usage volume being more than 60% higher than a year ago, patch volumes are running 30% lower.
      Thank you,

  • Hi Adam,

    thank you for the update which is quite helpful for our customers.

    One of my customers asked why we can't get instead of 4 weeks testing 6-8 weeks testing on the preview stack. The 4 weeks are not time enough to do the regression testing, the integration testing, testing of new functionality and check own custom reporting.
    Is there a plan or any considerations to extend the test phase to 6 or 8 weeks for our customers?
    This might help our customers to rectify their preview and test phase.
    I am looking forward to your feedback.


      Max - Our historical experience has been that any truly significant release issues are reported and identified within the first 2 weeks after release, and resolved within the first 4 weeks. And this is what led us to a 4 week gap between the Preview upgrade and Production upgrade. Would we consider a longer gap? Of course we are always open to ideas ... but I have a suspicion that, whatever gap we have, there will be people who would like to see a longer one. For our 2017 schedule, we are retaining the current 4 week gap.

      Thank you,


  • This is indeed a great and well thought out change in the release cycles.
    We have a number of customers overwhelmed by continuous changes to their environment and the amount of effort that goes into regression testing. This has resulted in more focus towards ensuring that the current implemented functionality does not break and with very little focus on adapting to the new features.
    With this change in the release strategy, customers can now focus on exploring the new capabilities of the product atleast in two out of the four releases.

  • Kudos Success Factors Team! Great work in identifying one of huge pain point for most HR organizations that has SF implemented and remedying it appropriately. Am positive that most clients are going to love this!
    What would be nice in Q2 release of 2017 & years going forward - Would be whenever redesigns of existing functionality are offered, they are well tested before rolling it out to clients, so can avoid disruptive weeks right after release patch goes into production. As we had seen in past - Even after testing this release notes extensively in preview instance, most release patches when applied to Production, ends into various issues most cycles.


      Charmi - We like to believe that our redesigns are well-tested before deploying to clients. In truth, many hundreds of redesigns go into quarterly releases as we improve for scale, for maintainability, for performance, for usability, for coping with new functional use cases than were envisaged at the time of original development. Very few of these redesigns result in problems ... most go completely unnoticed by anyone. But, I acknowledge that "most" is not the same as "all" and, yes, it's our goal to ensure that all redesigns do not disrupt customer usage.
      Thank you,

      • Adam, Thank You for reassurance. Did we had disruptions in past? Yes we did. Said that, we can only imagine how challenging it must be for Success Factors Engineering team to manage 6,000 customers, a dozen products, in 10 data centers!!
        We are optimistic about Success Factors growth in such a short span and looking forward to well thought out resolution offering to customer issues and challenges, as move forward to 2017.