Forum Discussion

SauravSarkar's avatar
SauravSarkar
New Contributor II
4 months ago

Data Migration Strategy : demerging one application to two new applications

Hi team ,

My client is demerging . So their current app has to be split into two new apps based on Entity structure. 

What is the usual data migration strategy that is used ?  My question is more focused on Data Migration : 

There are 4  sets of data : 

1. Data Corresponding to Origin Import : 

2. Data Corresponding to Forms 

3. Data Corresponding to AdjInput ( i.e Journals Data) ( Along with Journal Information )  - Do we need to pass the journals again to the new Application or is there a way to export ( can be done using DM but any other way ) and importing them back in ? 

4. Annotations 

What is the best practices around it ?  What are the things that one should take care about ? 

Regards,

SS

 

Methodology
  • Henning's avatar
    Henning
    Valued Contributor II
    4 months ago

    Hi, that very much depends on the requirements of your client. They can just extract the data and load it into the new solution using the import step in a workflow just like one loads historical data in any new project.

    If they want to be more specific as you are indicating, they can load journals as actual journals and load data to origin forms using BRApi.Finance.Data.SetDataCells(si, dataCellExs) (though this may be a bit slow, depending on your volume of data). This rule also lets you save strings on V#Annotation. If you want to go down that route, you need to write a rule that pulls the data from your extracts and saves the data and the annotations in the cube using the above function. Do not try that with a full data set, start small and then incrementally increase it. I am not aware of a corresponding Api function which would be more performant.

    You could also extract the data in Excel and "set" them from there in the new application to move data from O#Forms to O#Forms. This would be easy to do for their own admins if they want to do parts of it themselves.

    There are many ways to go about it and I think it really depends on each individual case, the data volume and the customer's requirements.