Non-Techie Guide Part II: Managing Environments in Dynamics 365 Business Central Online

One of the key differences to consider when moving from Dynamics NAV or Dynamics 365 Business Central on-premise or private cloud to a SaaS solution (aka Software as a Service or public cloud) is the types of environments that are available and how they should be used. 

There are 2 types of environments, Production and Sandbox. Each Microsoft Azure Active Directory tenant that buys a Dynamics 365 Business Central online licence automatically gets 1 production and 3 sandbox environments tied to a specific country and localisation with an allocation amount of storage.

Note that the total storage allowed is spread across both the production and sandbox environments – so that as your database grows you need to be aware of incurring additional storage costs by keeping unnecessary sandboxes.

Additional production environments can be added at additional cost and each additional production environment comes with three additional sandbox environments and 4 GB additional, tenant-wide database capacity.

Production environments for Dynamics 365 Business Central

This is the environment that your business uses to run Dynamics 365 Business Central. It is deployed on performance tiers in Microsoft Azure with a guaranteed high level of availability and support. It is are backed up automatically and frequently to protect your data.

Live companies can be copied for training and testing purposes, but development should not be deployed to your production environment until tested in a sandbox environment.

Sandbox environments for Dynamics 365 Business Central

Sandbox environments should be used as a testbed for development, training or just trying things out and can be created and deleted at will. Dynamics 365 Apps can be deployed straight from Visual Studio Code to a sandbox environment, and you can attach a debugging session to a sandbox. They are there to play around with and can be significantly different from the production environment.

There are a few key thing to note about Sandbox environments:

1. App Deployment: It is important to note that Apps that are published to a sandbox directly from the development environment or created using Designer are published within the scope of the service node and will therefore be removed when updates take place.
2. Performance Testing: Our support team may create a sandbox for debugging purposes but if you want to run performance tests, or similar benchmarking, the sandbox is not reliable enough for these purposes. This is because sandboxes run in a different performance tier on Microsoft Azure than production environments.
3. Backups & data exports: The automatic backup that applies to production environments does not apply to sandboxes. Also, you cannot request a database export for a sandbox environment and can only export data by using Excel or RapidStart.
4. Deletion: A Sandbox environment should be deleted once it has served its purpose – so as not to waste, potentially costly, storage. It is recommended that there is always at least 1 sandbox available for use to test updates before they are applied to Production.