The preferred path to the release 7.1 of SAP Solution Manager is in most cases -as discussed in the previous blog- the upgrade of the existing system . It removes hidden costs and allows to leverage existing master data (logical components, iBase/Components, User Master Records, Business Partner Master Records etc.). Nevertheless, an upgrade also means radical changes in the CRM engine powering IT Service Management (ITSM) and Change Request Management (ChaRM) :

For the organizations that have been using Incident Management or Change Request Management for an extended period and heavily rely on those scenarios to support internal or external audits, this historical data is very precious and needs to be retained.

Unluckily, when upgrading to Solution Manager 7.1, it ends up more or less like having two different tools : the ‘legacy’ with ABAP tickets and the ‘new’ one with CRM WebUI tickets. And during the transition period, you have to jump constantly from one tool to another, which is frustrating from an end-user perspective and do not help the adoption of the target 7.1 solution.

To avoid such a situation and to allow a lean and smooth transition to Solution Manager 7.1 ticket usage, the option of performing a full Data Migration can be considered. Here are the typical cases I encountered :

(1) – “Migration” of the 7.0 ABAP tickets into 7.1 CRM WebUI tickets within the same upgraded Solution Manager.

In this scenario, the Solution Manager is upgraded (master data are kept…) and the old ABAP tickets are of course accessible in CRM_DNO_MONITOR.

But to simplify the transition, the open tickets are migrated into the target 7.1 transaction types. The ticket number and statuses usually are identical, the metadata (processing log, changes to document) are retrieved as well as all attachments, text entries, business partners assignments etc.

Closed tickets can be migrated as well, and put in a closed (read-only) status in the target ticket type.

If some data mapping or transformation is required, management rules are implemented. Even more important, exception rules are implemented to manage missing or irrelevant data cases.

Some advanced migration tasks can also be considered :

Creation of document flow (linkage between tickets)

Assignment of Transport Requests (modifiable and even released one) to Change Documents

Re-assignment of Change Documents to new Project cycles

Upload of Cross-System Object Lock entries in Solution Manager

(2) – “Migration” of the 7.0 ABAP tickets into 7.1 CRM WebUI tickets between two different Solution Manager systems.

In this scenario, an “old” Solution Manager contains the ABAP tickets and will be decommissioned. A new fresh installation of Solution Manager 7.1 is performed. This strategy brings new challenges, as the complete set of master data do change as well !

During the migration, ticket numbers are often kept, the statuses are identical, the metadata (processing log, changes to document) might also be transferred (auditing purposes). And for sure all attachments, text entries… are migrated as well. The migration scope certainly involves all open tickets, for which further processing will be required afterwards. But usually also all closed tickets that will be migrated into read-only documents. Like in the previous scenario, data management and exceptions management rules are utmost important.

The same advanced migration tasks as mentioned earlier can be considered :

Creation of document flow (linkage between tickets)

Assignment of Transport Requests (modifiable and even released one) to Change Documents

In this last scenario, a third-party tool (Remedy, Lotus Notes etc.) holds all the tickets that should be migrated, as it will be decommissioned by SAP Solution Manager 7.1 (fresh installation). This strategic move offers a lot of opportunities, as Solution Manager is not simply a ticketing tool but a comprehensive and integrated IT Management platform.

In this scenario, the complexity is to extract from the legacy tool a structured list of all existing tickets, with all key information that will be required to populate SolMan ITSM/ChaRM tickets. Beforehand, a complete set of master data has to be created in Solution Manager and the target processes have to be designed and implemented before migrating.

Finally, the migration can be performed, mass creation of 7.1 tickets in the target system. A common requirement is that the ticket get generated with their original creation date (in the past). The metadata (processing log, changes to document) can be transferred as text file and attached to the ticket like all other kind of attachments. And again the migration scope encompasses both open and closed tickets.

As previously data management and exceptions management rules are a key to data migration success.

At last, some advanced treatments can be requested post migration, similar to the one we exposed earlier.

those are the main data migration scenarios and challenges I had to deal with so far. This return on experience relies on 15 migration projects, ranging from few thousands of tickets up to a massive 100,000 tickets. Each and every single of those project falls into one of the category described here, and even though the expectations and constraints were always somewhat different, my objective here was to emphasize the common patterns…

Hopefully this small overview was interesting for the community. If you have particular questions or inquiries, feel free to post your questions or to contact me directly..

Assigned tags

Related Blog Posts

Related Questions

Thank for your information. I have some questions regarding to the type case 2 ‘Migraion between two solution manager’. How can we do the migration? what tool can we use for the migration? how to handle the delta data?

I need some questions regarding to the type case 3 ‘Migraion between Non SAP and SAP solution manager’. How can we do the migration? what tool can we use for the migration? is there any standard function module there ?

Thanks for this valuable information..we are currently facing similar kind of issue that we have two system one solman 7.0 and other solman 7.1. We want to transport all old data which are in old solman 7.0 system to new system. According to your blog its possible.