SAP Business Technology Platform (SAP BTP) is a Platform-as-a-Service (PaaS) offered by SAP. This platform enables the companies to become an intelligent enterprise, by combining their cloud and hybrid environments, using extension, integrations, analysis tools and so much more.
On the Business Technology Platform, two different environments are being offered by SAP: Neo and multi-cloud. SAP has been working hard in order to transform SAP BTP from proprietary technology into an open source-based, multi-cloud infrastructure. Within SAP’s multi-cloud first strategy, customers are encouraged to migrate to the multi-cloud infrastructure, as much as possible. It is not a jump that can be taken without any consideration and preparation.
What’s in it for you, what is SAP offering to assist in this migration and what exactly do you need to do? Let’s find out in this blog post!
There are a couple of advantages using multi-cloud instead of Neo:
But there is a fourth main reason, probably the most important one. Every once in a while, SAP adds a new service to the SAP Business Technology Platform (SAP BTP). Think about services like Intelligent RPA to automate manual tasks, Document Information Extraction to transform unstructured into structured data, Launchpad service as central gateway for all your application and extensions, and so on. SAP is adding those new services (and all future services) only to the multi-cloud environment. Existing services on Neo will still be available, but the service set on Neo will remain the same. In order to make use of the new services, a multi-cloud infrastructure is required.
The advantages of switching to multi-cloud are clear. But how do you successfully migrate?
There are three golden tips for a successful migration project: 1. For some services, SAP offers out-of-the-box migration packs. These migration packs are enablers to secure and speed up the migration process. 2. The migration process should not be a big bang. Migrate every application, service and integration individually, not all at once. Thanks to this step-by-step approach, you will learn from previous migrations and be able to adapt to new challenges. 3. The step-by-step approach goes hand in hand with the sequence in which applications, services and integrations are migrated. Start with an easy scenario, with few to no business process impact. This will allow you to gain experience.
The migration methodology can be visualized:
• Discover: Analyze all additional services and their dependencies. Get to know the ins and outs of the current environment. • Prepare: Set up the new environment, by creating a subaccount, subscribing to the relevant services, assigning user roles and creating services instances. • Migrate: Move the relevant content (apps, integration flows, etc.) from the current to the new environment. • Validate: Test the new environment with the migrated content before using it in a productive scenario. Use the validation to learn from occurring issues and possible fixes.
Generally speaking, the scenarios below need to be migrated from Neo to multi-cloud: • SAP UI5 • API Management • Cloud Integration • Cloud Portal service • Document Management service • HANA • Mobile services • Workflow management • … In order to give a more in-depth view on what exactly migrating those scenarios means, four of them will be discussed here: UI5, Cloud Integration, HANA and Workflow management.
Before diving in, it might be worth pointing out the differences between Neo and multi-cloud when it comes to IDE (short for Integrated Development Environment). The following table shows the differences between the Web IDE Full-Stack (Neo) and Business Application Studio (multi-cloud):
The Business Application Studio in fact embodies the multi-cloud first strategy from SAP, by providing developers with an adaptable, extendable, industry-standard and open source-based development environment.
SAP UI5 In the preparation phase, a new project needs to be created in the multi-cloud environment. Next to that, it is required to map user roles and user groups and to create the destinations used in the application. Once that is done, the HTML5 app can be exported and imported into the newly created project. The last step is to adjust configurations such as data sources, destinations and routes. One of the small changes, adjusting the routes, is shown below:
In comparison with other migration tools, XSK scores quite well. Especially when it comes to manual code modifications, usage costs and the fact that it is open source.
But XSK is more than a migration tool. It can and will also be used to maintain existing XS Classic apps, once they are migrated to the multi-cloud.
As is shown on Figure 3, it is clear that in a multi-cloud environment, a separation is made between the runtime and design time on the one hand (XSK running on Kyma), and the data storage on the other hand (HANA Cloud Service). It is not recommended to built new apps using XSK (in comparison with Business Application Studio, following CAP), but it is an excellent tool to migrate and maintain existing XS Classic apps.
When it comes to Cloud Integration, objects to migrate are prepackaged SAP content, custom artifacts, certificates, access policies, etc. To facilitate this migration, SAP has created a configurable Postman collection , together with a clear step-by-step approach indicating the sequence in which those objects need to be migrated.
There are however a couple of pitfalls that need to be taken into account. Sensitive data, such as passwords, are not migrated automatically. This means that after the actual migration, all passwords used in basic authentication need to be entered manually in the keystore of the new tenant. Migrating also causes the endpoints of the integration flows to change. This change needs to be reflected as well in the source systems and/or applications calling these endpoints.
The technical complexity of migrating existing workflows from Neo to multi-cloud is rather low since this is a quite straightforward process. Workflows can be exported from the current environment and imported into the newly created Workflow management instance. One of the points to take into account is the fact that authorization is managed with SAP Identity Authentication Service (IAS), whereas in Neo this is done in the BTP Cockpit.
The complexity lies however in the functional aspect of the migration, i.e. defining the cutover strategy. There are two possible options to choose from:
1. Hard cutover
On migration day, all existing workflow instances will be recreated in the new environment. The history of those existing instances will be gone, since every instance will be recreated with a technical user. Information such as creation date, created by and metadata of past approvals will be lost.
2. Transition period
In this softer approach, the current and new workflow engine will run next to each other for a certain amount of time. New workflow instances will be created and maintained in the new workflow engine, while existing instances will be taken care of by the current workflow instance. The advantage of this strategy is that the logs of the current engine will contain information of every workflow instance, from creation to closure.
Get inspired by our cases, news and the latest SAP insights.