Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

In this new blog, I'd like to elaborate on one very particular aspect of the SAP Solution Manager Upgrade Projects for which I already provided some insights there: http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/11/22/solution-manager-71-.... To be more specific, I would like to expose the main Data Migration scenarios challenges I could observe on various projects with the adoption of Solution Manager 7.1...

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) :

  • CRM 5.0 is replaced by CRM 7.0 EhP1
  • User Interfaces change from classical SAP GUI to SAP CRM Web UI
  • New 7.1 transaction types (SMIN, SMCR, SMMJ etc.) replace the old 7.0 transaction types (SLFN, SDCR etc.)
  • After the Upgrade, processing of 7.0 transactions is allowed, but only new 7.1 transactions shall be created

The schema above (source: SAP) describes the transition phase for ITSM / 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
  • Re-assignment of Change Documents to new Project cycles
  • Upload of Cross-System Object Lock entries in Solution Manager

(3) - "Migration" of tickets from a Legacy (non-SAP) tool into Solution Manager 7.1 CRM WebUI tickets.

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.

  • Assignment of Transport Requests (modifiable, sometime released one) to Change Documents.
  • Assignment of Change Documents to new Project cycles
  • Upload of Cross-System Object Lock entries in Solution Manager using standard function modules

In a nutshell,

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..

7 Comments
Labels in this area