There are three main technical migration paths to SAP HANA. All of these methods have their own advantages and disadvantages compared to each other. My aim is to provide guidance and recommendation to plan your HANA technical migration using most effective approach for your business case.
Before starting I have to mention that all these methods (except maybe greenfield approach) would require a general technical planning and preparations such as;
In large scale productive systems, these steps may take several days to complete so it is crucial to plan your migration project properly.
The first and mostly used (so far!) approach for technical migration is classical migration which is heterogeneous system copy using classical migration tools such as SWPM, R3load, Migration Monitor etc.
There are three major steps with classical migration to SAP HANA:
Depending your business requirement and which SAP system you are planning to migrate, there are several optimization options available. Well-known downtime minimized option is available as part of the classical migration in case you don’t have a large downtime window (especially for productive systems), but with this method, the overall migration –usually– takes a bit longer.
For performance improvements and therefore reduce the total migration time, you may consider parallel export and import option (which is very handy in some cases!), and table/package splitting during the export for your source anyDB. Also, using extra application servers for export activity would also reduce your overall export time.
Personally, I would prefer to perform a migration test run, analyse the results and timing; then try to improve the performance by using convenient optimization options depending on the case.
Classical migration is a well-practiced method to bring your systems to SAP HANA; it has been widely used for years and the most mature approach out of three. On the other hand, it may have some disadvantages for specific cases especially in terms of flexibility and preparation activities. Yes, you may need to perform several preparation steps on your system for SAP HANA if you are performing classical migration. For instance, if your system is non-Unicode, then you have to perform a Unicode conversion. Also, if your SAP release is not supported by SAP HANA, you have to perform an upgrade first to bring it to a supported release then you can proceed with the migration.
In my opinion these are not show stoppers and even though it requires a bit of preparation and manual activity classical migration is still a solid choice.
Some effective use case examples of classical migration approach:
This method is basically performing a new installation on SAP HANA. There are two paths after building new system on SAP HANA; you can either choose to proceed with greenfield approach without changing existing solutions and processes or you can perform selective data migration to SAP HANA depending on your existing solution.
This approach allows you to consolidate your system and harmonize your master data as part of the migration project. It offers more flexibility compared to classical migration via selective data migration option (e.g. you can migrate only specific data of the last three financial years). It also allows you to correct possible design errors along with the opportunity to include new business processes within the new system.
Some effective use case examples of fresh installation approach::
DMO is an option of SUM (Software Update Manager) which combines system update, technical migration and Unicode conversion (if required) with an optimized migration procedure from ABAP-based SAP system running on anyDB to SAP HANA.
DMO of SUM helps you to avoid landscape changes (SID, host name) and allows the combination of all relevant steps for the in-place migration to the target database (Unicode Conversion, Update, and Migration) in one tool. It is a one-step migration procedure compared to classical migration approach. One tool to rule them all.
DMO option offers simplified migration steps (hence less error-proneness), reduced manual effort compared to classical migration, also reduced and only one business downtime period which can also be optimized/minimized depending on the scenario.
Also, database update of your source anyDB may be unnecessary, because DMO requirements for the anyDB version are reduced compared to the standard update.
More importantly; source database is consistent, continues to run and it is not modified therefore it can be reactivated with only medium effort in case of a fall-back. So it is a totally safe option.
Before starting I have to mention that all these methods (except maybe greenfield approach) would require a general technical planning and preparations such as;
- Housekeeping activities, removing obsolete data or archiving old data.
- Collect and update database statistics
- Perform consistency check for tables and dictionary objects.
- Operating system and database related checks and verifications.
- Parameterization for improved performance.
In large scale productive systems, these steps may take several days to complete so it is crucial to plan your migration project properly.
Classical Migration
The first and mostly used (so far!) approach for technical migration is classical migration which is heterogeneous system copy using classical migration tools such as SWPM, R3load, Migration Monitor etc.
There are three major steps with classical migration to SAP HANA:
- Perform an export of your source anyDB database
- Create your target system on SAP HANA via database import
- Perform post-load activities and additional configurations
Depending your business requirement and which SAP system you are planning to migrate, there are several optimization options available. Well-known downtime minimized option is available as part of the classical migration in case you don’t have a large downtime window (especially for productive systems), but with this method, the overall migration –usually– takes a bit longer.
For performance improvements and therefore reduce the total migration time, you may consider parallel export and import option (which is very handy in some cases!), and table/package splitting during the export for your source anyDB. Also, using extra application servers for export activity would also reduce your overall export time.
Personally, I would prefer to perform a migration test run, analyse the results and timing; then try to improve the performance by using convenient optimization options depending on the case.
Classical migration is a well-practiced method to bring your systems to SAP HANA; it has been widely used for years and the most mature approach out of three. On the other hand, it may have some disadvantages for specific cases especially in terms of flexibility and preparation activities. Yes, you may need to perform several preparation steps on your system for SAP HANA if you are performing classical migration. For instance, if your system is non-Unicode, then you have to perform a Unicode conversion. Also, if your SAP release is not supported by SAP HANA, you have to perform an upgrade first to bring it to a supported release then you can proceed with the migration.
In my opinion these are not show stoppers and even though it requires a bit of preparation and manual activity classical migration is still a solid choice.
Some effective use case examples of classical migration approach:
- Your system does not require any update to run on SAP HANA, and you only need to perform the migration; for instance, you need to migrate your BS or BW system to SAP HANA without any additional component requirement.
- Your system is SAP ECC 6.0 EHP7 and you would like to move to SAP S/4HANA Finance on SAP HANA. Because SAP S/4HANA Finance is not a huge upgrade and it is basically an additional component (Simple Finance 2.0), it would be better to perform the classical migration first and install SAP S/4HANA Finance component.
- Your source database is large and you can’t afford longer downtime. This is not actually a certain reason to choose classical migration; DMO option of SUM (which I will explain below) can be a better choice depending on business requirements and other migration requirements.
Fresh Installation on SAP HANA
This method is basically performing a new installation on SAP HANA. There are two paths after building new system on SAP HANA; you can either choose to proceed with greenfield approach without changing existing solutions and processes or you can perform selective data migration to SAP HANA depending on your existing solution.
This approach allows you to consolidate your system and harmonize your master data as part of the migration project. It offers more flexibility compared to classical migration via selective data migration option (e.g. you can migrate only specific data of the last three financial years). It also allows you to correct possible design errors along with the opportunity to include new business processes within the new system.
Some effective use case examples of fresh installation approach::
- You are planning to perform selective data migration.
- You are experiencing lots of technical issues with your existing system and would like to proceed with greenfield approach.
Database Migration Option (DMO) of SUM
DMO is an option of SUM (Software Update Manager) which combines system update, technical migration and Unicode conversion (if required) with an optimized migration procedure from ABAP-based SAP system running on anyDB to SAP HANA.
DMO of SUM helps you to avoid landscape changes (SID, host name) and allows the combination of all relevant steps for the in-place migration to the target database (Unicode Conversion, Update, and Migration) in one tool. It is a one-step migration procedure compared to classical migration approach. One tool to rule them all.
DMO option offers simplified migration steps (hence less error-proneness), reduced manual effort compared to classical migration, also reduced and only one business downtime period which can also be optimized/minimized depending on the scenario.
Also, database update of your source anyDB may be unnecessary, because DMO requirements for the anyDB version are reduced compared to the standard update.
More importantly; source database is consistent, continues to run and it is not modified therefore it can be reactivated with only medium effort in case of a fall-back. So it is a totally safe option.
Some effective use cases of DMO option of SUM:
You would like to combine your EHP upgrade along with technical migration to SAP HANA.
You want to migrate your non-Unicode system to SAP HANA.
You are running SAP NetWeaver 7.4 on anyDB and would like to migrate to SAP S/4HANA (edition 1511) on SAP HANA.
Classical migration approach requires you to update your source anyDB, due to reduced requirements with DMO, you may not need to update your database before the migration.
You have a large database and can afford only one downtime with possible downtime minimized capability.
In conclusion, there is no one-size-fits-all approach when it comes to migrating your system to SAP HANA. It is clear that DMO has more use cases and the most favourable approach by experts and SAP, the other two methods can also be the most effective approach for your own scenario. At the end of the day and it really comes down to your own scenario, complexity of your existing processes, requirements for the migration, business downtime affordability and your target release.
Source: scn.sap.com
No comments:
Post a Comment