How to Refresh a Dynamics 365 F&SCM Sandbox From Production
how to refresh D365 finance and operations sandbox from production LCS
Also searched as
- D365FO database refresh production to sandbox
- LCS move database refresh steps
- what to do after D365 sandbox refresh batch jobs withheld
- D365 finance operations copy production to UAT
Short answer
In Lifecycle Services, open the target sandbox, choose Maintain > Move database > Refresh database, pick the production environment as the source and confirm. The copy replaces the sandbox AOS database, so you must then redo everything that is environment-specific: batch jobs, integration endpoints, email, print settings, users and Entra ID app registrations.
Applies to: Dynamics 365 Finance and Supply Chain Management (cloud, Tier-2 or higher sandboxes, one-version service updates). Environments managed through LCS; unified environments use the Power Platform admin center for the same operation.
How to refresh a sandbox from production
- 1Tell the project team and freeze deployments: a refresh overwrites the whole sandbox database, including unreleased test data, configuration and personalizations stored in the database.
- 2Export what you need to keep: data management packages for configuration data, user-specific saved views if important, integration endpoint settings, and a list of batch jobs and their recurrences.
- 3Confirm the source (production) and target (sandbox) are on compatible application and platform versions. If the sandbox is on a newer version than production, the refresh is not allowed; update first.
- 4In LCS open the project, go to Environments, select the target sandbox, then Maintain > Move database > Refresh database. Select the production environment as the source and submit the request.
- 5Wait for the operation status to show Completed in the environment history. The environment is unavailable while it runs, and large databases can take several hours.
- 6Sign in and check System administration > Inquiries > Batch jobs. After a refresh, jobs are placed on hold (Withhold) so the sandbox does not run production schedules against test systems.
- 7Re-enable only the batch jobs you want in the sandbox and update integration endpoints, URLs, service principals, SFTP and API credentials so the sandbox does not call production services.
- 8Reapply email settings under System administration > Setup > Email > Email parameters, and verify Entra ID application registrations under System administration > Setup > Microsoft Entra ID applications.
- 9Check user access: user accounts, roles and legal entity assignments come from production, so confirm testers can sign in and that test-only users you created before the refresh are re-added.
What a refresh actually does
A database refresh copies the production AOS database over the sandbox AOS database. Code and the application binaries are not copied, only data. That means the sandbox keeps its own deployed packages (including your extensions and ISV models), while every table row, number sequence, workflow definition, batch job and parameter record now matches production at the time of the copy.
The platform deliberately neutralizes some things so a sandbox cannot do damage. Batch jobs are set to Withhold, and email sending is disabled in the copy. Many other settings are not neutralized, which is where the real risk sits. Any integration whose endpoint URL is stored in a parameters table, a business event endpoint, or an Electronic reporting destination still points where production pointed unless you change it.
Because the environment ID changes, anything keyed to the environment, such as Power Platform links, Azure DevOps build service references, or ISV license keys tied to the AOS, may need to be re-established. Treat the refresh as the start of a short, repeatable post-refresh runbook rather than a one-click operation.
Pre-refresh preparation
The only reliable way to preserve sandbox-only configuration is to export it before the refresh. Use Data management > Export with a project that contains the entities you changed: system parameters, number sequences used for testing, integration endpoint tables, workflow configuration, and test users with their role assignments. Keep these as reusable data packages in a shared library so the same packages can be imported after every refresh.
Also record the performance and capacity baseline. If a Tier-2 sandbox is much smaller than production data volume, long-running forms and batch operations will behave differently. A refresh does not resize the environment, so a test that ran fine on a thin dataset may become slow after the copy. Plan test cycles knowing this.
Finally, check data privacy obligations. A production copy contains customer, vendor and employee data. If your organization masks personal data in non-production, there is no built-in anonymization step in the refresh itself, so you must run your own scrubbing job or an approved data masking tool after the copy and before testers are given access.
Post-refresh checklist
Work through the list in the same order each time and keep it as a document the team signs off on. First, secure the environment: block external endpoints, change SFTP and API keys, and clear email addresses on customers and vendors if you could send mail by accident. Then restore functionality: import your saved configuration packages and re-register the environment-specific application IDs.
Next, rebuild integrations in the right sequence. Recurring integration jobs, business events, and Power Automate flows may still carry production identifiers. After you switch them to test endpoints, run a single transaction through each path and confirm it lands in the test system, not in production.
Last, rerun the smoke tests: create a sales order, post a purchase invoice, run a master planning job and a recurring batch. Only then release the environment back to testers and note the refresh date so everyone knows how stale the data is.
-- Check which batch jobs are on hold after a refresh (run in a sandbox SQL context) SELECT NAME, STATUS FROM BATCHJOB WHERE STATUS = 0; -- STATUS values: 0 Hold, 1 Waiting, 2 Executing, 3 Error, 4 Finished, 5 Ready, 6 NotRun, 7 Canceling, 8 Canceled
Common refresh failures
The most frequent failure is a version mismatch between the source and the target. LCS blocks the request or fails it early when the platform or application version differs in a way the database cannot be upgraded through. The fix is to bring the sandbox to the same or a lower release first, or to wait for production to be updated.
Another common issue is a refresh that completes but leaves the AOS in a state where users cannot sign in, usually because the Entra ID tenant or the user principal names differ between source and target. Confirm the tenant is the same, and if you use a separate test tenant, plan a user mapping step.
Finally, if the database is very large the operation can exceed the expected window. Raise a Microsoft support request through LCS if it remains in progress far beyond your historical norm rather than submitting a second refresh, which can collide with the first.
Common pitfalls
- !Re-enabling every withheld batch job at once, which fires production recurring jobs (EDI, bank, email) from a test system.
- !Leaving integration endpoints and SFTP credentials pointing at production after the copy, so test transactions reach live partners.
- !Forgetting that personal data is copied as is, with no masking, into an environment that has wider user access.
- !Assuming code and extensions are refreshed too: only data is copied, so the sandbox keeps its own deployed packages.
- !Not exporting sandbox-only configuration beforehand and losing test setup that took days to build.
- !Submitting a second refresh while the first one still shows In progress.
How an ERP-grounded AI assistant handles this
A grounded assistant such as ERPray, connected read-only to the environment, can list the post-refresh state for you: which batch jobs are on hold, which endpoints and parameters still contain production URLs, and which users or roles differ from your saved baseline. It shows the queries it ran and does not change anything, so the checklist becomes a report your admin reviews rather than a memory exercise.
Frequently asked questions
How long does a D365 sandbox refresh take?
It depends on database size and Azure load. Small databases may finish within an hour or two, while large ones can take many hours. The environment is unavailable during the operation. Watch the operation status in LCS and use your own previous refresh durations as the baseline rather than a published number.
Does a refresh copy my customizations and extensions?
No. A database refresh copies data only. Deployed code packages in the sandbox stay as they are. Anything stored as data, such as workflows, parameters, number sequences and personalization records, is overwritten by the production copy.
Why are all my batch jobs on hold after the refresh?
The platform withholds batch jobs after a database copy so that a test environment does not run production schedules. Review them under System administration > Inquiries > Batch jobs and re-enable only the ones you need after you have repointed integrations.
Can I refresh from sandbox to production?
No, the supported direction is production to sandbox and sandbox to sandbox. Moving a sandbox database to production is only possible through the go-live process, and only for the initial golden configuration, not as an ongoing refresh.
Related
Fixing "Cannot create a record in (table). The record already exists" in D365 F&SCM data entity imports
This is the standard kernel duplicate-key exception, thrown when the Data Management Framework tries to insert a staging row into a target table whose unique or alternate key already matches an existing record. It almost always means the entity's insert-vs-update logic did not recognize the target row as an update, not that you have a true accidental duplicate in your source file.
Error fixFixing "There are currently no batch servers available for processing" in D365 F&SCM
This message means the batch framework cannot find any AOS instance flagged as a batch server and available for the batch group the job is assigned to. The fix is almost always in server configuration (System administration > Servers) or batch group assignment, not in the batch job itself.
How-toD365 Recurring Integration: Enqueue, Dequeue and Ack Explained
Create a recurring data job on a data project, register an Entra ID application and authorize it in D365, then POST files to api/connector/enqueue/{activityId} to import, or GET api/connector/dequeue/{activityId} followed by an ack call to export. The job's activity ID in the URL ties your calls to the data project.
How-toHandling OData 429 Too Many Requests throttling in D365 Finance and Operations
D365 F&SCM protects shared AOS capacity by throttling OData and custom service calls, returning HTTP 429 with a Retry-After header once a client sends too many requests too quickly. The durable fix is to honor Retry-After with backoff and redesign high-volume or frequent-polling integrations to use batching, business events, or Data management instead of tight request loops.
Error fixFixing "You do not have the following permissions on TableData (table): (permission)" in Business Central AL
This runtime error means the current user's assigned permission sets do not grant the required Insert, Modify, Delete, Read, or Execute right on that specific table. It is most common right after installing or updating a custom AL extension, because Business Central checks object-level permissions even for tables an extension owns.
Error fixFixing "The CIL object was not found" in Dynamics AX 2012
This error appears when the AOS tries to execute compiled CIL for a class or method that has not actually been regenerated since a code change was imported or edited, so the .NET runtime has nothing matching to run. The fix is a full compile followed by a full CIL generation and an AOS restart, not just a partial or incremental rebuild.
AI for ERPAI for Dynamics 365 Finance and Supply Chain beyond Copilot
AI for D365 Finance and Supply Chain beyond Microsoft Copilot: private LLM grounded on data entities and OData, on-prem-capable via Local Business Data.
Stuck on Microsoft Dynamics 365 Finance and Supply Chain Management?
Talk to engineers who work inside Microsoft Dynamics 365 Finance and Supply Chain Management every week, and who build private AI that answers these questions from your own ERP data.