What environment should I start implementing in? Prod (then clone down) or Dev (and move up)

[Winston]

Hello everyone, 

We're going to begin implementing our system soon, and I was just wondering what's everyone's take on this is. Servicenow on the ITSM Guided Setup recommends that for new users to start in prod and clone the system down to test and dev. I've always done work in dev environments then moved up, is it possible to clone a prod environment after a test or dev environment?

[Allen Andreas]

Let me know if you have any other questions.

If my reply helped guide you to a correct answer for yourself, please also mark it as Correct.

Thanks!

[Dipu Joy]

If you are a new customer and not live yet, the best option will be as follows:-

1. Get your PROD instance and then Zboot the instance without any DEMO data.

2. Install the Plugins you want on the instance. All paid/free plugins your organisation require. This is very important that there are at times during plugin installation, the sys_id of the records will be different on instances and this can create issues when you commit update-sets on the plugins configuration as the record will not be found if its matched on sys_id.

3. Once your PROD instance is ready without any DEMO data and all your integration configurations and n with all the plugins, request a restore of your PROD instance to your SUB PROD instance/instances ( there is a HI Catalog, or raise a HI Task). Clone will exclude some data.

4. You can start development on your SUB PROD instance and all the instance will be with the same set of sys_id's

5. If you are installing any new plugins on SUB PROD, please install this in your main DEV instance as this will make sure when you clone over to PROD, it will be the same sys_id's

6. Create a HI ticket to add your SUBPROD/DEV instance to on-demand backup during clone workflow and you need to provide an expiration date for that.

7. Update the clone property on PROD to allow it as a clone target.

8. You can initiate the clone any time as per your convenience as we have set to create an ad-hoc backup before any clone so that an new backup will be generated from DEV to PROD for GO LIVE. Because of the a-hoc backup configuration; you do not have to rely on the backup time for the GO LIVE clone.

[Allen Andreas]

Hi,

Thanks for the information. A few things just from my experience:

Prod instances don't contain demo data when initially launched, so this shouldn't be an issue where you need to zBoot a brand new Prod instance.

I'm sure there is a "possibility" that plugins being activated in different instances could create different sys_id's across those instances, but I find this a bit hard to wrap my mind around because if that was a thing...then...later when you go to implement something like ITBM, etc. after go-live, you wouldn't activate on your Prod and work backwards? So not too sure if mismatched sys_ids is common.

Some of the data from Prod you wouldn't want to bring down to your other environments and I'm unsure who would configure all of their integrations right in the beginning, like MID Servers, etc. would need to be different. before working in other environments. Settings and other things like theme, etc. you'd probably want to leave off as well.

The onDemand clone is a good point, however this isn't normally advertised, but I've used this many times. As you mentioned, it is advisable to have it expire at a certain point as later it can make regular clone sessions insanely long due to creating the backup first before commencing the clone, but that would take a bit to get to that point.

Overall, thanks for posting. Unsure about this as the "best" way, but it's definitely a viable option. Thanks!