SM9.41 OOTB installation and rebuild from ground up

I was almost certain I posted this question an hour ago, but cannot now find it.  Please excuse if you find it already posted  but worded differently.

I have been reading many of the answers to questions about moving from 9.21 to 9.4x codeless.

Given the time required to:

- perform at least 2 different upgrades

- extensive testing needed for upgraded legacy code

- many of our old legacy customizations may be OOTB now

It would almost seem to me that we would be better off Installing a new OOTB Codeless mode installation of SM9.41 and rebuilding all our processes from the ground up.   This way, we can be sure that everything we build is able to upgrade when next version of SM9.xx comes out.  We have very clean processes and code (brings no trash from legacy implementation and extensive customization)


Can you list the Pros and especially the Cons for doing new Installation and rebuilding from ground up?

Does this typically take more or less time than 'upgrading'from 9.21?

Thank you

  • Hello Stacy,

    As you acknowledge, it is not simple task to upgrade SM from 9.21 to 9.4x.
    so, it is not simply answered what is better among new Installation and upgrading application.
    genearlly, it depends on the size/complex of old legacy customization.
    If your system has simple legacy customization then, both ways are good enough.
    If your system has complex legacy customization then, it needs to be considered exactly.
     for such a situation, it is helpful to get HP Professional Service, SM upgrade assessment.
     after HP PS's upgrade assessment, you can decide your process accordingly.
     You can upgrade by yourself or HP PS. It depends on your environment(system,duedate,complexity,people resources)

    Support Engineer

    Thank you for using the HPE Community. If you find that this or any post resolves your issue, please be sure to mark it as an "accept as solution".

  • Hi Stacy,

    Can you list the Pros and especially the Cons for doing new Installation and rebuilding from ground up?


    Pros: 1) Keep same dbdict with out-of-box, without need to resolve dbdict mismatch issues in except.log; 2) No need to resolve upgrade conflict; 3) No performanct impact due to large legacy transactino data.

    Cons: 1) Can NOT enable PD based on module by module; 2) Need to reimplement legacy customizations; 3) Need to purge out-of-box demo data (cm3r/incidents/probsummary/...); 4) Need to migrate legacy master data (operator/contacts/assignment/device/...); 5) Need to migrate legacy tickets.

    Does this typically take more or less time than 'upgrading' from 9.21?

    >> As Kyoung-hwan Shin mentioned, it depends on your custimzation, data volume...


    SM RnD Upgrade Factory

  • Stacy,

    When doing a combined upgrade from 9.xx to 9.4x AND concurrently moving your build to Codeless, it is really two major separate steps, but it isn't as bad as it seems:.

    Normally, when you upgrade a classically tailored system, you have to complete all conflict resolution for the upgrade, then test and test and test.... BUT -  if you also plan to implement Codeless workflows as part of the move to the new version - you don't have to do conflict resolution on any components that are deprecated after Process Designer/Codeless Mode is enabled, which can save tons of time. (Once you move to codeless, a lot if the legacy code is no longer used, so there isn't a need to mess with it).

    For example, last summer we upgraded a 9.3x customer that had installed no PD content packs previously with the intent of a full codeless conversion.

    The actual preparation of the 9.3x to 9.40 upgrade package was completed in about one week, including testing. For any item that was tied to legacy display components for the areas to be replaced in codeless, we just kept the old version (with PD enablement, the Objects are updated to use new display components).. We did test components that would move forward, and had to merge some modified Script Library stuff, but this saves a lot of time (THIS ASSUMES YOU WILL NOT ACTUALLY DEPLOY THE 9.4x upgraded classic system).

    Next, we built the custom configured PD workflows for each module. At the time of the upgrade, you apply the upgrade and transfer all config/tailoring as you would any tailoring components. You can test that process against a copy of production repeatedly to ensure it goes smoothly. 

    This is still a big effort, but codeless is actually much easier to work in, plus it provides a really good opportunity to start from the new out-of-box workflows (which are, honestly, the best out of box build I've seen in nearly 20 years with this application--development did a nice job on the new modules). For this customer above, the new build is much more closely aligned to OOB than previously and they'll have better capabilities as a result with less work.

    NOTE: this above was all executed in a 9.40 environment. With Hybrid mode available as of 9.41, you have more options, including an option to stage the migration of modules to codeless workflows. In fact, you don't even have to move an entire module to new workflows at once: For example, the incident management workflow is assigned in the category record, so you can migrate one category at a time. If you have a highly customized, non-IT category such as "HR" you might choose to keep the Hybrid mode build for them while migrating the IT category "Incident" category at cutover. We also defined a streamlined workflow for the complaint and request for information categories that is simpler than the workflow used for incident.