Also known internally as a “Run Once Job”, this job performs data moving as necessary for a particular Rock update/release.

1. Create a new Job in the Rock.Jobs namespace.
2. Add a new well-known Guid to the Rock.SystemGuid.ServiceJob class with the naming convention “DATA_MIGRATIONS__TOPIC” (e.g. DATA_MIGRATIONS_152_REPLACE_WEB_FORMS_BLOCKS_WITH_OBSIDIAN_BLOCKS).
3. Register the job to be run immediately on startup by adding its well-known Guid to the runOnceJobGuids collection within the Rock.Migrations.RockStartup.DataMigrationStartup.OnStartup() method. (Example as seen here)
4. Create a migration to add a new [ServiceJob] record. (This is the job you registered in step 3.) It will run on startup:
   1. The method AddPostUpdateServiceJob in the MigrationHelper class may be used to register the Rock Update Job. For example:

RockMigrationHelper.AddPostUpdateServiceJob( 
                name: "Rock Update Helper v15.2 - Replace WebForms Blocks with Obsidian Blocks",
                description: "This job will replace WebForms blocks with their Obsidian blocks on all sites, pages, and layouts.",
                jobType: FullyQualifiedJobClassName,
                cronExpression: "0 0 21 1/1 * ? *",
                guid: Rock.SystemGuid.ServiceJob.DATA_MIGRATIONS_152_REPLACE_WEB_FORMS_BLOCKS_WITH_OBSIDIAN_BLOCKS
            );

• If working in a hotfix branch, the migration should be added as a plugin migration (see the “Hotfix Changes” section within this codex).
• If working in the develop branch – or wherever the migration token currently resides – the migration should be added as a proper EF migration.