A working guide to Business Central sandbox environments

What Business Central sandbox environments are for

A sandbox is its own environment. It has its own database, in the same tenant as production. Nothing posted there reaches the live company. Teams use it to try a new posting setup. They also rehearse a data migration. They also train new staff on realistic data. Developers publish extensions from Visual Studio Code with the debugger attached.

So sandboxes are for testing and development only. Microsoft does not intend them for running the business, and their speed does not measure production. Your subscription includes a set number of environments. Your licensing partner can add more. So check your allowance.

Creating Business Central sandbox environments in the admin center

Open the admin center. Go to Environments and choose New. Give the environment a clear name. Set the type to Sandbox and pick the country and version. A new empty sandbox holds the CRONUS demonstration company. That is fine for learning, but it tells you little about your own setup.

For meaningful tests, open the production environment instead and choose Copy. Name the target and set its type to Sandbox. Then start the copy. The result has your companies, data, setup and extensions as they were then. Administrators need the right Microsoft Entra role, or partner access, to do this.

What is switched off in a sandbox copy

A copy must not act on the outside world. Business Central protects you here. So Business Central runs a clean-up when it creates a sandbox from production. Job queue entries go on hold. Outgoing email and several integration setups are disabled or cleared. Scheduled tasks stop. This prevents a test copy from emailing customers or sending duplicate orders to a web shop.

That protection means you must re-point integrations before you test them. Connect the sandbox to a test account, such as a payment test account or a test Dataverse environment. Never use the live ones. Extensions from other publishers may carry their own connection settings. So check each one before restarting any job queue entry.

Using Business Central sandbox environments to test updates

Microsoft ships two release waves each year and offers preview versions ahead of each. Create a sandbox on the preview, or copy production and update the copy first. Then run your core processes from order to payment. Pay special attention to extensions, custom report layouts and anything that calls an API.

In the admin center you can set an update window. You can also pick the date to apply an update, within the period Microsoft allows. A sensible routine is to update the sandbox as soon as the version is offered. Test it, then fix what breaks. Then schedule production afterwards.

Managing your sandbox environments over time

Copies age quickly. An old sandbox no longer reflects current setup. Tests run in it give false comfort. Refresh it by deleting the old copy and creating a new one. Name environments by purpose, such as Test, Training and Dev. Then nobody has to guess which is safe to break.

Remember that a copy contains real customer, vendor and employee data. So grant access with the same care as production. Users see the environment name and type in the client. If you would like a landscape and refresh routine designed for your team, our consultants can set that up for your Business Central sandbox environments.

Business Central sandbox environments: questions

How many sandboxes can I have?

A Business Central subscription comes with an allowance of production and sandbox environments. You can buy more. The admin center shows how many you are using. Microsoft adjusts allowances from time to time. So confirm the current figure on its licensing pages or with your partner. Do that before you plan a set of environments for training, testing and development.

Does a sandbox copy include my real data?

Yes. Copying production brings across every company, its transactions, setup and installed extensions. That is what makes tests realistic. It is also why access to the copy should be limited to people who may see the same data in production. So treat your Business Central sandbox environments with the same care as the live system.

Can I move changes from a sandbox to production?

Setup does not transfer automatically. Extensions are deployed as app files. You can move configuration with configuration packages, or enter it again by following the notes from your test. Converting a sandbox into a production environment is not the intended route. So keep clear notes of every change you make while testing.

Will my integrations run in the sandbox?

Not until you switch them back on. The copy process places job queue entries on hold and disables several connection setups. Point each integration at a test endpoint first. Then release only the job queue entries you need for the test. That way no real customer or supplier receives a message by mistake.

Can developers debug in a sandbox?

Yes. Developers can publish an extension from Visual Studio Code to a sandbox and attach the debugger. That is not possible in the same way on production. Snapshot debugging exists for investigating problems in production, with the right permissions. So most teams build and test in a sandbox first, then move the finished extension across.

Pages that build on Business Central sandbox environments

A sandbox is where upgrades, migrations and custom work are proven before they go live. These guides and services describe the work that usually happens inside one. They cover data migration, upgrade testing and extension development. Read the page that matches your next project. Then plan which of your Business Central sandbox environments you need, and who may use each one. For the product detail, see Managing environments in the admin center on Microsoft Learn.