I'm looking into migrating a couple of Property Editors in my package to v14. In v13 I had two different property editors with slightly different data, similar to this:

Person Picker
[{
 GroupName : string,
 PersonId : string
}]

Company Picker
[{
 GroupName : string,
 CompanyId : string
}]

I'm thinking that maybe I should merge them into one schema in v14, something like this:

[{
 GroupName : string,
 EntityId : string
}]

I guess I would need to create something that migrates the data and transform the stored JSON. Is there anyone who have made similar migrations when moving to v14 or that have seen any reading/examples around this?

uSync Migrate allows you to create your own custom migrators to transform data when you import it: https://github.com/Jumoo/uSyncMigrations?tab=readme-ov-file#complex-data-

@Jemayn Thanks, but not sure that I want my package to depend on uSync

You can do it in migration code, so when the site runs the first time after adding the version with the migration, it can finde all data types using your editors, and update accordingly. I had some trouble finding the right article in the docs, but heres an example of running migrations https://docs.umbraco.com/umbraco-cms/v/13.latest-lts/extending/database#using-a-notification-handler

There are also specific package migrations that are shown here: https://docs.umbraco.com/umbraco-cms/v/13.latest-lts/extending/packages/creating-a-package#custom-package-migration

Yep agree with Jesper & Soren that you could use a package migration to reshape the data as you need.

V14 package migration docs here.. https://docs.umbraco.com/umbraco-cms/extending/packages/creating-a-package#package-migration

Thanks! I'm using migrations for stuff like db-tables etc. so it make sense to put the code in a migratipon. I was looking to see if there is anything specific around moving data from one schema to another since v14 kind of merged many different property editors into using the same schema i figured that there might be inspiration out there on how to approach this.

https://github.com/umbraco/Umbraco-CMS/blob/contrib/src/Umbraco.Infrastructure/Migrations/Upgrade/V_14_0_0/MigrateDataTypeConfigurations.cs ??

Thanks @Mike Chambers ! 😄 I'll have a closer look at that file, seems like the "source of truth" for the thing I'm looking for.

Though the one thing I keep coming up against.. is that do these migrations, and then have to use the

INotificationHandler<MigrationPlansExecutedNotification>

to resave (dataype/doctype) as

migrationplans

will supress notifications.. Otherwise if you have uSync/umb deploy for instance to import on startup.. it will immediately overwrite/revert your changes as it didn't know the migration changed anything 😦

Ohh, thanks @Mike Chambers did not think about the uSync/Umbraco Deploy use case here. That's a great point for package devs, easy to handle in a individual project but probably more tricky for a package that migrates data. How are you making sure that the notification only saves the stuff "it needs" to?

csharp
 foreach (ExecutedMigrationPlan executedMigrationPlan in executedMigrationPlans)
        {
            foreach (MigrationPlan.Transition transition in executedMigrationPlan.CompletedTransitions)
            {
                if (transition.MigrationType == typeof(ImportPackageXmlMigration))
                {
                    return true;
                }
            }
        }

lifted from https://github.com/umbraco/The-Starter-Kit/blob/v14/dev/src/Umbraco.SampleSite/Migrations/PostMigrationNotificationHandler.cs after @Ronald Barendse pointed me in the right direction so can't take any credit ;-).. thread here https://discord.com/channels/869656431308189746/1245696446301208616/1246046623507812413

@Mike Chambers so why is the foreach loop above needed? Thought migrations deals with this so not sure what this code is trying to do/solve

migrations supress notifications by design, so if you alter a doctype, and have usync import at startup for settings.. usync doesn't get it's notification from the migration that the doctype has been changed, so usync config file is pre migration and then runs after the migration, reverting the migration change back to previous.

Ah OK interesting to know

It's by design though so that multiple synchronous package installs don't implode each other.. 😉 but is nuanced...