Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Unmanaged Customizations to Managed Solution

  • 1.  Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 11 days ago
    Hi everyone,

    @Nicholas Arbour​​ asked a fantastic question the other day about adding existing components to a new solution and it got me thinking about something I've been wrestling with that I haven't had a chance to test. Does anyone have any experience adding existing, unmanaged components to a new managed solution, and if so, can you any lessons learned or things to watch out for? I'd like to take a bunch of customizations we've made over the past 8 years that aren't part of any single solution, bundle them up into a monolithic solution, and "redeploy" them as managed.

    A Little Background...
    I've been working on our Dynamics development "team" (just me now, was once me and one other) since around 2016. My company adopted Dynamics around 2012. When I first joined the team, all of our customizations were made directly to the default solution and moving from Dev -> QA -> Prod involved manually applying the same customizations as Dev in each environment. No solutions were used to bundle things up and make the deployment process easier. I don't know why things were done this way, but this is how things were done at the time.

    When I became a team of one, I started to look into ways to at least make the transport process easier and less error prone. I've been using unmanaged solutions for the past few years. For each sprint, I create a new solution (ex: Sprint 50), I apply my customizations to that solution, and them transport them between the environments when the time comes. This works well, but now I've got countless "Sprint XX" solutions applied to each environment. I clean things up occasionally by deleting some of the older sprint solutions. Since they're unmanaged, the customizations stick around.

    Now, I'd like to collect all of the customizations we've made over the years into a single, managed solution, that I can put under source control and automatically deploy using an Azure DevOps pipeline. I've done the same for another, newer, Dynamics-based system we have here and it's worked great. I'm just wary of doing this in the event that going from unmanaged to managed messes something up.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------


  • 2.  RE: Unmanaged Customizations to Managed Solution

    SILVER CONTRIBUTOR
    Posted 10 days ago
    Edited by Laurent Maneville 10 days ago

    Hi Steve,

    Going from unmanaged to managed is easy! Just export as managed and your done ! Moreover, With Azure DevOps pipelines, it is easy to automate export in unmanaged and managed at the same time. Then, when importing to a new environment, you could choose the manage or unmanaged version. This will also be very helpfull if for any reason your dev environment is lost.

    Maybe be a bit more carefull when importing this new big managed solution in another environment, do a first test in copy of the instance to check if everything is correct.

    I think that your greatest work will be to create the Big Solution! If you still have the previous sprint solutions (or perhars the zip files for the older ones ?), you could use the wonderfull "Solution Component Mover" from XrmToolBox to help you.

    In the future, you may consider using "Clone a patch" from your big solution to manage each of your sprints !

    Best regards,



    ------------------------------
    Laurent Maneville
    Nmédia
    Drummondville QC
    ------------------------------



  • 3.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    There are lots of opinions regarding managed vs unmanaged solutions on these forums!
    I would ask why with a dev team of 1, why you are considering moving to managed solutions?

    We used managed solutions when we started out here and eventually had to revert to unmanaged.
    For me, managed solutions are for:
    • Third party solution vendors
    • Complex and well managed environments - one where you can be sure no one will ever make any changes to production

    For small one, two dev environments, managed solutions are overkill that eventually come back to bite you (again - IMO).


    ------------------------------
    Donal McCarthy
    Digital Marketing Administrator
    BrightWork
    Galway
    ------------------------------



  • 4.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 10 days ago
    Hi @Donal McCarthy :)
    Just out of curiosity - why would the team size affect a choice of deployment method?​​
    (not trying to be sarcastic - I'm interested in the reasoning)

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------



  • 5.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    No probs @Jonas Rapp but it seems kind of obvious to me!
    The more moving parts there are, the more likely you are to benefit from managed solutions.

    ------------------------------
    Donal McCarthy
    Digital Marketing Administrator
    BrightWork
    Galway
    ------------------------------



  • 6.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    As a dev team of one, I'm considering moving to a managed solution because of the control and assurance it gives me that each of my environments have the same customizations applied. It also removes or reduces the urge to just apply a fix or change directly in each environment because it's "faster". Lastly, I may not always be a dev team of one.

    My end goal is to require that all changes move through a well-defined and easily auditable pipeline in Azure DevOps. I want to know what changed between each deployment and see a clear relationship back to a user story or bug report. I've got this working for a newer solution now, but need to go back to our (historically) less controlled environment and implement this process.


    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 7.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago

    I would NOT recommend going to manage, especially if you are the only developer for an in house solution. If you are selling your solution then managed is the only way to go. But for in house projects managed solutions just add unnecessary headaches. Remember that managed is an all or nothing deal. It is a lot easier to remove components in an unmanaged solution and VERY painful in a managed solution.

    And if you use patches, you are out of luck with managed.

    - A patch is created for unmanaged solution. You can't create a patch for a managed solution.

    https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customize/use-segmented-solutions-patches-simplify-updates



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 8.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 10 days ago
    Hi Rex,

    I'm not going into the managed/unmanaged discussion, but want to add a note to your statement about patches:

    The bullet you quote means you cannot create a patch from a managed parent solution​. So no, you cannot create a new patch solution in Test or Prod (where the solutions would be managed).
    You do however create patches for the unmanaged solutions in Dev that you would export as managed, and similarly you export the patches as managed to patch a managed solution in the target environment.

    The very next bullet states:
    - When you export a patch to a target system, you should export it as a managed patch. Don't use unmanaged patches in production environments.

    Distributing unmanaged patch solutions makes no sense, you might as well just create yet another unmanaged solution then to add changes to target environments. Managed patches have the advantage of "knowing" they are patches to a specific solution, so you secure the dependency in target environments and can utilize the Clone behavior when you want to wrap up all patches to a new version of the delivery.

    So regardless if you go for managed or unmanaged approach, patch solutions are only relevant for managed distribution.

    Then again - the original question was never if they should switch to managed approach 😉

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------



  • 9.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    Edited by Rex Kenley Tan 10 days ago

    Jonas

    How would one remove a component in a managed solution? If I have unmanaged, then it is a simple delete of the component. I still haven't found a painless way of doing so in managed.

    I have to disagree about the "insensibility" of unmanaged. We have a dev, stage, prd environment utilizing devOps. We have been using unmanaged solutions to promote enhancements, changes and patches between environments without any issues. Yes, there is more responsibility with managing the components, but at least we have that freedom without being bogged down by a managed container. Managed solutions would lock you down.  

    I know MS has been pushing for us to use managed. But it still doesn't make sense to me as to why we should do it for an in house solution with all of its restrictions with no clear benefits. I would appreciate it if you can provide any info that would cite these managed benefits.

    *****

    "I'm just wary of doing this in the event that going from unmanaged to managed messes something up."  - original post

    I may be mistaken, but I thought Steve was trying to find out what cost he would be paying for the benefit of not having to clean up old unmanaged solution containers.

    *****

    Found the answer to my primary concern, but how difficult is it to incorporate the process to devOps?

    https://www.henryjammes.com/2018/09/how-to-delete-components-from-managed-solution.html

    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 10.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    Unless I'm thinking of something different, it's fairly painless to remove a component from a managed solution, at least in the testing that I did. I find it far more difficult to remove a component from an unmanaged solution.

    Managed
    Delete the field, form, etc. from the solution.
    Publish the managed solution to QA.
    Publish the managed solution to PRD.

    Unmanaged
    Delete the field, form, etc. from DEV.
    Publish the solution to QA.
    Delete the field, form, etc. from QA.
    Publish the solution to PRD.
    Delete the field, form, etc. from PRD.

    For me, managed solutions align much better with how I think and how traditional software development and ALM work. I can be fairly confident that if version 1.X is deployed in Environment A and Environment B, then those two environments will have the same components and customizations applied as part of that solution. The same can't be said for unmanaged, because you can remove a component from the solution and forget to remove them from downstream environments.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 11.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    Edited by Rex Kenley Tan 10 days ago

    Steve

    Based on the article I posted, I think you are missing a few steps. The author specifically stated.

    If you try to delete one the components manually in production, you will get this kind of error, because the components are in a managed state.

    To which he then outlined the required steps to create a clone solution which you then merge with your target solution.

    1. Clone your solution (optional) and update the version number
    2. Delete the field, form, etc. from the solution.
    3. Deploy the clone managed solution to your target managed environment
    4. Apply the Solution Upgrade in your target managed environment (instead of just publishing)

    Repeat 3-4 for PRD.

    And you are correct about what you said about managed and unmanaged. But I think you will encounter some difficulty when it comes to DevOps. You need an Azure component that would do the managed upgrade merge (I don't think there is one yet) or you will have to write a custom powershell script to do the aforementioned steps. This is not a problem for unmanaged as the necessary components are readily available.

    https://github.com/WaelHamze/xrm-ci-framework

    Cheers!



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 12.  RE: Unmanaged Customizations to Managed Solution

    Posted 10 days ago
    Ah, the old debate over managed vs unmanaged.  Steve, I like your idea to implement an auditable pipeline for deployment, I think its a great solution to help you in the future.  I also share some of the hesitation around managed solutions, but will point out that with every version, Microsoft makes deploying and dealing with managed solutions more and more like custom code deployment, so I think ongoing you'll be ok.  A few notes based on this thread:
    1. To delete items from the system (i.e. actually remove a field from the database, for example) with managed solutions you actually have to follow a much longer process.  Dynamics will not remove something it does not find within a solution being imported, so your steps (delete the item from the solution then publish to environments) will not actually remove the item.  Rex lays out some added details there.
    2. We should be clear on when a solution becomes managed.  Everything in your development environment will always be unmanaged, because a solution does not become managed until it is exported as managed, and then imported elsewhere.  Once it is managed, then you cannot change it in the target.
    3. The limitations for internal use are real.  Imagine a situation where you do what you intend, build the big managed solution and re-deploy it to production so that everything there is managed.  You are having a fine time updating with patches or new managed solutions and life is wonderful.  But one day you decide that the development org could use a data refresh and so you copy your production down to dev.... and now all of your config is managed and you cannot change those solutions directly again.  To maintain this managed pipeline, dev must always be there (or you should keep unmanaged copies of your solutions in source control as well) because without the source unmanaged solution you can never again export the solution.

    I'm no DevOps expert, but could you create the same automated deployment pipeline with unmanaged solutions instead?  Gain the benefits of automation and traceability but keep the flexibility of unmanaged solutions?  Just a consideration!

    ------------------------------
    Merlin Schwaiger
    Director of Solution Design
    PowerObjects, an HCL Company
    Minneapolis MN
    ------------------------------



  • 13.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    I've been following the managed vs. unmanaged debate for what feels like years now and the cons have always scared me off until recently. It seems like the process has gotten better over the past few years!

    You bring up a good point about the 'ol dev refresh from production. That's something I hadn't fully considered, but I think would be possible to work around given that both managed and unmanaged solutions are being stored in source control. I'm using the SolutionPackager tool that comes with the SDK to export the solution in both formats, unpack them into a format that works well (better) for source control, and store that way. Deployments pull the "raw" files, package them back into a zip file (using the SolutionPackager), and then deploy to the target environment. For a dev refresh, it's possible that I could remove the managed solution and then redeploy from the unmanaged configuration in source control. I'd lose data (not a big deal since I don't have production data in dev and have only done a minimal copy back to dev) and it'd be a huge pain, but it would be possible.

    I also think your idea of unmanaged all the way through would work as well, with the downside that there could be some manual steps that need to be performed in each environment after a deploy, such as deleting components. It's not the end of the world, but maybe that's the better place to start. Less risk from a managed solution standpoint and I suppose I could switch to a managed solution at some point in the future should the need arise.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 14.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    Edited by Rex Kenley Tan 10 days ago
    If MS provides a tool to convert managed to unmanaged for the dev refresh scenario, I predict it would be ZERG RUSH to manage solutions ;)

    http://i.imgur.com/KJnk9.gif
    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 15.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 10 days ago
    Hi - I was referring to the statement around Patch Solutions, which I believe was misunderstood. Reading the quoted bullet alone can absolutely give the impression that you have to distribute unmanaged solutions to get the benefits of it, while it is actually the opposite.

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------



  • 16.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    @Jonas Rapp You may be right.

    @Rex Kenley Tan I've got a DevOps pipeline implemented using a managed solution right now that works quite well. In setting everything up, I made sure to test the removal of components and their effect on the downstream environments. I ultimately ended up using the following Powershell commands as part of my process to deploy everything.

    $existingSolutionResult = Get-CrmRecordsByFetch `
                  -conn $connection `
                  -Fetch $fetch

    Import-CrmSolutionAsync `
                  -conn $connection `
                  -ImportAsHoldingSolution:($existingSolutionResult.Count -eq 1) `
                  -BlockUntilImportComplete `
                  -MaxWaitTimeInSeconds -1 `
                  -ActivateWorkflows `
                  -SolutionFilePath $(System.ArtifactsDirectory)\drop\packedSolution\$($env:SolutionName)_managed.zip

    $upgradeSolutionRequest = New-Object Microsoft.Crm.Sdk.Messages.DeleteAndPromoteRequest
    $upgradeSolutionRequest.UniqueName= $env:SolutionName
                
    $response = $connection.ExecuteCrmOrganizationRequest($upgradeSolutionRequest)

    This post was the basis for much of the pipeline I configured. The things that post is missing that I ended up adding are:

    • -ImportAsHoldingSolution switch when importing the solution. This stages the solution for upgrade.
    • -ActivateWorkflows switch to ensure that plugins and workflows are deployed in the desired state.
    • The last three lines to execute a promote request that upgrades the solution, which removes any deleted components. 


    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 17.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 10 days ago
    Thanks Steve! :) Over 9k points for you!

    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 18.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 10 days ago
    Looks like you've got a nice setup there @Steve Platz that even MS solution platform gurus would approve of :)
    We know Wael's CI stuff has been around a few years, but have you tried the preview from MS as well?
    https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerApps-BuildTools

    @Merlin Schwaiger to your #1 I'd like to comment that yes, there is a quite heavy process to delete components. But the upside is: there IS a process that is supported even through CI/CD automation :) Going unmanaged, sure it is easy enough to delete something from PROD, but you have to do it manually... which not all governance policies approve of.
    ​​

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------



  • 19.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 9 days ago
    Hi Jonas, developers shouldn't be doing anything manually in production. Just because you need to delete something from an unmanaged solution is no excuse: script it up! I have 15 devs in three Scrum teams developing features in two branches (current production instance and our next big release). We have about 10 instances to manage so we script everything we can. Hardest thing to script so far has been the Data Export Service -- not even Wael had a good answer for that one.

    ------------------------------
    Neil Benson, MVP
    Customery
    Brisbane, QLD, Australia
    https://customery.com/blog
    ------------------------------



  • 20.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 9 days ago
    Keep it up, Neil Quijote 😊
    Completely agree there, I'm just lazier and cross my fingers (every time) that I can use the MS ALM strategy instead of inventing my own. Well I already did that, but that was before MS even had that story. Of course there are still gaps, like the DES.

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------



  • 21.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 8 days ago
    Thanks for the update Jonas and others,

    This thread is way above my payscale - so per the advice from Jonas, I've asked an ALM/PowerApps BuildTools expert from Microsoft to maybe provide some input as well.  Let's hope, enough peer pressure will summon the infamous @Shan McArthur to response to this thread and see what Microsoft thinks?​

    Cheers,
    Tony

    ------------------------------
    Tony Stein
    D365UG, GM
    Dynamic Communities
    Fargo ND
    ------------------------------



  • 22.  RE: Unmanaged Customizations to Managed Solution

    Posted 4 days ago

    There are a number of inaccurate statements in this thread and I want to shed some light on the topic and where we are going.

    Here is the official statement for the use of managed and unmanaged solutions and I hope that it helps add some clarity for the community: Unmanaged solutions are to be used in a development environment and to be exported and processed by Solution Packager to be checked into your source control system.  Managed solutions are to be used to deploy your solution to all other environments.

    Notice that at no point in that statement is team size, project complexity, or other dimensions a factor in the appropriate solution type.  It really is as simple as that.

    Deleting components is only possible through solution import actions if you are using managed solutions and if you use the stage for upgrade (or promote and delete) mechanic.  In the new UX, this is now the default behavior.  To delete a component, simply remove it from your solution in your development environment and export a newer version of your solution file (as managed).  Import that into your production environment using the stage for upgrade mechanic and the system will remove that component.

    We are making a lot of investments this year in making solutions more reliable and easier to work with.  We are adding many more components to solutions, cleaning up the UX, investing in making solution import a zero-downtime and non-disruptive experience, giving you better insights into layering, and the ability to undo active customization.  We are also shipping Azure DevOps tasks to help enable easy ALM automation.  ALL of our investments are based on the design of managed solutions.  Any advise to using unmanaged solutions for deployment is doing customers a disservice as it will put them on an unhealthy ALM path and will make it more difficult to use solutions and to automate ALM.  I find that most folks that are still advocating the use of unmanaged solutions are doing it because of their experience years ago and how difficult it was.  I would encourage them to refresh their knowledge and consider the proper way of using solutions to enable healthy ALM - whether they are a one person team or embedded in a larger project team.

    A quick checklist for everyone to self-assess your ALM health:
    1. You consider source control as your single source of truth and not a running environment.
    2. You check in your unmanaged solution files after they are unpacked using Solution Packager (or our unpack task in our DevOps tasks)
    3. You deploy managed solutions to all other environments (test, UAT)
    4. You run solution checker in your ALM pipeline
    5. All ALM operations are automated and do not require manual deployment steps to be taken
    6. There are no unmanaged changes in your production environment - all changes are brought through only using managed solutions.
    7. While you are developing a solution, your development environment will *only* have the direct managed dependencies installed and no other solutions, and you do not ship multiple solutions from the same environment.



    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------



  • 23.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 4 days ago
    Edited by Rex Kenley Tan 4 days ago

    Shan

    What does MS recommend in the "Dev Refresh from Prd" scenario? It should be easy to just restore the Prd DB to Dev, change the managed solution to unmanaged and be on our merry (following the recommended) way. This feature has been requested since 2011 and so far no official solution nor guideline was given.

    As I have stated before, this is the only thing that is keeping us from going managed. Thanks!



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 24.  RE: Unmanaged Customizations to Managed Solution

    Posted 3 days ago
    The refresh dev from prod scenario is an incredibly unhealthy way to look at the problem and will only drive more unhealthy ALM problems down the road.  If you have unmanaged changes in production, the way to fix this is to create a solution in prod, add the unmanaged components with customizations to it, then export as managed.  Rehydrate a new clean dev org, import your unmanaged solutions from source control, then import your unmanaged solution from prod.  This will ensure that the changes in prod will be the last ones made and will be on the top of the stack.  Add any new components into your dev solution, then export, unpack, and check into source control.  Your next build will deploy those changes to prod and you will be healthy from an ALM standpoint AND be using managed solutions as well.  You will pass all of my healthy ALM checklists I just shared.

    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------



  • 25.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted 3 days ago
    Shan, thanks for diving into the user group community and providing clear guidance.

    Can I ask for a couple of favours?

    1. Can Microsoft help the community understand the benefits of managed solutions?
    My teams have been criticised on a couple of projects by Microsoft Consulting Services for transporting unmanaged solutions to production. Using managed solutions is more complicated, and we've been unable to see any benefit from that effort. MCS has been unable to express the benefits either. Until we all can believe a convincing case for managed solutions, most partners and customers will continue to take the easier path -- unmanaged solutions.

    2. Can Microsoft provide better guidance and training on managed solutions?
    Microsoft Learn has barely any content on managing solutions (this is all I can find: https://docs.microsoft.com/en-us/learn/modules/use-developer-tools-extend/). Microsoft Docs has ambiguous guidance, including an option to not use solutions at all! https://docs.microsoft.com/en-au/dynamics365/customer-engagement/developer/organize-solutions. Managed solutions have been improved a lot over the last couple of years, but our knowledge is out of date and the learning content is out of date too.

    3. Can Microsoft commit to closing the ALM gaps?
    An enterprise Dynamics 365 project will have a bunch of solutions, Azure resources, integrations, and configurations that need to be transported across environments. I have two full-time devops engineers in my team to manage this. There are still gaps in duplicate detection rules, Data Export Profile configurations and other items that aren't solution aware. We prefer LogicApps to Flow because we're not sure how Flow connections would play in a solution. I'm excited to see the investments Microsoft is making in Dynamics 365 extensions for Azure DevOps, but since there is already a robust community toolset available, I'd rather Microsoft focus it's resources on the gaps that the community can't close itself.

    ------------------------------
    Neil Benson, MVP
    Customery
    Brisbane, QLD, Australia
    https://customery.com/blog
    ------------------------------



  • 26.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 3 days ago
    Edited by Rex Kenley Tan 3 days ago

    Shan

    The "refresh dev from prd" is not for the sake of solutions/code, but for the sake of having a dev environment that has production data. As you have stated, unmanaged solutions is for the dev environment. So a feature that would allow us to easily change managed to unmanaged after a dev refresh would be perfect. This would allow developers to code and test against real world data and have "very near production" results.

    This is a common practice in many erp systems like SAP. It would be nice if CRM has this feature as well.

    Thanks for taking the time on this subject.

     



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 27.  RE: Unmanaged Customizations to Managed Solution

    SILVER CONTRIBUTOR
    Posted 3 days ago
    Hi,

    I really don't like the concept of bringing prod data to a dev environment, this may include real persons private information. This could be done to analyse and correct a specific bug in a test environment, but for this, you don't need to have an unmanaged solution, once it's corrected, just make the same correction in your dev environment.

    What is interesting to keep is Configuration data that is not transported with the solution. In our ALM procedures in Azure DevOps, we export solutions and configuration data and both are put in source control, ready to import in prod environment.

    The tool to export/import configurations we use is available on the marketplace: Dynamics 365 Data Migration Tool

    We are now waiting for the new lincensing model with unlimited instances, we will be able to create as many dev instances as we like, just importing the unmanaged version of the solution and the configuration data from source control and we are ready to go!

    We havn't yet used managed solutions in prod environment, but with all the improvments from Microsoft on this side, and the improvment on our ALM procedures, I think we are ready to try it!

    Best Regards,

    ------------------------------
    Laurent Maneville
    Nmédia
    Drummondville QC
    ------------------------------



  • 28.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 3 days ago
    Edited by Rex Kenley Tan 3 days ago

    Laurent

    SAP shops have been doing this for years and they do scrub all private information as part of the refresh. You won't find any credit card information in a DEV environment (or they will FAIL the audit). Typically they would refresh QA from PRD, but there are situations where DEV needs to be refreshed from PRD as well.

    What we want to do is to have a dev environment that has "near production like" data to develop our solutions on. As some would say, why not use test data, I would ask back why not use prd data to test? Test data is a fantasy, while prd data is reality.

    Data Migration is a great tool! Although don't think of it as a full data migration tool, it is not designed for that.

    If you will, please share your experience with your migration to managed. Thanks!




    Ps. As to why SAP does this, I am going to quote delphix

    SAP landscapes: So fresh and so clean?

    ...These features enable enterprises such as Clorox, HP, and NASA to complete SAP projects dramatically faster, while using far less infrastructure.

    Adding to these capabilities is a new, joint solution from Delphix and Automic Software that addresses the challenges companies face when refreshing SAP systems. Teams have long relied on system refresh–updating non-production environments with data from a more current source–as a means of maintaining landscapes with data accurately reflecting the state of the business. Doing so translates into higher quality development, testing, and training.

    https://www.delphix.com/blog/application-development/delphix-automic-rewriting-rules-of-sap-refresh



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------



  • 29.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 4 days ago
    Thanks for this fantastic write-up! It aligns well with my understanding before posting my original question and with what I've been reading across the various D365 Blogs at Microsoft. I'm happy to read that I appear to be on the correct path regarding automating our ALM pipeline.

    Regarding #7, that's going to be difficult until our licensing changes, allowing us to have "unlimited" sandbox environments. ​We've only got a handful now and it's too time consuming to reset an entire environment just to install one unmanaged solution, modify it, and push it out. However, I see why this would be beneficial and it's something I'll aim for once we move to the new licensing model.

    Thanks again for taking the time to share your knowledge!

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 30.  RE: Unmanaged Customizations to Managed Solution

    Posted 3 days ago
    Some good news here:  the new licensing model allows for an unlimited number of instances that you can manage - within your storage allocation.  The healthy ALM patterns I am projecting including treating environments as temporary and short lived.  You should be able to spin up new environments, do some work on them, capture the change in source control, and dispose of the environment without having to worry about the number of instances that you are using.  Each CDS instance takes 512MB from your storage allocation and each CE instance will take 1GB from your allocation.  The allocations will be returned once the instances disappear.  This new billing model is available for existing customers as well - living within the total allocation of your current subscription.

    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------



  • 31.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted 3 days ago
    @Shan McArthur - we are all aware of the official party line. The fact that it doesn't mention ​"team size, project complexity, or other dimensions a factor in the appropriate solution type" is hardly surprising.
    Like @Neil Benson, I would really appreciate some solid reasons as to why we should use managed solutions, when experience has taught us that unmanaged is just easier.


    ------------------------------
    Donal McCarthy
    Digital Marketing Administrator
    BrightWork
    Galway
    ------------------------------



  • 32.  RE: Unmanaged Customizations to Managed Solution

    Posted yesterday
    The reason the guidance is not mentioingin team size, project complexity, or other dimensions as a factor of when to use managed versus unmanaged is specifically because those factors do not matter.  Unmanaged solutions are unmanaged configurations and are used in your development environment and to be checked into source control.  Managed solutions are to be used to deploy your solution to other environments.  Full stop.

    There are too many folks that think that we have two different solution types so that you can choose which one you are going to use.  This has never been the intent and is not the way that this should be thought about.  This type of thinking just leads to confusion and unhealthy ALM environments.

    Here is what managed solutions provides for value:
    1.  A managed solution can be uninstalled.
    2. A managed solution can delete a component as part of an upgrade.
    3. A managed solution can be patched.
    4. A managed solution can be maintained separately from other solutions
    5. Managed solutions are layered with each application / publisher being able to support that application separately
    6. Managed solutions are aligned to the strategic investments by the product team and will be best supported going forward.
    7. Managed solutions will allow you to have good ALM health.


    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------



  • 33.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted yesterday
    @Shan McArthur This all makes perfect sense and I want to move in that direction. Is there an easy way to migrate (or identify) unmanaged customizations that were made over the previous few years and package them into a managed solution? My initial thought was to work through each entity, find the attributes, customizations, etc. that contain the prefix we use, and add them to a new solution, but that seems like a lot of manual effort and there's a good chance that something will be missed. Is there a better way?

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------



  • 34.  RE: Unmanaged Customizations to Managed Solution

    Posted 22 hours ago
    @Steve Platz You are thinking about this correctly.  Yes, there is a way to do it via the SDK, but it is not easy.  The SDK will allow you to enumerate all of the components, and view their solution layers.  What you would be looking for are components that are unmanaged or have an Active layer on top.  Now for the 'easy' part of your question - it is on my wish list / backlog to give customers a feature to easily pick up and add 'customized' components to a solution.​ Once we get parity on the new modern solution explorer, newer features like this could be considered.  Until then, there are no restrictions on building a tool that uses our SDK to do this.

    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------