Technology Blog Posts by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
thorebedey
Product and Topic Expert
Product and Topic Expert
3,429

Introduction

There are several reasons for migrating a Datasphere tenant. Some of them are: change of datacenter, change of SKU, integrating a DSP into a freshly created BDC instance. As of February 2024, there is no out of the box migration option for DSP. 

Recognizing this challenge, we have developed a specialized service that simplifies and streamlines the migration of a DSP tenant to a new environment.

 

Migrating a tenant

Sadly, there are limitations that prevent a migration via "button click". These limitations include: DP-Agent installation or re-entering credentials in migrated connections. These will remain manual tasks done by the customer. Nevertheless, our service can automize the migration of about 90% of the tenants content. This includes:

2025-02-28_09-20-06.png

 

There are currently topics that are out of scope for an automated migration either because of technical limits or because the manual effort of migration is very low and its not worth automizing. These include:

  • data migration for remote tables (re-initialization needed to ensure valid link to the source system)*
  • data migration for local tables that are targets of replication flows (re-initialization needed to ensure valid link to the source system)*
  • data marketplace content
  • most of Configuration & Administration topics (certificates, Monitoring settings etc.)
  • custom roles**

*even though this data cannot be migrated from the old tenant, we can automize the re-initialization so that no manual efforts are needed.

**custom roles in DSP are per definition global roles and cannot be created. Hence, these need to be created manually after tenant provisioning to ensure smooth creation of any scoped roles that depend on these custom roles.

Update: We can now also migrate tables from Open SQL Schemas, which was not possible before.

 

Technical foundation

For a full technical documentation of the migration service we would need about 20 blogs, so here I would like show one example and point out the technology used. For the migration, we use a script that we run locally to download the entire tenant to a folder structure. This folder structure contains everything that is needed to re-upload the content into the new tenant.

2025-02-28_09-38-17.png

Our script is coded in javascript and uses DSP's command line interface (CLI) wherever possible. For special scenarios, which are (currently) not possible via CLI (e.g. creating connections, schedules, data migration) we are using internal API calls.

As an example, we would like to explain how our data migration works. Here, we want to migrate all data from local tables, that are not targets of Replication flows. For this we need 5 steps.

  1. create a DB Analysis user in the source tenant (needed for step 3)
  2. screen all spaces for local tables that are not targets of replication flows
  3. if found, create a HANA connection to the corresponding space in the source tenant
  4. create a data flow for each table that points to the corresponding table in the source tenant
  5. run the data flow
  6. delete the data flow after the successful run
  7. delete the data migration connection

So if a space has 20 local tables we create 20 data flows. One could argue that transferring the tables in 1 replication flow vs. 20 data flows is easier but to use a local table in a replication flow, it needs to have a key column. To overcome this limitation to ensure also local tables without key columns can be migrated, we are using data flows.

For this scenario we use a combination of CLI (Step 4: data flow creation and Step 6: data flow deletion) and internal APIs (Step 1, 2, 3, 5 and 7).

 

Conclusion and Call to Action

We have been working on this service for multiple months to ensure a resilient and smooth transition to the new environment. This is also the feedback we got from the customers migrating with our service.

Furthermore we are ensuring that when provisioning SAP Business Data Cloud, we can help using an existing DSP tenant in this context as well.

If you are planning on migrating your DSP tenant (or you have a customer that wants to migrate), we are looking forward to align expectations and next steps with you!

Feel free to reach out: thore.bedey@sap.com, nils.henk@sap.com

 

 

6 Comments