## 4 Proposed Migration Approach and Its Evaluation
### Migration Approach
#### 4.1.4 Data Transformation  
Once a microservice is created, the next step is to transform the data from a monolith database into multi-model polyglot persistence. The biggest challenge here is that both databases use different data models, so it is not possible to directly transfer data from one to another, it has to be transformed. The aim of this step is to create an application that can execute data transformation between databases. The proposed data transformation process is shown in Figure 5.  
The first sub-step is to extract everything needed to transform the data from a monolith database. A code that is able to read data from a monolith database and transform it into data models that represent the used data structure has to be written. The authors recommend creating a repository layer with a repository for each data table in a monolith  
Figure 4: An example of the function _GetCustomer_ implementation within the microservice layers. database. An example of the simplified repository and model implementations written in the C# programming language are shown in Figure 6.  
The _MonolithModel1_ is a model that represents the data in the _ModelTable_ data table. The _MonolithModel1 Repository_ has one method, _GetAllRecords_, which calls the generic interface _IDatabase_ that executes the SQL query to obtain all records from the specific table _ModelTable_ and maps the result to the defined model _MonolithModel1_. Finally, read-only access rights should be granted and firewall rules should be set up in order for the application to access the data in a monolith database. The purpose of the next sub-step is to transform the extracted data into a data model that is supported by multi-model polyglot persistence. As the data models and repository layer for multi-modal polyglot persistence have already been implemented in the third step, the code can be reused. Once both data models for the monolith database and multi-modal polyglot persistence are created, the mapping logic between models has to be implemented. Each field of each data model for polyglot persistence has to be mapped. The simplified example of the data model of multi-model polyglot persistence is shown in Figure 7. It is a combination of two data models used in monolith application. The _MonolithModel1_ and _MonolithModel2_ models represent two data tables in the monolith database and _PolyglotModel_ represents a document with the embedded sub-document _PolyglotChildModel_. Even though the given example looks simple and straightforward, in practice, mapping logic can be more complicated: the data model for the polyglot can be a combination of dozens of data tables, fields from the same data table can be part of many data models of the polyglot, data types for fields could be different, etc. The complexity of data model mapping strongly depends on the quality of the monolith database data model where a lower quality means a higher complexity. Figure 5: The proposed data transformation process. Figure 6: An example of the simplified repository and model implementations. The next action in the second sub-step is to create all records for polyglot persistence based on records in a monolith database. If we follow the examples defined in Figures 6 and 7, the number of records for the _PolyglotModel_ model should be equal to the number of records in the _Model1 Table_ table. For each data model of polyglot persistence, a main data table in a monolith database has to be identified. A simplified example of records creation is shown in Figure 8. The _PolyglotModelTransformer_ class uses _MonolithModel1 Repository_ and _MonolithModel2 Repository_ classes to obtain _MonolithModel1_ and _MonolithModel2_ records from the monolith database and passes these to the _PolyglotModelMapper_, which maps all of the fields and creates _PolyglotModel_ records. The last sub-step imports all records created in the second sub-step into a multi-model polyglot database installed in the third step. The authors suggest reusing the repository layer created in the microservice.