One of the most prominent issues with complex NetSuite Implementations is related to Sandbox & Production Environment Management and Change Management Policies. This will be the focus of this section of my “Keys to Success for Complex NetSuite Implementations” blog series.
For readers, new to NetSuite, a Sandbox is a safe and isolated test environment in which you can develop and test new applications and customizations without worrying about affecting your production account.
Complex projects greatly benefit from more rigorous testing and defect remediation efforts, which in my honest and humble opinion, require a dedicated team effort involving an end-to-end quality assurance team, functional consultants, business project leads, IT and end users to ensure a smooth project rollout.
Implementations for companies with many users also require more user acceptance testing and training sessions. So how can we ensure we can manage the numerous activities performed by all these actors throughout the project’s lifecycle without stepping on each other’s feet and be successful when it is time to deploy required changes?
The first step is to determine how many Sandbox environments are required and the functional purpose of each. There are many factors that can influence this decision point such as the client’s budget, project timelines, the number of project roles involved (i.e. developer, integration, data migration, end user, system administrator, etc.) and compliance needs such as Sarbanes-Oxley (SOX).
The ability to only be able to copy a production environment to a sandbox instance can also play into the landscape setup and deployment direction as well. For an enterprise level implementation, a four-environment landscape (one production and three sandboxes) is typically the norm. However, I have seen many other variations as well. In this blog, I will only focus on this setup, and detail out the advantage and disadvantage of the landscapes in question.
The use of a four-environment landscape is common as it allows us to segregate the development efforts (“DEV”), testing/quality assurance efforts (“QA”) and the user acceptance/training efforts (“UAT”) from each other. This in turn can improve chances of project success and reduce go-live incidents as long as the policy is stringently followed by the entire team, governance and change management is enforced and deployment moves are handled correctly.
To add to the complexity, these types of projects often have multiple phases, which means that once we launch the application, we need to support the next phase of the project and at the same time support production matters, such as newly discovered defects or a variety of NetSuite updates including new bundle releases and fixes.
[table id=11 /]
**Not applicable if new project phases or future rollouts are required. Note: it is easier to support a joint QA and UAT effort in the one environment than a joint DEV and QA effort.
This type of setup has many advantages. It provides development teams with more flexibility and improves efficiency throughout the development lifecycle. The developers can freely execute all their coding needs and at the same time allow the solution architect and functional consultants the ability to work on solution designs, proof of concepts and other needs.
Furthermore, the quality assurance team can also execute their test cases in peace as they have an environment that is dedicated to them without worrying about configuration changes, diminishing the risk of invalidating end-to-end testing efforts.
Based on my experience, I believe this is extremely important and should always be a priority if an organization is planning to roll out any type of back office solution, which is without doubt, a long and tedious process.
Where there are advantages, there will always be disadvantages. With these type of projects, the disadvantages are often related to deployment and change management efforts. As multiple development teams work on solutions required to satisfy the business requirements collected during the beginning phases of the project, these solutions will need to eventually be migrated in a controlled fashion from DEV to QA to UAT and finally Production.
Of course, the path I just outlined is not necessarily always the same, however it is the most common one. Performing these types of moves requires an IT Administrator that has previously worked in multi-tenant environments.
It also requires a good understanding of the SuiteBundler, which is the tool that moves over customizations or configurations from one environment to another. So how does one manage all these changes?
Well, it can of course be done manually, which requires version tracking of all changes across all environments. This in turn requires some form of tool that documents all configuration and customization details, the associated business requirement and the environment to which it has been deployed.
Issues that arise during testing also need to be tracked in the same fashion. This can be a very cumbersome and error prone process, which will quickly fall apart if not enforced by the entire implementation team.
However, even if the team does follow the defined change management process and are extremely detail oriented, I would still discourage this strategy as human beings will inevitably still slip up from time to time and make mistakes.
So, what other options are available and effective? Enter FLODocs, an automated change management tool that I am a strong supporter of. This SuiteApp is easy to install and allows you to perform a differential comparison across all your environments.
Moreover, it captures the configurations and dependencies in each environment, documents the differences between each environment, controls your deployments and finally warns you of any potential deployment issues.
We have recently become a FLODocs partner and can attest to its value, especially on larger enterprise engagements.
