Go for your quick win! Migrate Identity Provisioning tenants to SAP Cloud Identity infrastructure.

Migrating your Identity Provisioning tenant from SAP BTP, Neo environment to SAP Cloud Identity Services infrastructure brings key benefits.

Would you click the Migrate button when you read this? Or processes like update, upgrade, migrate – you name it, make you feel apprehensive about change no matter what the benefits are?

It’s a known fact that the fear of change is a fear of unknown. And, as scientists say, our brains find peace in knowing. How about getting to know migration better?

Why

We give you 6 reasons why it is important for you to migrate:

• Running Identity Provisioning (IPS) on a common infrastructure with Identity Authentication (IAS) tightens the integration between both services. These are not just nice words but a real advantage. Common infrastructure paves the way to common IPS and IAS features and one common administration console.
• Administrators of SAP Cloud Identity Services get simplified user experience. They log in once – either in IPS or in IAS administration console, and easily navigate back and forth. Features, like setting up SSO for corporate IdPs, enabling two-factor authentication and many others are just a click away.
• Almost all IPS connectors are enabled for your migrated tenant regardless of the obtained bundle. You will no longer go through tables in the documentation checking whether the connector you need is supported for your tenant. There are exceptions, of course, but you can count them on the fingers of one hand. See: Connectors Availability in Bundle Tenants on SAP Cloud Identity Infrastructure
• As of June 27, 2022, when migration was released, all new IPS features are delivered only for tenants running on SAP Cloud Identity (SCI) infrastructure. It’s a pity if you won’t be able to take advantage of the latest enhancements, such as: the Simulate job, the color-coded transformations and properties autocompletion, the possibility to run job through API, to download skipped entities for a job or to run a job on a specific day of the week, and there are many more to come.
• The migration itself is an easy 9-step process which automatically transfers your data (system configurations, like transformations, properties, destinations, certificates). Manual post-migrate steps are reduced to the very minimum.
• Last but not least, SCI is a stable infrastructure that’s been proven over time. For the record, IAS is running on the SCI infrastructure for years.

How

Before clicking the Migrate button, there are important things you need to know and prepare for.

Preparation

Before migration, define a time window for running it. The migration process might take considerable time to complete depending on the amount of data you want to migrate. Also, make sure that no provisioning jobs are running. Stop manually triggered jobs and pause the scheduled ones.

During migration, your IPS tenant will be disabled. Other administrators of this tenant won’t be able to perform any operation or system modification until it completes.

After migration, you will have access to your IPS tenant on Neo environment for 30 days. After that, the tenant is offboarded and cannot be restored. Although your Neo tenant will be available for 30 days, we recommend that you do not perform any operations on it, such as running jobs, adding provisioning systems and others.

Expectation

Here is our initial set up: In the IPS tenant on Neo, there are 3 systems (1 source, 1 target and 1 proxy). The source system has a modified transformation. The target system has an outbound certificate generated, while the proxy system has an inbound certificate imported.

Here is what you could expect:

• In your Neo tenant, the provisioning systems will be enabled.
• In your SCI tenant: migrated systems will be disabled; scheduled jobs will be paused; modified transformations will be migrated with status initial (regardless of modifications); the first provisioning job will run in Full Read mode, even if Delta Read is configured; inbound certificates will result in creating a technical user in IAS, connectivity destinations (if any) will be migrated as system properties. Only provisioning job logs are not migrated.

Procedure

1. Log in to your IPS tenant and select Tenant Migration.

2. Choose Migrate.

3. Select the target IAS tenant and choose Next Step. After migration, this will be the common SCI tenant where IAS and IPS service instances will be enabled.

The read-only details about the IAS target tenant are displayed. There is no existing IPS for the selected tenant. Therefore, a new IPS tenant will be created and your data will be migrated there. If Existing IPS was set to true, the existing IPS will be reused.

4. Select the Source Systems you want to migrate and choose Next Step.

5. Select the Target Systems you want to migrate and choose Next Step.

6. Select the Proxy Systems you want to migrate and choose Review.

7. Review your configurations and choose Finish.

8. Choose OK to confirm that you want to run the migration.

You are informed that your tenant is being migrated.

9. You are informed that the migration completed successfully. Choose OK.

Note: Once your migration completes successfully, you cannot trigger it again. Any data that you haven’t selected for migration, and you want to migrate as well, must be exported and manually imported in your SCI tenant within 30 days.

You are informed that your IPS tenant is already migrated to https://<ias-host>/ips on the SCI infrastructure and that the IPS tenant on Neo will be deleted on the given date.

What’s Next

You can start using your IPS tenant on the SCI infrastructure.

1. Log in to your IAS tenant with your admin user at: https://<ias-host>/admin

2. Navigate to Administrators, select your admin user and assign it the Manage Identity Provisioning role.

The migration process created a new technical user of type System – called PROXY. It holds the inbound certificate of the migrated proxy system.

3. Log in to your migrated IPS tenant. The URL follows the same pattern: https://<ias-host>/ips.

4. Open your source system.

Although its transformations were modified in the old Neo tenant, as you can see below…

… the modified transformations in the migrated tenant are with status initial, which means that you cannot reset them to an earlier version:

5. Open your target system and view that its outgoing certificate is migrated.

6. If all your data is migrated and everything is correct, return to your IPS tenant on Neo and disable the provisioning systems.

7. In your IPS tenant on SCI, you need to perform some manual post-migration steps, if you have configured the following scenarios:

• Proxy systems for integration with external identity management systems
• Real-time provisioning
• Connections to on-premise systems

For more information, see step 5 and 6 in the Next Steps section here:  Migrating Identity Provisioning Tenant.

8. Enable the provisioning systems and run the provisioning jobs in the migrated IPS tenant.

Note: The first provisioning job runs in full read mode, even if delta read has been configured. After successful full read, jobs with ips.delta.read set to enabled run as expected, that is, only modified data is provisioned.

This was a simple scenario with a small amount of data, which of course cannot reflect yours. Its only purpose was to let you know more about the way migration works. The more you know, the better prepared you are.

Watch this video for a detailed walkthrough!