I would like provide an overview of current available technical migration paths to SAP HANA from an existing system running on anyDB; including the latest tool updates, several relevant aspects to consider and options during the actual migration.
(If you have not planned your HANA platform migration yet, better start planning soon; so you can take advantage of numerous SAP HANA Platform innovations designed to run your business much faster and simpler.)
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.
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:
If you are not confident of which optimization or parameterization you need to use during the migration; it is always better to perform a few test runs and try different optimization and parametrization methods.
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:
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::
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.
Have a look at the DMO phases below (this is from the SAP’s official guide):
Some effective use cases of DMO option of SUM:
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.
References and further reading:
There are great resources especially the ones written by boris.zarske and boris.rubarth I listed some of them below. Definitely read their articles before start planning your technical migration to SAP HANA.
http://support.sap.com/sltoolset
SAP First Guidance - Using the DMO Option to Mi... | SCN
Classical Migration to SAP HANA
How to decide between a Greenfield and Brownfie... | SCN
Migration to SAP HANA: Overview Video of Database Migration Option DMO
Migration of SAP Systems to SAP HANA
Decision Matrix to Choose Best Migration Option of ABAP Systems to SAP HANA
A better way to migrate your SAP NetWeaver BW from any database to SAP HANA
Software Update Manager (SUM): introducing the tool for software maintenance
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
9 | |
5 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |