As the platform is maturing, more complex scenarios come out from the many companies using Business Central.
One of the requirements I came accross a couple of times was essentially what we used to have in the old NAV environment, where we were able to take a company backup in either Production or Sandbox and restore it in either Production or Sandbox, provided in BC world that:
a. all extensions are exactly the same and the same version, including the base app
* this can be checked with a composite check of all extensions involved
b. there is enough capacity available in the tentant to perform a restore from a company backup
c. if there are data security concerns, a check that would also validate the restore is performed only in the same SaaS tenant
I am sure the why will be answered if this idea fetches enough votes, let's focus on the how:
* we (the royal one...by that I mean Microsoft) will need to look at existing IP which can be easily transformed for this, topped up with the above checks and restrictions, the best tool to achieve this being right out the Intelligent Cloud engine, tweaked to work instead of OnPrem to SaaS, SaaS to SaaS.
What do you think? we could call it whatever you like, but I'd love to call it (Tenant) Company Backup with two options: Backup, Restore
Anything else? Nice to have, to make it widely used by company admins:
I would also like both the Backup and Restore to have a assisted setup to walk you through the Azure Storage setup.
* here you could add a first page with a link to something like this: https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/tenant-admin-center-database-export#setting-up-azure-storage
* then the second page with a field for the Blob service SAS URL
Kind Regards,
Robert
Comments
If you voted for this, you may be interested in the next one too: https://experience.dynamics.com/ideas/idea/?ideaid=96162047-dd19-ec11-b76a-0003ff457cd8
Category: Tenant Administration
Another thing to consider: cross company data.
If we move data from Prod2 to Prod1, what if Prod1 has tables that are not set to DataPerCompany, which means, they share data with other companies. What do we do then?
It might be a bit more complex than this answer (depending on the tables involved as well), but I came up with a possible solution below.
We can migrate the source that can be a snapshot, so we don't have the successive transactions problem (while we move data) in the source system and we could collate all tables with DataPerCompany = false, then present these in a Assisted Setup/Wizard type screen as follows:, presenting the user with options (per table) to either:
* merge the data in the new environment
* bring it through entirely
* not bring it through.
In this wizard/assisted setup step it would just go through this list and set the enum to the right choice for each table in the next step, if it is a
* merge, it would show each of the table that need to be merged in a dropdown and under the data that need to be merged and you can drag it from left to right (right being the target) by pressing a button and one button to move it back.
* copy it over will bring up the third screen where there are any conflicts if we want to bring the whole data from the source over in a certain table and options to keep one or another.
* for the third option, nothing to bring over.
Ideally an export of this walkthrough settings before hitting finish so you can import these at a later time if you want to do some prep work, reducing the time of setting this up when everything else is being copied over.
* Of course with a check that the data is still actual on Import.
Category: Tenant Administration
One more thing to add to the wishlist here is this:
* given it would work in the same environment, another user friendly option is to have a
Source Environment and Source Company (ex: prod2, Cronus NZ) and a
Destination Environment and New Company (ex: Prod1, Cronus NZ)
* This would remove the need to use any intermediate steps or Azure Storage resources and reduce the load on the tenant networking too, because the data can move in the backend local tenant SQL environment from one database to another.
Category: Tenant Administration