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.
The organization has only one environment:
The company may even use an area within this environment for configuration/development planning, testing, and training endeavors.
The organization has two environments:
There are three or more environments.
There could be more than three environments. The choice is really up to the organization and its configuration/development methodology.
Of course, it's up to the company, but they can follow some effective practices.
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.
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.
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).
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!
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.