You’re offline. This is a read only version of the page.
16
My company has been using unmanaged solutions for many years to deploy changes between our dev, test, and production environments. A new unmanaged solution is created for each sprint, changes are added to it, and it is deployed across each environment. Now, I'd like to move to a more controlled ALM solution using managed solutions and automated deployments with Azure DevOps.
To help reduce risk, I'd like to incrementally deploy a managed base solution, but I'm unsure if this is a good idea. To do this, I would like to add the custom entities we've created to the solution, one at a time, and push them up through production, then repeat with the next entity. So, if there were three custom, unmanaged tables (Table 1, Table 2, and Table 3), the first deployment would convert Table 1 to managed, adding in any required components, the second would convert Table 2 to managed, and so on.
Are there any pitfalls to this approach that I need to be aware of? The Microsoft documentation mentions adding all unmanaged customizations and deploying with a single solution, so I want to be sure I'm not backing myself into a corner in some way by slowly building up over time.
Thanks! I appreciate you taking the time with me on this.
Yeah, you're on the right track here for sure.
What I'd add is that when dealing with managed solutions it is the "stacking" where you run into complications, as opposed to the initial push; your second managed solution install has far more ways to go wrong than the first.
So instead of copying Prod before every release, copy it just once and branch into a Prod and a "Shadow Prod" where you continue to push to Prod for a little while unmanaged because that is safe and comfortable and you know what you're in for, but at the same time you push out a couple releases in a row managed to 'shadow prod'. With a bit of luck, you'll hit conflicts like mismatched publisher prefixes or dependency blocks or other failed imports that will let you get a sense for the quirks without ever putting prod at risk. Or, maybe your solution is just so well-managed and straightforward that you hit no issues at all, in that case you can switch to managed without any hesitation knowing you've really tested it out.
Beyond that, your headaches in the future will all be about cross-solution layering. So, unmanaged customizations on top of your managed ones; multiple managed solutions that have conflicts or overlap; things like that. For as long as you are monolithic, as you say, these issues will be rare. Just know the community is always here to help if you run across a nasty issue and need some advice!
@cchannon That's a great idea. I think pushing managed/unmanaged to dual environments would be a great way to build up the managed solution while feeling more comfortable about the eventual switch. It seems best to make a copy of production before every managed deployment, to ensure there will be no issues when the actual switch occurs.
Deployment Pipeline
Outside of needing to maintain a copy of the unmanaged solution so you can make changes in the future, and the potential issues that can come with layering and dependencies, what other pitfalls should I watch out for? I plan to start with a single, monolithic solution.
Ok, then before you start down this path, a bit of advice: be sure you are ready. Doing these entities one at a time isn't going to mitigate much risk for you because once you go managed on anything it is quite hard to go back.
I am strongly in favor of using managed solutions, but I have been doing it for years and I know the pitfalls. If you want to dip a toe in the water, I think that's a good idea but don't do it by going partially managed. Instead, make a copy of your target environment and go all in as managed in the copy, while changing nothing about your process in the real thing (unmanaged). Then go for one or two more releases like that and see how the two environments differ: managed to managed and unmanaged to unmanaged.
This will let you get a feel for it and mitigate risk by not actually touching production until you are totally ready.
@cchannon That was my understanding, what I saw from testing, and why I came ultimately went down this path. The benefits I'm looking for are risk mitigation (smaller, incremental changes to managed) and the ability to not have to switch over all unmanaged components to managed in a big bang. I'm a single developer on a medium-sized deployment and need to balance changing to managed with ongoing customizations + other commitments.
You're not backing yourself into a corner, but it does seem like you're creating a lot more work for yourself than is necessary.
When you import a managed solution with a given component (a table, for instance) and that component already exists in the target environment as unmanaged, Dataverse will automatically convert the component to managed (i.e. the managed solution always wins). This is true whether you are importing one, three, or twenty components at a time.
What benefit are you looking for by converting them to managed one at a time?
#1
stampcoin
17
#2
mmbr1606
15
Super User 2025 Season 1
#3
ankit_singhal
11
Super User 2025 Season 1
Share
Report
All responses (
Answers (
