SAP IDM 8.0 database migration now possible!

Switch your DB vendor and save on operational costs while preserving
all functionalities and historical data
A story by Todor Petrov

SAP IDM 8.0 database migration now possible!

Why a company will drop a software that took significant effort and resources to implement? Tolstoy famously said: “All happy families are alike; each unhappy family is unhappy in its own way.” His axiom seems to be equally valid for the relationship between an enterprise and its digital assets. Multiple reasons can lead to a growing disenchantment with an application and at some point, to the final verdict: divorce by decommissioning. Some of those are purely emotional, but most of the time it’s nothing personal, just business:
  • AGILITY - the software is not able to keep pace with the targets of the organization
  • PERFORMANCE - the competition seems much better in terms of functionalities and/or look and feel
  • MONEY - the cost of operation grew unexpectedly
  • KNOW-HOW - it is getting harder to find skillful experts to support it
  • RELEVANCE - certain digital innovations have made it obsolete, etc.

SAP Identity Management has seen its own share of broken relationships. Some existing customers were not happy with the lack of clear roadmap, others complained about the outdated UX, there were also some attracted to the promises of competitors, and those that thought it cannot support their journey to the cloud. The significant technical challenges that had to be overcome in the process of upgrading from version 7.2 to 8.0 only made the situation worse. On top of that, the upgrade did not offer the option to switch to the newly supported Sybase database, although there were customers who wanted to move away from their existing SAP IdM database mainly for cost-saving reasons. After all the difference between some of the supported databases (e.g. Oracle vs. Sybase ASE) is not something that “shines” on the expense sheet.
Talking to SAP IdM customers, I often hear tough questions that lead to any of the above mentioned points. For the customers, its “just business as usual”, but for me and the team at ROIABLE it is all personal – a personal mission to help them amend their relationship with SAP IdM. Some of the “counselling” sessions, were already posted in previous blogs:
SAP IDM is dead, long live SAP IDM!
The revival of SAP IDM
Upgrade of SAP IDM (not) for dummies

The positive vibes

SAP has changed course when it comes to IdM: its support has been officially extended to 2027 and a customer initiative program has been started with + 10 new functionalities/improvements this year and more in the pipeline for 2021. The clear message from SAP is that IDM is not limited by the confinement of on-premise versus cloud boundaries. Although running on-premise it can support a hybrid landscape with the help of IAS and IPS services on SAP Cloud Platform.
The outdated UX is a pain several consulting companies have already provided a pill for and ROIABLE is among them. The solution named ROIABLE IDM UX can run both on-premise and in the cloud and retains all existing Web Dynpro forms of the customer, not changing their logic, rather only rendering them as proper Fiori/SAPUI5 screens, thus delivering great user experience and improving the acceptance of IDM among its end users.
More about the facelift we gave SAP IdM can be found HERE
The database license cost-saving opportunity

Historically SAP IdM supported various databases, but a large share of the customers was running on Oracle. While it is still a solid choice from technical perspective, it is currently the DB with the highest license cost. The difference could be so big that just this one standalone can be used to justify a full replacement of IDM. During the lifetime of version 7.2 SAP provided a system copy guide from Oracle or MSSQL to MSSQL, Oracle or DB2, but such is not available for v. 8.0. Additionally, with version 8.0 Sybase ASE was introduced. It was a very different type of database and it was hard to provide a migration path out of the box. This, alongside the growing demand to host servers in the cloud, turned into a technical riddle that is not so easy to solve.
Moving the landscape to the cloud might look like a good reason to start clean and drop SAP IdM, for another IAM vendor, who seem to run and operate the cloud much more cost-efficient. Besides the fact that SAP IDM is equally strong player in the cloud field, there are at least two more reasons not to do that. The first is the data gathered during the life of the IdM system (e.g. historical data), which is required for audits and reporting purposes. The second is that the system is already up and running, repositories are connected, permissions are loaded, and processes are defined. To get all that with a new software in place is a project on its own with all typical risks and pitfalls as well as the potential budget implications.
ROIABLE already helped customers move away from Oracle to another database of choice. Yes, you can migrate your SAP IDM database without losing functionality or historical data. Additionally, the new landscape can be in the cloud or still run on-premise. ROIABLE has created a migration package that covers your needs: we take care of your new system setup, be it on-premise or in the cloud (e.g. NW installation, IdM installation, VDS, etc.), the follow-up configurations and of course migrating your existing SAP IdM database. Certain actions can also be executed by the customer’s service provider/own team if requested.
The migration itself requires in-depth knowledge in three areas - pure databases, table structures in SAP IDM context and specific SAP IdM knowledge. Without any of these you will probably achieve only a halfway result. Our approach ensures full transfer from the source to the target environment (e.g. undisturbed operation and access to data). Depending on the complexity and the number of IdM systems, a migration project can take about 3 months, which includes multiple stages of moving data, testing, verification, and adaptations.

