12 things to include in your SAP cloud migration plan

The what, how and when of SAP migration planning

We have created a series of blog posts to make you understand what the key drivers are for your SAP to cloud transformation and how you can prepare best for the next steps to come, In this post, we will help you to plot out your next steps after you have understood your overarching business objectives.

1. What are the key drivers for moving SAP to the cloud
2. How to create an effective strategy when moving SAP to the cloud?
3. 12 Things to include in Your SAP cloud nigration plan

What

You can’t begin a migration without knowing what it is you want to migrate. This means getting an overview of the scope of the SAP and related systems that will be impacted. Things to consider here include:

1. Know which SAP applications, versions and enhancement packs are in use

Whether the migration is part of a broader business transformation or limited to a technical-only migration, it is likely that there will be some changes made to the application landscape to run in a cloud environment. It’s important to get an overview of all the SAP-linked applications, versions and enhancement packs affected by a migration to cloud plus the technical detail of upgrades that may be required for those applications to run in the cloud.

2. Know where your SAP version fits on the SAP support schedule

Making technical upgrades for support compliance reasons can be costly. When deciding to migrate SAP to the cloud, you will need to assess where the version you’re migrating is on the SAP support roadmap. If you are going to be updating your system during your migration, consider future-proofing it by upgrading beyond just mandatory platform requirements.

3. Third party applications and tools that form part of the SAP Scope

What other components form part of the SAP Migration scope? Attention is naturally drawn to the core SAP systems to be migrated but many organizations’ SAP landscapes are augmented by critical third party tools and applications that may present their own challenges in migration.

4. Identify integration points

What system integration points need to be maintained in the new cloud environment? Or, if adopting a hybrid or multi-cloud deployment, what new integration points need to be implemented and supported? Map the data flows between systems both in and out of scope.

How

The how part of a plan is where technical configurations and specific details are outlined. But some key considerations that fall under ‘How’ include:

5. How is support delivered?

Moving SAP to the cloud may require a change to your existing support arrangements. This could mean a reskilling of support roles internally or adjusting third party support contracts. Identifying this in advance makes it easier to adjust once the migration to cloud starts.

6. How will you secure your SAP systems in the cloud?

Is your existing SAP security posture - including processes and supporting toolsets - suitable for a move from on-premises to the cloud for your SAP systems? What, if any new threats could you introduce? What additional security measures are now available to you with your cloud solution and how will you implement them?

7. How much capacity do you require?

Unlike an on-premises environment, capacity can be scaled up or down depending on requirements. If your current data center is built for maximum potential capacity needed, you need to assess what resources you realistically need in the cloud, knowing that you can scale up for demand. This rightsizing means you can benefit from one of the biggest cloud promises – cost optimization.

An SAP cloud migration also offers the chance to declutter, consolidating supporting applications or tools and assessing what non-production workloads are needed in the cloud vs on-premises. By decluttering first before migrating, you can again optimize the capacity you require in the cloud.

8. How will you ensure business continuity?

The good news is that the cloud provides out of the box levels of resiliency and redundancy that most on-premises installations cannot replicate viably, making this part of your planning easier. Things like virtualization, availability zones, regions, failover capabilities, and backup services are among several cloud capabilities that you can take advantage of in designing the business continuity or disaster recovery plan.

When

Many organizations are aware of the 2027 end of support for ECC deadline, which is helping shape their plan timelines. But some other things to consider are:

9. Is there a business objective, strategy or program deadline that needs to be met?

You might be moving to the cloud because of aging data center infrastructure and the organization doesn’t want to incur CAPEX costs. Perhaps leadership has decided to follow a Cloud First policy and data center infrastructure or support contracts need to be renewed. Or a transformation project is underway and SAP in the cloud must form part of that. Whatever it is, planning well in advance is imperative as SAP migrations take time.

10. Will you have resources available?

Will the right users be available to support the project once underway or are you aware of constraints or conflicting projects that will compromise the proposed timing of the migration that needs to be adjusted for?

11. Are there critical periods of business that can’t be disrupted?

Your migration should be timed to avoid periods in which business outages caused by cutover activities can’t be tolerated, for example, your financial year end, seasonal production peaks or a critical merger. You need to assess what sort of risk and associated roll back/mitigation plans you need to allow for.

12. When will you conduct testing?

Do you understand the impact of change on the SAP environment and are you able to set reasonable expectations early on about the likely testing demands on the business community to successfully complete the migration?

Finally, in developing the plan, you should consider:

• The cloud migration strategy should always stand as the reference point to reconfirm scope or support decision making points.
• Try and dissect the project plan into shorter time frames so that success can be easily measured and regularly recognized. Afford yourself logical time out spots to take in what has been learnt and to adjust the plan if necessary.
• Don’t get wedded to an end state technology or design until the current scope is well understood and the migration considerations and activities are better understood. Shoe-horning an existing SAP solution into a predetermined end state can often lead to project overrun and even failure. It’s not a compromise if you plan for it.
• Do you need specialized skill sets to support the project and what role does your existing team play in the project? What does your support regime need to look like once migrated?