Image by Liv Hema

MIGRATION

Migration does not happen overnight – it is series of smaller journeys before reaching your destination.

Migration Inputs

 

There are two phases that feed into the migration:

  • Discovery. At CLOUDWRXS, we undertake a full assessment and discovery of your existing environment. This enables us to understand your application and environment inventory, identify application dependencies and requirements, perform total cost of ownership calculations and establish performance benchmarks.

  • Design. We will create the basic cloud infrastructure for your workloads to live in and plan how to move apps. This involves identity management, organisation and project structure, networking, organising apps, and developing a prioritised migration strategy.

Designing for success

Strong architecture and design are the roadmap that will help you navigate your migration journey from Point A (your existing infrastructure and environments) to Point B (going live in the cloud).  

 

During the design phase, we’ll help you put the building blocks in place to support your cloud native architectures. 

 

From a functional perspective, there should be little or no change to the design when migrating applications to the cloud. 

 

But since cloud infrastructure has very different architectural constraints, we must also consider the potential impact on performance, scalability, high availability and security during the design phase and take steps to ensure none are compromised.

 

Good architecture and design mean a cloud native system should be largely self-healing, cost-efficient, and easily updated and maintained through automated processes and DevOps procedures such as Continuous Integration/Continuous Delivery (CI/CD).

 

As a Google Cloud partner, we align ourselves to the Google principles for cloud native architectures:

  • Principle 1: Design for automation

  • Principle 2: Be smart with state

  • Principle 3: Favour managed services

  • Principle 4: Practice defence in depth

  • Principle 5: Always be architecting

4-types-of-sap-migration.png

The cloud-world is always changing and the technologies powering it evolve. While the principles above are no magic formula for creating cloud-native architecture, they provide strong foundations for those who want to get the most from it. Moving and adapting architectures for cloud is also an opportunity to improve them, so they can more easily adapted to another environment.

The four patterns of SAP Migrations

  • Pure Lift and Shift. We move what a customer already has to the cloud, ensuring the technology is merged with the best Google Cloud Platform features to reduce operational expenditure, without addressing business change. This can be a good starting point for those who plan to start transformation once the cloud migration is complete.

  • OS/SAP. If we are undertaking a full round of business testing, it may be a good time to make changes to applications – especially if the business has fallen behind on recent updates to their stack. We’ll help you identify the areas that may change with an application upgrade.  Updates to the database or OS stack will bring the most recent security and performance updates as part of the migration.

  • DB UPG.  Migration from an on-premise or a co-lo data centre to Google Cloud may require a database change if older technology is in use, such as Oracle. During the discovery and design phases, we’ll identify any changes required with a plan on migration to database technologies to SAP HANA or DB2.

  • S4/HANA. Many businesses are preparing for the 2027/30 shift of SAP focus to a standardised application and database technology partnership. This means a migration may include an application and database update, so you benefit from one testing cycle to cover both options. While this takes longer, it can easily fit into an existing upgrade plan.