MIGRATION SPECIFICS


One of the common challenges along the migration process is handling properly the connections between the objects in SAP IdM. As you probably know the table connection is based on an auto generated MSKEY, while the logical connection, which people can understand is based on MSKEYVALUE. Deciphering this dependency is the key to the puzzle. Moreover, there are multiple fields that are additionally encoded and stored in CLOB fields and such kind of fields tend to be handled differently by the various DB vendors. On top of that, just finding the right way to transfer them will not be enough, since some also contain important information, which needs to be relinked to the migrated key – e.g. audit logs with userid.

Furthermore, the most time-consuming task of the migration is related to the changes, which need to be applied to custom scripts and SQL statements, especially if they were using the native SQL capabilities of the original database (e.g. Oracle). One simple example is built-in SQL function TRIM() in Oracle, which does not exist in Sybase, where RTRIM() and LTRIM() should be used instead. 

PROD is taken as the single source of truth


We run the migration always using the productive system (PROD) as a template/single source of truth. With our approach the data from PROD is moved to a separate storage (e.g. sandbox) and from there we perform the first migration cycle, which builds up the new development system (DEV) of the customer. There we perform the needed tests and verification before moving to the next system in the landscape. If there is a quality system (QA), then it is again migrated from the production template, but this time, it is the customer who tests the results of the migration. In case the landscape consists of only two systems - DEV and PROD, then DEV is reverted to a clean state - e.g. clean IdM and NW install, and then the migration is repeated while again asking the customer to verify the results of the migration on the new landscape.
Only once the customer tests are completed successfully, we move to the real production system migration. Here we offer two options – full single load and delta historical load.
The full single load might require a longer downtime of PROD depending on its size and complexity. However, it is the simpler approach after which the new system is fully ready to be used as before without any limitations.
The delta historical load approach requires less downtime of PROD (within the typical timeframe of a weekend) since it transfers initially only the current and future-related data for all identities, repositories, approvals etc. This is the data that is mandatory for the system to operate properly. The rest of the data (e.g. historical data, audit logs, etc.) is transferred gradually over time in proper slots of no or low activity in the system. The complexity here is higher, but if the latter type of data is not critical to be available on the first day of the Go-live, then it might be the proper way for some companies.
One of the additional benefits achieved with the migration is that all IdM systems in the landscape are equalized in terms of configuration. Production data stays only in PROD while all other systems (e.g. DEV and QA) are wiped clean of it. DEV and QA can load their data from the repositories dedicated for them. In the meantime, the old landscape can be used without any limitations. Once the new landscape is ready for Go-live, the old one can be shut down. Newly developed packages that were not transported to PROD before the migration, if any, can be exported from the old and imported in the new environment, thus fully equalizing them.
A bonus benefit for all companies that go with our migration package is the full audit we will perform to their existing system. Performing in-depth analysis before the project starts is an important prerequisite in order to assess the variable of the migration, e.g. the percentage of custom scripts, the volume of data, etc. You can join the list of our successfully migrated SAP IdM customers by clicking on the button below and filling out our questionnaire.
REQUEST SAP IDM DB MIGRATION

© Copyright 2024 ROIABLE. All Rights Reserved.