Implemented Change Management facing issue with current change process

[navin14]

Hi All,

Previously, we used the Change Module out-of-the-box (OOB) with states such as Open, New, Work in Progress (WIP), Close Complete, and Close Incomplete. Recently, we upgraded to the Change Management Module, which includes the Change Advisory Board (CAB) workbench with states now labeled as New, Access, Authorize, Schedule, Implement, Review, and Closed.

Currently, we have some active changes in production using the previous change process. Our business is eager to deploy the new changes that will alter the entire workflow. When we deployed the changes to Test instance, the states are displaying as numerical values like 1 and -5 for the existing changes,

What is the most effective way to deploy these changes without impacting the previous ones?

[Akash4]

Addressing the existing change_request records via a Fix Script is a good option when the configurational changes happen in the system. The old choices have inherited from Task table (parent of Change Request) and hence the child is showing values like 1 or -5 since now it has got its own states.

But before proceeding on this step, one must be cautious since Fix Scripts modify the records and hard to differentiate from non-modified ones once the Script is Run. Extra care is to be taken in DEV instance while testing with filtering on fields like "Created On < Particular Date". Only changing 1 state choice at a time is beneficial, also Scope must be addressed.

Do a one on one mapping for each state of currently existing records from oldChangeState to newChangeState and then run a Fix Script. A sample script looks like below:

var gr= new GlideRecord('change_request');
    gr.addEncodedQuery('stateIN1,2'); // Query for 'Open' or 'WIP' states based on taskValues
    gr.query();
while (gr.next()) {
        var oldState = gr.state.toString(); //store it
        gr.state = 2;//based on new Values say for "Assess"
        gr.update();  // Save the updated record
}