Restoring Old Environments in Business Central

/ Dynamics 365 Business Central, Integration With Business Central / By

This article will outline the ways in which a restoration for an environment will be possible and the limitations associated with it. It will then explore things you should consider after a restore, such as name changes. Microsoft have launched a new update that allows for the restoration of users’ systems to a point in time in the past.

The current situation

Where you’re going to be implementing new data that may cause issues, typically a copy of the company would be made in order to save yourself from any knock-on effects caused by any number of differing migration errors that are possible.

But it isn’t just importing data that can introduce these inhibiting errors. Where a company has development introduced to a system, it’s possible that issues that occur cannot simply be reversed. It can lead to a system having to start from scratch in certain cases. This is of course the worst-case scenario and Microsoft plan to mitigate these risks. Microsoft are proposing changes that will allow users to revert to a point in the environment’s lifecycle within the past 30 days. This is ample time to sort out any issues with data and avoid making any company-damning errors.

The proposed criteria for restoring an environment

  • The environment which you are trying to restore requires a paid subscription.
  • Previously deleted environments cannot be restored. In such situations where this is required, contact Microsoft Support for help. It’s not always possible for Microsoft to restore an environment as intended, but they can try. Data or extensions can be unintentionally omitted due to the difficulty of such a restoration. Essentially, there are no guarantees a previously deleted environment can be restored.
  • You can only restore an environment that matches the Azure region and country of the original environment.
  • There are limitations to restoring Sandbox environments. Whilst Production environments can be restored as either a Production or Sandbox environment, Sandbox environments aren’t granted this flexibility. These can only be restored as Sandbox environments.
  • An environment is limited to a maximum of 10 restorations in a month. It’s extremely unlikely that number would ever be required anyway!
  • Sandbox environments which have had development extensions can be restored, but not with their extensions. The extensions in question are those published directly from Visual Studio Code. This is even the case if the extensions were present in the environment’s system at the time you are reverting to. This includes any per-tenant extensions which rely on development extensions.
  • Any per-tenant extensions created for the purpose of implementing within the following version of the Business Central won’t be available in the restored environment. Again, this applies to cases even where they were uploaded at the time you are reverting to. Any per-tenant extensions that were already installed will be available in the restored environment.

Other factors to consider before a restoration

Any AppSource and Business Central app in the restored environment will have the latest available hotfix installed automatically. This even extends to where the hotfix wasn’t available at the time of the point of time you’re transposing to.

Another thing to keep in mind is limiting access for users during a restoration period as well as putting all job queues on hold. Users can either have their access removed or the environment renamed. This prevents users accessing it using the old name.

The steps to restoring an environment

To restore an older environment, follow the steps listed:

  • You must be an admin firstly. Once established, proceed to the ‘Environments’ page.
  • Select the ‘Restore’ option.
  • In the Restore Environment pane, specify the period you wish to restore the environment to.
  • Select the type of environment you wish to restore.
  • Grant a name to the environment you are restoring.
  • Click the ‘Restore’ option. You can’t always move to the exact time slot intended. Where this is relevant, be sure to click the nearest available option.

After you have completed the previous steps, you’ll be able to click into your list of environments and this one should be set as ‘preparing’. It can remain in this state for several hours, but eventually will change to ‘active’. In the event of a restoration failure, the ‘Operations’ page provides details on what has caused this. To proceed, the failed environment will have to be deleted and then you can try again. Where this situation repeats itself, contact Microsoft Support.

It’s likely you will want to add in some missing data. This can be done using configuration packages or looking up data from the original environment. You can exceed the number of Production environments in exceptional circumstances, such as a restoration. The number of environments must be back within limits 30 days after the creation of the extra environment.

Name changes

We mentioned briefly that name changes will be a way to diminish the number of users in a system undergoing a restoration. This is because it changes the URL. Renaming should be done at a time when no users are active on the system. There are lots of factors to consider when going about changing the name of an environment. Here are a few:

  • The URLs saved as bookmarks or favourites on staff members’ computers will now be out of date.
  • You may struggle amending the URLs of partner-developed apps.
  • Any links to specific pages in the environment found in Teams, e-mails, Word, Excel will no longer work.

You may wish to rename the version you are reverting back to with the name of the current environment. At this point, you may wish to name the current system something like ‘OUTOFDATE’, or ‘DONOTUSE’.

Scroll to Top