This blog post talks about some specific issues that We faced at a customer who was migrating attribute,analytical and scripted views to Calculation views and Table functions respectively. The below points should be considered for successful migration of the artifacts.
Migration from Attribute and analytical views to Calculation views
When using the migration tool, analytical views with star join are converted to calculation views but if you have a star schema in analytical views then following steps need to be considered
1) Delete the calculated columns in the star join node of the analytical view and redo the calculated measures after conversion to calculated view. During our migration project (we were migrating from HANA sps11 to Hana sps12) we faced inconsistent measure values after conversion but were able to resolve the issues following the above technique.
2) if you are trying to materialize the view which is not recommended but still never materialize the calculated measures. All the calculated measures should be calculated at the topmost aggregation/star join node for optimum results.
3) the attribute/analytical view can give you inconsistent result if the joins on columns have similar names and they are keys in the table. For example in our situation we were converting material attribute view which had MARM and MARC tables. While joining it was propagating MATNR from MARM but in the original attribute view the MATNR comes from MARC. Our issue was resolved when we manually changed the calculation view and changed the join and took MATNR from MARC table.
Migration from scripted calculation views to graphical Calculation views
– attribute and analytical view in scripted calculation views give you the worst performance and maximum improvement in memory consumption and performance can be leveraged after converting each attribute and analytical view that are used in the scripted views. Never use a scripted view with attribute/analytical view. Although not recommended but attribute and analytical view in calculation views do not cause a huge performance issue so can be used if the conversion effort is more but they should be converted to calculation views if a scripted calculation view is involved.
– Do not use a star join for only two tables/views. Significant performance improvement in terms of reduced memory consumption was observed on converting from star join to aggregation node with two tables/views only.
the blog does not talk about the process of migration. Please check below links for migration process