Dataverse changes when updating a solution in dev / test and moving to production

[vonventti]

I have a solution in power platform which consists of a couple of model-driven apps and a couple of dataverse tables. 

I was wondering, if I want to make some updates / modifications in the apps which requires me to add or delete some columns in the dataverse table it refers to, what happens when I import the modified solution in the production environment. Does the modified solution simply overwrite / delete the data that was already in the dataverse table in the production environment if the modified solution does not anymore have this column? I'm a bit confused relating to this since I would like to potentially make some changes to the apps, but would not like to alter the data that the users have already inputted in the production environment.

Also if I just make changes to the apps without touching the dataverse tables, I assume that when I move the solutions from dev to production environment, it will only mirror those changes I made in the apps and leave the dataverse tables untouched, with the original data left in them in the production environment?

Thank you for your answers!

[parvezghumra · Accepted solution]

@vonventti Am I right in thinking that you already installed an initial version of your solution to your Production environment? Is it installed as unmanaged or managed?

In summary if your solution already exists as unmanaged in your Production environment (not recommended), and your next version attempts to update the unmanaged solution with a new unmanaged version of the same solution, only additive changes will take effect. Any columns or other components deleted from version 2 of the solution, that existed in version 1, will not be deleted from Production as a result of the update to version 2 of the solution in this scenario. This is because unmanaged solution installs/updates are additive only, meaning only addition of new components and updates to existing components take effect. Deletion don't take effect.

If your solution was originally installed as managed, and the updated solution is installed and upgraded as managed too, then all changes should take effect, including addition of new components, changes to existing components and deletion of existing components. The upgrade process will delete any components that are not present in version 2 of the solution that were originally in version 1 of the solution (as long as no other solution maintains a reference to such components).

[ravdemo]

Which is a best practice of customization: do we need to import solution into sandbox environment as an unmanaged solution from production environment and then after export as a managed to production environment? Should a clone to patch and clone a solution is better option? will all the records created by a user in production during our time in customization and upgrade to newer managed solution will be lost or will stay?? Thank you 

[parvezghumra]

@ravdemo Best practice states that all customisations should be made within an unmanaged solution in the dev environment, this should then be exported as managed and imported into non-development (ie. test and Production) environments.

Patches are no longer recommended for use by Microsoft. They were originally introduced into the solution framework in order to optimise the deployment experience. But now that they have significantly improved the performance of managed solution deployment and because patches introduce unnecessary complexity, their use is no longer recommended.

The upgrade of a managed solution in a non-development environment can only result in the loss of data when the new version removes any schema (tables, columns, relationships). For example, if a table component is removed in the new version of the solution, the upgrade will result in the deletion of all data in that table in the target environment. Likewise, if a column is removed in the new version, the upgrade will result in the deletion of all data in that column in the target environment.

[ravdemo]

Thank you.

Just wanted to make sure....If I have to make changes to system views and import some data into a table. Then, I will have to do in development environment by making a separate solution and importing the app in this solution. Make changes here. Then, publish and upload this as a managed solution to testing environment and then to production. Am I correct?

Thank you

[parvezghumra]

@ravdemo You don't necessarily need to create a new solution. You can work in an existing unmanaged solution in the dev environment, make the necessary changes within the solution, export as managed and then import as upgrade in the Test and Production environments when ready.

Data cannot be included into a solution and so cannot be moved across environments using the Solution Framework. You can do a manual export of data from your dev environment and import into Test/Production (when the necessary schema is available there), or use tools such as the Data Transporter within the XrmToolbox, Microsoft's Configuration Migration Tool, or build your own SSIS packages using the KingswaySoft connector.

[ravdemo]

Thank you, It was very helpful.

[vonventti]

Hi @parvezghumra,

Thank you for your answer, it clarified this for me.

In my case the solution is installed as a managed solution in the production environment and unmanaged solution in the dev environment, which I intend to use if some changes are happening, and then import it as a managed solution in the prod environment once those changes are made. However, I don't think I will be doing any deletion / adjustments into the tables themselves if the managed solution then overwrites them with the latest changes it has, as you said. Or at least make sure that the data is backed up and can be retrieved in case any changes need to be made to the tables.