Hey all, Looking to adjust a property editor in the backoffice of our Baseline project, Originally this property editor was a simple Color picker in which we used the name and hex to generate a class to attach to sections of our website. We now are looking at adjusting this to becoming more of a "palette" picker utilising a Contentment Data List so that we can pull various other settings from a node within the backoffice (As well as being able to offer a custom picture via contentments ability to provide custom value labels). However I'm a little confused as to which route to go for and was hoping for some clarification. In this scenario, we intend to roll this out to a number of Umbraco Baseline Children and as such need to preserve whatever content choices have been made by the user's. This lead me down the path of looking how to achieve this and as far as I can see, there appears to be the options of either performing a migration on the projects, or having a property value converter to perform the change when a user interacts with the node that has the property on it that needs changing. (This was my basic understanding of it, apologies if this is not factual!) Essentially what I would like to know is which route is considered the "correct" way to swap one property editor to another, preserving the data on sites that can contain anywhere from 20 to 200 instances of this particular property editor.

Hi @Tom Chance, as with most things in Umbraco, there are a few ways you could tackle it. For a Baseline style project where the updates are going to be rolled out to the children... I'd be tempted to go with a [custom package migration](https://docs.umbraco.com/umbraco-cms/extending/packages/creating-a-package#custom-package-migration), (e.g.

PackageMigrationPlan

) to do this, then it'd been handled on each baseline child instance standalone. As for what would go in the migration step/state, (

PackageMigrationBase

), e.g. the bit that would convert the property value data from your (old) Color Picker to (new) Contentment Data List format (typically a JSON string array) ... well, that's up to you. (I don't have any code examples to share for that. 😬 ) Although maybe someone else has on GitHub? e.g. ...and then the custom migration would need to re-publish those content pages/nodes that have been updated.

Tidy thank you @leekelleher! Yeah just needed pointing in the right direction. Thankfully initially we intend to simply preserve the choice so the conversion of the Color Pickers Label to the Node Name used in the contentment data list should be simple enough to work out 🙂 Thanks for the direction ❤️

From what I recall, the main difference with the

IContentService

from v7 (and I say this with a very vague recollection) was how save/publish worked. In v7 I recall it being on the Content/Node object itself, but with v8+ it was done on the service itself, e.g.

_contentService.Save(content)

... at least I think that's the bit that kept catching me out back then. (but like I say, it's been a long while)

Yep thats what caught me out just now as well 😄 Cheers again! Have now created an "on save notification handler" of a settings node, in which the creation of a themes subfolder is performed with palettes underneath based on the labels from the sites respective Color Picker. So now onto this package migration!