I’ve already explained why the idea of migrating SAP system to public cloud is not science fiction anymore (click here if you did not read this post). Different hyperscalers proved multiple times that their ecosystems are secure, flexible and robust; what’s more, SAP has officially approved the public cloud infrastructure as a supported environment for their products. Numerous productive cloud implementations proved it’s just a valid, future-proof approach for any company dealing with challenges of keeping their SAP systems up-to-date. Especially with changes this ecosystem is undergoing at the moment…
But the question remains: what is the right path for migration? Is a simple lift&shift suitable for me, or should I consider full reimplementation of my systems? Well, the answear is – as in most complicated scenarios in IT – … it depends. Let’s see at what’s possible and why did I choose a specific scenario when creating my SAPonGCP project.
As you can see, there are quite some possibilities. Each of them can be valid for a specific business case and need to be carefully chosen based on throughout analysis of the customer current situation and future needs and plans.
The simplest approach is called “lift&shift” and it can seem very tempting at a first glance. Especially as GCP offers a service that handles most of the steps for you! Migrate for Compute Engine (formely a Velostrada service) uses streaming technology to minimize downtime and integrates with VMware vCenter for a consistent interface. Sounds too good to be true? Unfortunately, that’s often the case. You need to adhere to quite some prerequisites and limitations. What’s more, lift&shift moves the machines as-is, together with all the software versions, parameters, adjustments and workarounds from source. It simply makes is hard to clean up the system during the migration, not to mention it does not let you upgrade the system in place or make any other significant changes.
But isn’t migration to cloud a perfect opportunity to do some adjustments and changes to the current landscape? With support deadlines always at the horizon and SAP pressure to move to HANA and convert the systems to S/4, there are always some planned modifications ahead. That’s why lift&shift methodology is usually either ruled out or treated as an initial step to move the systems to the public cloud before some more serious modifications are made (like: move the system to GCP quickly and start heterogenous DMO migration afterwards, when you operate solely within the publick cloud).
TIP: remember to make a serious cleanup and data archiving before migration, especially when you move to HANA. Storage is inexpensive these days, but if the database is to be kept in memory (and needs license coverage for it), perspective changes a little bit.
All other methodologies presented above require you to provision and configure fresh systems within the public cloud realm before actual migration happens. From minor adjustments, heterogeneous migrations up to complete reimplementations (for example, with S/4 bluefield scenarios), you need to have target infrastructure ready beforehand. This is exactly why I chose to automate this part of the process, covering probably more than 80% of the use-cases.
No matter if you just restore a database to already provisioned system or use it as a target of a DMO migration, you need to have it in place. A specific OS flavour and version is needed; filesystem layout, virtual hostnames/IPs needs to be adjusted and – just maybe – they should adhere do SAP Adaptive Design (especially if SAP LaMa usage is planned in future). If you’ve moving to public cloud, maybe your approach to DNS, backup&restore or monitoring changes? If that’s the case, correct agents should be in place and configured on target VMs, while those from source should be discarded.
TIP: no matter what migration method you choose, don’t just copy&paste VM parameters (CPU + memory) from source. Keep in mind that on-prem sizing always tried to anticipate future (3-5 years) hypothetical growth, while sizing in public cloud realm should cover current needs with some small margin. Use the flexibility of the cloud and resize the system when needed!
Making the right decisions regarding migration approach is not an easy task that requires a considerable amount of experience and a deep dive into customer realm. Don’t just accept “easy” solutions like lift&shift if there are next steps ahead. Always plan the whole change cycle and automate most probable tasks that will happen in most cases. You’ll have a lot of challenges along the road anyway and it’s just worth to have the basic things ready in minutes.