As you all know, the focus in the ERP industry is to optimize the cost of ownership to manage the landscape. With this, it strategically shifted the client’s focus to “Core Business” and building domain capabilities.
Migration to cloud is one such aspect of cloud move to make the transition seamless.
Success of migrating SAP systems to cloud depends on meticulous wave planning considering the hybrid systems in most of the client’s environment with a mix of SAP and non-SAP systems. So it is critical that all systems planned for migration need to be analyzed from technical and business perspective and later to be aligned with key business stakeholders.
Cloud referred here can be any public or private cloud vendors.
Grouping is done during the preliminary stage to understand which all systems need to be migrated at the infra/db layer and later go in-depth on Business layer to understand the dependency, sequence etc.,
Broadly it can be classified into two level of grouping during assessment/planning phase.
Note - Above scenario applies ,if number of systems planned for migration is high enough, which can’t be handled using big-bang approach.
Thank you. I hope you enjoyed the blog and will help you in future migration planning.
Arun BP
Migration to cloud is one such aspect of cloud move to make the transition seamless.
Success of migrating SAP systems to cloud depends on meticulous wave planning considering the hybrid systems in most of the client’s environment with a mix of SAP and non-SAP systems. So it is critical that all systems planned for migration need to be analyzed from technical and business perspective and later to be aligned with key business stakeholders.
Cloud referred here can be any public or private cloud vendors.
Following are the Key design principles to be followed while forming the migration framework & waves.
Grouping
- Systems with minimal or no impact should be migrated first. Typically it may be Technical applications like GRC etc.,
- Proof-Of-Concept (PoC) of one of the Critical business system may be planned to make sure that there are no major migration related issues & get very high level view on business downtime, even though major outcome expected here is successful migration to cloud. with this, business can validate the “ways of accessing the cloud systems” which will help to get the view on network glitches, performance etc.,
- Initial waves to have simple/medium business applications with minimal cross interactions and followed by the rest
- Number of systems in the waves should be manageable
Strategy
- Approach should help to get the learnings (either PoC or technical systems) which can be incorporated to the future waves
- Shared system – Analyze the shared systems, if any which will integrate with ERP or S/4HANA based on usage, business criticality etc.,
- Duration of running systems partially on cloud & on-premise – This need to be considered as, some systems at any point in time may be partially migrated to cloud and rest on-premise till all waves are complete.
- Harmonize the target platform in case source has varied platforms.
- Non-SAP systems (if any) need to be migrated along with SAP systems, as they are integrated very closely.
- Migration Velocity :– rate at which applications get migrated to cloud. This includes various factors like availability of client SMEs for testing, skill set required, contract window available for the source data center exit, business complexity, projects in pipeline etc.,
SAP Systems grouping methodology for migration planning
Grouping is done during the preliminary stage to understand which all systems need to be migrated at the infra/db layer and later go in-depth on Business layer to understand the dependency, sequence etc.,
Broadly it can be classified into two level of grouping during assessment/planning phase.
- Infra/DB layer (Horizontal Cluster) – group by databases, group by multiple systems running on same hardware, multiple applications sharing the common database instance etc.,
- Business/Application layer (Vertical Cluster)
- Group by Technical functions – consider technical systems which bring minimal or no impact to business like GRC etc.,
- Group by Business functions – Portfolio of SAP /Non-SAP systems based on criticality and business dependency. Example – OpenText (IXOS) should be migrated along with ECC and cannot be migrated in isolation.
Note - Above scenario applies ,if number of systems planned for migration is high enough, which can’t be handled using big-bang approach.
Key considerations/learnings while performing the migration planning:
- Approach : - There is nothing like “Right” sequencing & wave formation made for a particular client, as there is no benchmark to base line. This solely depends on various factors from client to client. So this require a detailed analysis of the system usage, dependency etc., and decide on the right approach.
- External drivers - Sometimes projects timelines, number of waves etc., varies depending on exit date of the data center which will flatten the overall timelines in case project is not started early.
- SME Availability:- Availability of Key SMEs for testing is ignored many a times. This need to be considered though business impact is minimal in case of homogeneous migration.
- Plan for 3rd party scripts (if any) migration & interface strategy.
- Pre-requisite Steps:- It may be required to perform OS,DB upgrades/patches etc., as pre-requisite’s in the source system. So make sure, it is planned well in advance aligning with testing/validation team even though it is technical change.
Thank you. I hope you enjoyed the blog and will help you in future migration planning.
Arun BP
- SAP Managed Tags:
3 Comments
