Change Models: How to Handle Old Change Records (No Model/Flow)?

[maliksneha9]

We recently introduced Change Models + Flow Designer for Change Requests in our TEST instance. The instance was cloned from PROD, so we now have a mix of:
• Old change records → no change_model, no flow (manual process)
• New change records → using change models with flows attached
Issue we’re seeing:

• Old records still show the Process Flow Formatter, but since no model/flow is attached, it appears empty or misleading
• We want to ensure a clean experience and avoid breaking anything when we deploy to PROD

What’s the best practice here?
Specifically:

1. Is it recommended to leave old records as-is (coexistence) or try mapping them to a model?
2. Any risks or gotchas when deploying this setup to PROD where legacy + model-driven changes will coexist?

Would appreciate guidance from anyone who has handled a similar transition.

[Dr Atul G- LNG]

Hi @maliksneha9 

• Old change records → no change_model, no flow (manual process). --> expected behaviour
• New change records → using change models with flows attached --> expected behaviour
Issue we’re seeing:

• Old records still show the Process Flow Formatter, but since no model/flow is attached, it appears empty or misleading
• We want to ensure a clean experience and avoid breaking anything when we deploy to PROD

Atul:

Being a BPC and having worked as a Change Manager, there is no direct or quick fix for this. The key is to start by analyzing the existing changes that are still on workflows and gradually build appropriate change models for them. For new changes, you can enforce the use of change models by guiding the team to follow them consistently. You can also configure system properties so that only change models are used, rather than allowing the older approach.

It is also important to understand that this is not just a technical change—it is a mindset shift. People are often used to the traditional way of managing changes. However, if you educate them and demonstrate the benefits of using change models, they will gradually adopt and start using them effectively.

What’s the best practice here?
Specifically:

1. Is it recommended to leave old records as-is (coexistence) or try mapping them to a model?

Atul:

Yes, that’s correct—you cannot attach a flow or change model to ongoing changes.

You will need to either cancel those changes or allow them to continue as they are.

1. Any risks or gotchas when deploying this setup to PROD where legacy + model-driven changes will coexist?

Atul:

No, but before enforcing this, it is important to educate users. Inform them that this change in the way of working is coming and they should start adopting it.

I would also recommend configuring the system to allow only change models. If you keep both options available, users will likely continue using the old method, and it will be difficult to enforce the new process.

https://mynow.servicenow.com/now/best-practices/assets/change-management-process-workshop

[maliksneha9]

Hi,

Thanks for the update.

However, I am noticing that the new fields, related lists, process flow formatter, and the updated state choices (New, Assess, Authorize, Scheduled, Implement, Review, Closed) are also appearing on existing change requests. Regardless of their current state, these older records are being mapped to State = New.

Additionally, the Model field is empty on these records. When I populate the Model field via a background script, the change model flow gets attached and starts behaving like the new change requests.

I am unsure whether updating existing change requests to use the new change model is the right approach. Ideally, we would want existing records to continue following the current/legacy process, while only new change requests use the change model framework.

Could you please advise on the best approach for handling this, especially when promoting to production?

[Dr Atul G- LNG]

Hi @maliksneha9 

However, I am noticing that the new fields, related lists, process flow formatter, and the updated state choices (New, Assess, Authorize, Scheduled, Implement, Review, Closed) are also appearing on existing change requests. Regardless of their current state, these older records are being mapped to State = New.

Atul: Out of the box, it is set up that way, but you can change it. Since you’re using the standard model, all states are available by default. However, if you create your own model, you can decide which states you need.

https://youtu.be/kH4hW0FldOQ

Additionally, the Model field is empty on these records. When I populate the Model field via a background script, the change model flow gets attached and starts behaving like the new change requests.

Atul:Please don’t do this—you’re breaking the system and creating unnecessary issues. If you attach the flow from the backend, it will restart from the beginning instead of continuing from the point where the change was made. Essentially, it cancels the existing workflow and starts a new one, so the system begins from the initial state. This is the expected behavior

I am unsure whether updating existing change requests to use the new change model is the right approach. Ideally, we would want existing records to continue following the current/legacy process, while only new change requests use the change model framework.

Atul:

This is not the right approach to update old changes with the new model. The best way is to keep the existing changes as they are and close them using the current workflow. For any new changes, start using the new change model only.

It’s just a matter of time and adoption—once all old changes are closed, you’ll be fully transitioned to the new change model.

Could you please advise on the best approach for handling this, especially when promoting to production?

Atul:For production, use the system property to disable the old legacy page and create the new page. Also, start using the new change model as mentioned earlier. At the same time, educate the team about this new way of working and its usage so they are ready to adapt and adopt the changes.”

https://youtu.be/UV_Tac-AVDw