Instance management strategy in a large complex project

[Praveen1]

Intended Audience:

This blog is relevant for customer’s and consultants who are implementing SuccessFactors for a global client where they are planning to implement the solution in a multiple phase and have a complex landscape setup.

Use Case:

We have a global customer who is planning to implement SuccessFactors modules in their organization but want to roll out in phases by countries or regions in their organization.  This is a common requirement when it comes to large global customers where they tend to go live with the solution starting from small countries where they have small user base, feel confident with the solution that it satisfies their requirement and then roll it out to other countries where they have substantial user base.  There can also be a case where they want to roll out the solution by modules and regions, there can be multiple combinations on how Customer’s want to roll out the solution based on SF modules and regions where they do business.

When customers get SuccessFactors they generally get 3 instances depending on their contract. They are provisioned with 1 Production instance and 2 Test/Dev instances, a total of 3 instances.  We need to understand that SuccessFactors has two types of environments where these instances can be provisioned, they are Production Environment and Preview Environment.  The difference between these two environments is that Preview environment will always get the half yearly release approximately 4 weeks in advance than Production environment.  This is done so that customers can test new features and adjust to any features that affect their implementation before the new release hits their production environment.

In a large implementation generally 3 instances might not be enough during the implementation phase, and we have seen that customers tend to purchase additional instances for a fee during the implementation for multiple reasons.  Below I will discuss on a case study where a customer might have 2 or more extra instances purchased on top of the existing 3 instances.  As the preview environment is one month ahead every half year there are 2 months in a year where the two environments Production and Preview are not on the same release, so we recommend that no refresh are scheduled during these 2 months of the year, also there can be a situation where you might not be able to move configuration during this period.  So, it is recommended to keep the development and test instances in Production environment during implementation phase.  First thing would be to come up with an inventory diagram which show how many instance the customer has and what modules do each of these instances have.

Instance Inventory:

It nice to have an instance inventory diagram so that the project team know what instances are there and what are they used for.  Project team can maintain more info in the diagram as per there requirement.

Instance Inventory

Modules Deployed in each Instance:

Modules Deployed in each Instance

Have at least one instance in Preview environment so that you can test new features as and when they are released during quarterly releases. Parallelly customer can choose to have their Dev instance in Preview so that they are developing it in the latest release.  You can schedule a refresh from a Test instance when both the instances are on the same release.

There can be a consideration of an instance which is used as a master/golden instance during implementation which has only configuration and test data, this can be used for refreshes when you need to stand up an instance with a baseline of configurations.  Like there for example few modules are already rolled out and other modules are being add to existing production environment.

Above examples are for discussion purpose, customer/implementation partner can use this as a guideline to come up with a landscape diagram and configuration/data flow between instances so that at anytime they know what is deployed in each instance and how the configuration moves to production when it get developed/configured.  Below is an example from my implementation experience of how we had setup config flowchart.

Configuration flowchart:

Configuration flowchart

Golden instance was used as a Dev instance where all the configuration was done and then use instance refresh to copy to next Dev instance where they would load data and test the configurations.  You could also maintain the configuration in Golden instance and Dev instance by doing parallel configuration, it all depends on what the project wants to do.