Recommended approach for Data Migration

We are currently working on the topic of document migration. Here we want to establish a uniform process that clearly records the tasks for developers and model customizers. The procedure should be as simple as possible.

We build on the data migration described in the documentation here.

2 possible scenarios are to be implemented soon:

  1. a field is deleted
  2. a group is added

A concrete problem leads to our question for a best practice approach:

In Scenario 1 we remove the field from the model and write a MigrationStep to then delete the field from all documents. The new model is imported at service start, after which the migration runs. No matter what features of the A12 framework we use to manipulate the document (DocumentConvertor, DocumentSerializer, DocumentQueryService,…) - we cannot map the XML stored in the structure of the old model into an IDocument, since the field in the documents still exists, but is already missing in the associated model. Every approach leads to an exception.

approach 1
Each model change is stored in a new model file (possibly including the form model) in a subdirectory of the import directory and read in by the corresponding MigrationStep. In this way, we can still work with the imported “old” models during document manipulation, manipulate the documents and then import the new model. However, this leads to a certain overhead - many files, new work process. Also, this approach requires additional details to be thought through (since every change results in a new model file).

approach 2
We dispense with large parts of the framework that closely couple the model and document and implement our migration step at a low level. Means we read the XML content, manipulate it on the XML level and write the content back. In this case, the new model could already have been imported without causing errors. However, the migration code would be more error-prone, very strictly linked to the model, and this approach would feel like undermining the entire framework for handling documents.

In both approaches we have to reindex (SOLR or Lucene). Any advice how to do this?

Which is the preferred approach? Or is there a 3rd and better one? How does MGM implement migrations of this type and are there current examples or best practices for implementing our example scenarios 1 and 2?

Hi @mathias-early-ravine ,

We recommend to do the migration in steps:

  1. Migrate models
  2. Write migration steps using DocumentAfterRepositoryLoadEvent event. This event is fired after the document is loaded but before it is deserialized. So this is your chance to change the document. The migration needs to work on the XML (or other format if you are using extensions) because the new models should already be used.
  3. Start server where the models are loaded and custom migration is executed.

An example how to do that can be found in our git respository for version 2023.02 please use branch release/35.0 : examples/examples-dataservices-init-app/src/main/java/com/mgmtp/a12/dataservices/example/migrations/MigrationStepFour.java?at=refs%2Fheads%2Frelease%2F35.0

Example shows that documents can be migrated one by one and the index can also be rebuilt model by model. You can also migrate everything in one migration step(if you prefer one transaction) and rebuild index afterwards.