For Star Wars fans, the Clones represent a certain point in galactic history. The Old Republic needed a fighting force to face the Separatists. Clone Troopers were used to ensure exact replicas of the original genetic template. Exact replicas meant that leaders and trainers knew exactly what to expect from their fighting force. As time went on though, there was individual drift. The clones weren’t telepathically linked to one another, so there was nothing to keep their minds in sync as they grew. This drift created great personalities, but they were never the same.

Ok, what does one nerdy topic have to do with another?

ServiceNow also employs clones.

No, not humans, instances. ServiceNow has the facility built-in to take point-in-time replicas and copy that to another instance. Commonly, ServiceNow administrators clone from a production instance to one or more sub-prod instances. This is great for the same reason that Clone troopers were great for the old republic: the starting point is the same!

Clone Drift

So often in software development (and other areas in technology) we work under the assumption that sub-prod environments match production. Just as often, we find that to be a mistaken assumption. The problem, again, is drift.

Drift is the difference found over time between instances in both data and configuration. The longer the time between clones, the larger the drift is and the more painful it can be to clone when you finally get to it.

Combatting Clone Drift - Regularly Scheduled Clones

In August 2019 I spent the day with lots of fellow ServiceNow professionals at the NowAtWork event in Dallas. In a conversation with Brian Kelly, who manages Toyota’s ServiceNow team and implementation, he told me they had instituted a bi-weekly cloning policy. I was surprised by the frequency, but as he explained his reasoning it made a lot of sense to me.

There’s always someone who has something active in a sub-prod environment, whether it’s development or testing. There’s always a reason not to clone. The fact remains that the benefits of in-sync (not N’Sync) environments far outweigh the impact to ongoing activities.

Benefits of Regular Cloning

Brian shared several insights about the benefits of a regular cloning schedule he listed the pros and cons out for me:

PROS

• Schedule is frequent and known, no questions of if/when
• Coordination efforts dropped dramatically
• Very little environment decay
• If someone does an irrevocable change (delete a table) they only have to wait a week or two
• Can really play around in dev environment when we *might* clone only once a month, we were really really careful in dev

CONS

• Lot of time spent post-clone in configuration and update set application
• (Pro and Con) Need to alter process/procedure for shorter release cycles
• Bringing new people up to speed on shorter release cycles can be a pain (especially outside consultants, can burn SOW hours up front)

Determine the Right Frequency

Some organizations only clone right before an upgrade, others clone with each release cycle. In 2020, I conducted a LinkedIn survey asking ServiceNow connections to get a feel for how frequent folks were cloning. Of the admittedly small sample of 69 respondents the results were as follows:

Frequency	% of Response
Weekly/Bi-Weekly	4.4
Monthly	30
Quarterly	52
Annually or longer	13

Each organization needs to determine what cloning frequency works best for them, but the more frequent, the less painful it is.

"Recent" Feature Enhancements to Cloning

Madrid brought the ability to Rollback clones, while New York gave us a minimal ability to schedule recurring clones.

The Orlando Release brought us a few more features with Clone Profiles, the option to save in-progress update sets on the target instance, and ordering of Post-Clone Cleanup Scripts. The last updates to the System Clone features were in the Paris release where we saw a loss of use of RegEx in data preservers, and restrictions on clone requests while instances are in debug mode. There were no updates to the Cloning feature in Quebec or Rome.

In later posts, I'll dig deeper into clone features such as data preservers, exclusions, Post-clone scripts, and Clone profiles