Best Practice For Cloning During Long-Term Projects

[cmsrenaski]

I tend to put all of my questions in the Developer Community - please let me know if this belongs somewhere else. We currently clone quarterly. Once per quarter we are either upgrading or applying quarterly patches and we always clone from PROD to DEV and TEST before doing so. This works for most but we do have a couple of project managers that struggle with this concept as they have long-running proof-of-concept projects where we have vendors developing to prove a concept and our clones disrupt that process. When we went to K18 we heard that best practice is to clone more often, perhaps monthly, which causes our PMs a lot of consternation.

In general, I know that everything can be exported via update sets and data can be exported, however, there seem to be some applications where that is difficult. You're building things that cannot be easily exported. PA Dashboards are one example. Our PM also mentions Service Mapping (Service Watch) and Event Management. Per our PM, "We also have issues with other areas like Service Portfolio and PPS where the update set does not include all of the ‘Release’ steps. We still need to manually run steps like data loads, running scripts to repopulate historical field updates, etc.…"

Does anyone have any advice on how to accommodate long-running POCs (or just development efforts that can't be easily transferred between instances) while maintaining a prudent cloning schedule?

Thanks in advance for the help!

[mishu1]

Hi,

You can use "Exclude tables" and "Preserve Data" modules within the Clone application, to make sure that the table which you do not want to get cloned over from your target Instance to source Instance are excluded from the clone engine process, whereas Preserve data module will help you to preserve data on the Source Instance post the completion of the cloning.

Regards,

Mishu

Note: Please mark this response as "Helpful", if in case it has resolved your query. 

[cmsrenaski]

Hi, mishu

I'm marking this as helpful for informational purposes but in this case I'm speaking of projects/modules/applications that aren't in PROD yet so the tables/data wouldn't be there yet to exclude/preserve. Service Mapping (Service Watch), Event Management, Service Portfolio and PPS are all running in sub-prod instances only as proof of concept. We thought of turning it on in PROD w/o giving anyone the licenses so we could at least not have everything written over every time but SN insists on charging us as soon as we go to PROD, even w/o active licenses in place. 

Thanks for your input!

[mishu1]

Hi,

You can preserve the build work done for these applications in update sets containers and post the completion of the cloning, you can import back these update sets on the sub-prod Instances.

Also, yes the applications like- Service mapping, Event management etc. are subscribed applications and these will be charged as soon as you migrate these to productions as these are based on per thin device to be configured. These applications are not used by any of your end users, rather the pricing model is based on the number of end user devices which are deemed as critical business services, hence ServiceNow treats them as licenses once its migrated to the Prod Instance.

Regards,

Mishu

Note: Please mark this response as "Helpful", if in case it has resolved your query. 

[cmsrenaski]

Anyone else? We're struggling with the concept of How Often Do You Clone? Best Practice always seems to be "It Depends". I get that, but it's challenging to get to the state that works the best for all (or that we can compromise on). If you have a lot of development going on all the time it seems prudent to keep your instances in sync more aggressively, but the more development you have the more disruptive the clone...  ???