First time cloning - Dev to Prod?

[Tim_Berger]

Would like to get some input from someone that has dealt with this already.

Question: What is the preferred method - best practice - recommended when moving your content from the Development instance to the Production instance?

Background: The Dev instance still has all the content from SN in it from when SN originally stood it up (Example flows and users)...

Nothing has been moved into the Prod instance at this point. We are hearing mixed messages on what is best to do. 1st we were told to move things into the Prod instance thru update sets. Then we were told it is easier to Clone the existing Dev to Prod then run clean up scripts afterwards, and if anything is broken SN will revert our Prod instance back. Then we would just clone it again and do a manual clean up in our Prod instance.

'From experience, what is the preferred method?

[chrissteinkep5]

100% agree with Robert. And I don't think it is OCD, I think it is survival instinct.

'Cloning up' is definitely hitting the easy button, at least in the short term. You don't have to worry about keeping track of pesky things like what objects have been modified and why, or properly document bug fixes to ensure migration, which sounds great to the project team. However the longer you work with the product, and if you are one of the lucky people who work full time supporting a SN implementation, you start to see how interconnected it is and how one small bit of sloppy configuration or undocumented code can lead to tens of thousands of dollars of cost to a company. If you have ever had to spend days, weeks or months debugging an undocumented customization in ServiceNow, or seen a project delayed because the client and ServiceNow support can't agree on who is at fault, the value of proper change control and migration processes becomes much more tangible.

So IMHO it is hitting the 'easy button' but the opportunity costs are hidden and companies pay it later. The answer to poor requirements, testing and change control is not to "cheat" by doing all your work directly on Production. The answer is to have quality requirements, testing and change control.

[JordanLind]

I like this approach, pre go live all work done in PROD and then cloned to DEV.   One big issue I've seen eliminated this way is mismatched sys_ids for groups between instances which can cause workflows tasks to fail.

[sgrison]

If there is no data/customizations you want to save in your production instance then you should clone DEV to PROD.   As mentioned by previous posters the integrations/mid servers's would need to be modified to point to the production instance.

[Tim_Berger]

thanks again, it looks like we are moving forward with the Dev to Prod cloning. I was thinking we may have wanted all the SN demo information removed from Dev prior to the cloning, but from what I am told the clean up script will do that once in Prod.