I’ve worked with various customers over the years with differing philosophies regarding how many environments they have for their CRM/D365 systems.
While there are limitless ways a company might approach environments, we see three common themes.
1. Production Only
The organization has only one environment:
- The production environment—their day-to-day “real life” system in which their work happens.
The company may even use an area within this environment for configuration/development planning, testing, and training endeavors.
2. Sandbox and Production
The organization has two environments:
- The Sandbox—used for configuration/development planning, testing, and training efforts
- The production environment—used for day-to-day business operations.
3. Development, Sandbox, and Production
There are three or more environments.
- The development environment—used for configuration/development planning
- The Sandbox—used for testing and training efforts
- The production environment—used for day-to-day business operations.
There could be more than three environments. The choice is really up to the organization and its configuration/development methodology.
Which is the “Right Way?”
Of course, it’s up to the company, but they can follow some effective practices.
Avoid Production Only Scenarios
Having only a production environment could be okay if the organization doesn’t ever rollout new configurations or development work, but that’s rare, particularly in the age when Microsoft delivers a constant cadence of updates annually.
While those updates don’t necessarily pose issues, a production-only environment means you don’t have a testing ground for those updates before they hit your day-to-day environment.
If those updates do cause any issues, you’ll only know about it when the update happens and then need to mitigate the problem. The issue can significantly affect user productivity and, in worst-case scenarios, bring business operations to a grinding halt.
The Value of a Sandbox
At minimum, have a sandbox. The Sandbox essentially reduces the risk noted above to a point where business impact is limited.
The Sandbox takes the updates first, performing validation testing to understand any potential issues and giving administrators/developers time to deal with the problems before they hit production.
Usually, this means the team can implement a fix deployed before or immediately following the update. While this may include a bit of downtime, a plan is in place, and the company can work around it.
Proactive vs. reactive is always the way to go in this regard.
Additionally, having a sandbox gives administrators and users a place to try things out without the risk of impacting organizational production data.
Perhaps an administrator wants to test how a new form would work or rearrange the fields on a table form to see if it might benefit the data entry sequence.
Users might forget how a process works and want a refresher before making the changes to production data. The Sandbox gives a “safe space” for this work to unfold.
Frequent Updates/Enhancements
A development environment is wise if the company has a roadmap of changes they’re working toward and rolls changes/updates out on a semi-frequent basis.
It provides grounds for actual experimentation. For some, having this type of environment available spurs creativity.
End users rarely, if ever, have access here, so the administrator can be free to attempt whatever they’d like without fear of confusing end-users.
Of course, this can happen in the sandbox environment too. However, since the Sandbox is where users would go for training/testing, they may see changes and expect them to resonate in their production environment at some point.
It may add a layer of uncertainty to the equation that doesn’t need to exist.
Plans and tests begin in the development environment, then move a solution to the Sandbox for testing and training. Once ready, the items get pushed to production (along with effective change management communications and training).
Keeping Environments in Sync
While this may feel somewhat counterintuitive to the points noted above, it’s essential to have a defined process for keeping environments in sync.
At a minimum, a company should plan to move the production configurations down through the chain of systems available.
You may be thinking, “But why would that be necessary if the solution movement path moves from environment to environment?” That’s a fair question.
Sometimes, things change in production due to an update from Microsoft or a tweak to something implemented in a “quick fix.” While these situations shouldn’t happen, they do from time to time.
Embrace that reality and have a designated time (or times, ideally) throughout the year where you push all configurations back down through the chain so that everything is in sync.
We hope this article has given you some food for thought concerning D365 environments and how to manage them. Have questions about this or anything else D365 related? Contact C5 Insight today!
