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

[ivelinakiryakov]

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 7 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: running test jobs (Simulate and Validate), using the transformations graphical editor and the properties autocompletion, running jobs through API, downloading skipped entities or running jobs 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.
• SAP BTP, Neo environment will sunset on December 31, 2028, subject to terms of customer or partner contracts. For more information, see SAP Note 3351844.
• 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!

[bcappez-2]

Hello Ivelina,

 

I migrate a small IPS tenant from NEO to CF but, in the end, it losts its subaccount, so the destination dropdown menu is now empty.

Now jobs cannot run and new systems cannot be added too.

 

Any clue on this ?

 

Regards,

Benoît

[ivelinakiryakov]

Hi Benoit,
I’m sorry for my late reply. Following the migration, your old Neo tenant is still connected to your Neo subaccount. However, your migrated tenant is now running on the SCI infrastructure, where there is no connection to your Neo subaccount.
The destination properties are migrated as connection properties in the new tenant so it is expected that jobs would be running normally.

Best regards,
Ivelina

[senthil17]

Thank you ivelina.kiryakova for the great blog, when we migrated we got the error message "Migration has failed, see the logs for details", but when we check the job log it says successfull.

can you please let us know is this common? I also referred the note 3281962 - its not relevant to us.

 

Thanks

[ivelinakiryakov]

Hi,

If your migration completes successfully, you cannot trigger it again. Can you trigger it again? If not, this is a clear indicator that everything went well.

I could only guess that this might be a wrongly displayed message.

Best regards,

Ivelina

[normann]

Hi Evelina,

thanks for that great block.

One question: Can you tell roughly how much time a customer would need to plan for the technical migration part. Is it taking around 5 minutes for one whole IPS tenant or will it be more and depending on the amount of systems maintained?

Thanks

Norman

[ivelinakiryakov]

Thank you, Norman.

I would say that it all depends on how many systems the customer wants to migrate. In general, it won’t take long.

First, identify the systems to be migrated. Second, stop manually triggered jobs and pause the scheduled ones, as described in the prerequisites section of the documentation.

Best regards,

Ivelina

[former_member119004]

Hi Ivelina,

Thank  you so much for the detailed instructions in blog.

As I can see in the screenshots you have provided , there is only one source and target system available for migration, But in our tenant ,we have 5 source and target system correspondingly for each other. So, if we decide to migrate our tenant to SCI, would these all source and target systems be available to be chosen for migration.

One more thing I would like to understand is that, if all the source and target system can be migrated to SCI at once, why would anybody would select only few source and target system for migration and go for importing for others from Neo to SCI. Just a question, I hope I am clear with my question.

also We would like to know more about features which are available only in SCI and not in neo.

 

Best Regards,

Vidya Kabadi

[ivelinakiryakov]

Hi Vidya,

Regardless of how many systems you have 5, 10, 20…they will all be available for migration.

Note that, once your migration completes successfully, you cannot trigger it again. Any systems that you want to migrate, but you've missed to select for migration initially, must be exported and manually imported into your SCI tenant within 30 days.

On your second question, let’s say you no longer want to support a given provisioning scenario and you run the migration without selecting the given provisioning systems. Later, you decide that you still need those systems. As the migration finished successfully, you cannot trigger it again. You can only migrate the systems manually.

Hope this helps,

Ivelina

[bo_wright]

Recent attempt at IPS Migration is showing an error with message indicating "SSl configuration setup error", and then an expired certificate. Existing IPS systems include SF, Embedded Analytics, and LMS

Is this something related to SSL Certificate renewal schedule, and a LMS cert that needs updating on the SAP side?

https://me.sap.com/notes/2533915

[GaneshS]

Hi @ivelinakiryakov ,

In the blog it is mentioned "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.".  Is this applicable when step 8 "confirm for migration" is run   or   is this applicable from Step 2, when we click "Migrate" button.

Thanks. 

[ivelinakiryakov]

Hi Ganesh,

Once you select 'OK' to confirm the migration (step 8), the tenant will be disabled.

Best Regards,

Ivelina

[GaneshS]

Thanks for the confirmation Ivelina 🙂

[shindemahesh_81]

Hi Ivelina,

Thank you for sharing the informative blog on IPS Tenant Migration. I have couple of point to understand on migration of 1 IPS tenant.

1. How much time will take for Migration from Neo to Cloud Foundry.

2.Any down time is required for Neo or Cloud foundry during migration.

3. Any other system gets impacted during migration.

4. Do we need to select target location for migration or it will select automatically.

Please provide your comments on above point, it will be great help for me.

Regards,

Mahesh

[13960]

it seems the screen cap is not displayed correctly or is it just me ?

[Sword_mb]

I am not clear on several points.

1.  What impact does this have to the existing IAS tenant set up, including corporate IDP's, groups, etc,?

2.  My understanding is that the IPS rules are more restrictive in cloud in the sf.user.filter, such as not being able to filter out multiple specific users.  Is there a place we can look for specific information on the filters?

3.  What is the biggest time determinant on how long this process will take?

[ivelinakiryakov]

Hi,

1. Migrating an IPS tenant to SCI infrastructure does not affect the existing IAS tenant setup. This process only enables the IPS tenant and migrates the provisioning systems.

2. Filtering SFSF users is described in https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/list-of-properties -> sf.user.filter

3. The biggest time determinant for how long this process will take is the number of systems and provisioned entities the customer wants to migrate. The more systems and provisioned entities involved, the longer the migration process will take.

[Tim_ms]

Hi Ivelina,

when starting the migration IPS neo to CF we got a 401 error:
Job threw an unhandled exception. [See nested exception: Request failed with status: 401 and body: {"origin":"SAP IPS","error":{"code":"Unauthorized","message":""}}] Caused by: Job threw an unhandled exception. Caused by: Request failed with status: 401 and body: {"origin":"SAP IPS","error":{"code":"Unauthorized","message":""}}

We cannot find any additional Information anywere in IPS Neo or CIS CF. All users seem fine. When trying to migrate again when selecting the the "Identity Authentication tenant" we get "Internal error. Contact your system administrator." Again no additional information can be found. Do you have an idea what the issue might be? 

[uwe_pryka]

Hi Ivelina, it's a pretty cool blog and you are absolutely right, the fear of change ist fear of the unknown, basicly. If you are running only a few cloud services or systems for a while and the time to migrate comes nearer, your IdP comes within a bundle, maybe WEBIde , maybe Sales cloud, maybe SAC, not sure with which, you only have a few apps, let me say Jam and SAC active, AD inactive, it seems to be easy and fast done. But if you have a look in IAS, the JAM entry is already there, obviously, I'm not really sure why, what's the reason and, that's the main point! What will happen, if I want to choose to migrate Jam too? 1 Source, 1 Target, 0 Proxy. 

Thank you very much

Kind Regards

Uwe

[ivelinakiryakov]

Hi @Tim_ms,

You most likely need to open an incident and report the error.

Best regards,
Ivelina

[ivelinakiryakov]

Hi @uwe_pryka,

Thanks for the feedback. 

What exactly do you mean by 'JAM entry is already there'? Is the Identity Authentication tenant, where you intend to migrate, configured to provision users to SAP Jam in real-time?

Best regards,

Ivelina