Related issue: #2110 (Migrating a Block within a StreamField)
One previously proposed solution: #4755 (Add StreamField migration support)

At CFPB we have also developed some code for StreamField data migrations that lives here and is documented here. Our approach (which could certainly be improved upon!) tries to address migration of both the page itself as well as any historic revisions that also contain serialized versions of the StreamField data.

I'm taking this project, and gonna collaboratively work on this 👍

Progress so Far:

For now, we have decided to develop this as a separate package. https://github.com/sandilsranasinghe/wagtail-streamfield-migration-toolkit So far we've developed an approach which could be split into 3 parts:

• A process to recurse through different block structures and map data
• Operations that carry out the altering of the relevant blocks
• Querying and updating the changed data

For the recursion process we are working with raw JSON like data. We use the current block definitions to identify different types of structures (StreamBlocks, StructBlocks, ListBlocks) when recursing (for now we have not taken block definitions which differ from the actual data into consideration).
We use a block path (similar to the block path in the code in the cfpb link mentioned by chosak) to identify the blocks which contain the child blocks which will be altered and map their data. When we reach the block at the end of the block path we pass the value of that block to an operation which will handle altering the value as necessary. For example "stream1.char1" would match,

[
    { ..., "type": "stream1", "value": [
        { ..., "type": "char1" }, # match this
        { ..., "type": "char1" }, # match this
        { ..., "type": "char2" },
        ...
    ] },
    { ..., "type": "stream1", "value": [
        { ..., "type": "char1" }, # match this
        { ..., "type": "char2" },
    ] },
    { ..., "type": "foo" },
    { ..., "type": "foo" },
    ...
]

Operations are classes which have an apply method which will be called for all end blocks matching the given block path from the recursion process. This will contain the logic for altering the block value. We will be having a few operations available for from the package for basic/common use cases. We have the following for now.

• rename blocks
• remove blocks
• combine stream children to a listblock
• combine stream children to a streamblock
• move stream child inside a structblock
• move list child inside a structblock
• alter block value

Users will be able to define custom operations for any use cases they want, and we will try to include operations requested by the community as we go on. For example, the simplest operation which changes a block value would look like,

class AlterBlockValueOperation(BaseBlockOperation):
    def __init__(self, new_value):
        self.new_value = new_value

    def apply(self, block_value):
        return self.new_value

When querying data one important consideration is avoiding validation which can remove data which is not in the structure of our current block definitions. For this we're using an annotation when querying to get the raw json data straight from the database column completely avoiding validation. Afterwards a list of operations can be applied on the data with the above recursion process for each page. Note that any non page models with streamfields can also be updated.
For each page, all revision data can be updated or if needed revisions from a given date onwards only can be updated. With the changes in wagtail 4.0, we support any models with revisions to have their revisions updated when migrating stream data. Currently, this process is done by having a MigrateStreamData class which subclasses django's migrations.RunPython and handles the querying and updating. Pages and revisions will be updated in chunks with queryset.iterator() and bulk_update to reduce memory usage, especially for cases where there are large amounts of revisions. Usage will be as simple as creating a new instance with the app, model and streamfield to which changes are to be made along with a list of operations and block paths, and adding it to the list of operations in a migration file.This is the progress so far.

What we are looking to work on next include a management command to easily generate code for migration files, an autodetect feature to detect limited changes (rename and remove)

Initial version of package 0.1.0 published at https://pypi.org/project/wagtail-streamfield-migration-toolkit/ This is still in the early stages of development, so any feedback would be most appreciated. Note that work is still underway on improving the autodetect feature.