Are there any disadvantages if I UPGRADE using Clone technique?

Suggy
Giga Sage

Are there any disadvantages if I UPGRADE using Clone technique?

currently we have DEV, QA and PROD.

I have cloned DEV from PROD. Upgraded my DEV, worked on all the issues in DEV. Now DEV is ready.

What if just clone DEV over QA, so that QA gets upgraded based on the clone?

1 ACCEPTED SOLUTION

Michael Jones -
Giga Sage

ServiceNow does support cloning from a lower version to a higher version. 

https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/managing-data/concep...

As you started with a clone from PROD to DEV, you should not encounter any significant issues cloning DEV to QA after the upgrade however - the best practice is generally to perform the upgrade in DEV, document all necessary fixes, perform the upgrade in QA and once again apply the same fixes - this gives you a good dry-run for your upgrade in PROD. 

You would never want to upgrade PROD in this manner however and would always want to apply the upgrade manually. 

In short, you could take this approach, but it would be recommended that you work through the upgrade in QA the same as you've done in DEV. 

I hope this helps!

If this was helpful, or correct, please be kind and mark the answer appropriately.

Michael Jones - Proud member of the GlideFast Consulting Team!

I hope this helps!
Michael D. Jones
Proud member of the GlideFast Consulting Team!

View solution in original post

8 REPLIES 8

Michael Jones -
Giga Sage

ServiceNow does support cloning from a lower version to a higher version. 

https://docs.servicenow.com/bundle/rome-platform-administration/page/administer/managing-data/concep...

As you started with a clone from PROD to DEV, you should not encounter any significant issues cloning DEV to QA after the upgrade however - the best practice is generally to perform the upgrade in DEV, document all necessary fixes, perform the upgrade in QA and once again apply the same fixes - this gives you a good dry-run for your upgrade in PROD. 

You would never want to upgrade PROD in this manner however and would always want to apply the upgrade manually. 

In short, you could take this approach, but it would be recommended that you work through the upgrade in QA the same as you've done in DEV. 

I hope this helps!

If this was helpful, or correct, please be kind and mark the answer appropriately.

Michael Jones - Proud member of the GlideFast Consulting Team!

I hope this helps!
Michael D. Jones
Proud member of the GlideFast Consulting Team!

Hi @Michael Jones - CloudPires  ,

I found the SN Doc a bit ambiguous, re:

 

  • Copies the database schema from the source instance to the target instance.
  • Creates tables in the target instance database using the source instance table definitions.

There is no explicit mention of table excluders (wot I could see).

Are you saying that even if a table is excluded from a clone, the schema for that table will be included in the clone?

Thanks,Matt

 

Matt, 
 
This link gives some more in-depth answers to common questions about clones.  
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0715621
 
The first section - How does a clone work, provides some details that I believe shed some light on your sub-question: 
 

How does the clone work?

In response to a clone request, the ServiceNow platform performs the following tasks:

    1. Generates a file to preserve operational data on the target server.

      This file contains the data preserved by data preservers.

    2. Creates a new database for the target instance
    3. Restores the database schema and data from the latest backup to the newly created database
    4. After all data is copied across it starts the exclude/preserver functions
    5. If Exclude options are ticked
      • Tables in the exclude module are truncated (All data is cleared out)
    6. File created in Step 1 for preservers is loaded into the target database (overwriting any data from the restore)
    7. Email functionality is disabled in the target database
    8. Once all is completed the target instance repoints to the newly created database
    9. All Clone cleanup scripts are executed in the target instance.
      • Regenerate Text indexes
      • Clear scheduled job node associations
    10. The clone is complete and the instance is accessible for the customer.
    11. After the clone completes a backup is taken of the old Target database (Can be rolled back for up to 7 days)
    12. Once the backup completes the old target database is retired.
 
So, step 3 would be applying the database schema to the target instance, with steps 4 and 5 and 6 (excluders and preservers) coming after. 

So, yes, even if you exclude a table from a clone, the underlying schema will be applied from the source instance to the target. 

I hope this helps!

If this was helpful, or correct, please be kind and mark the answer appropriately.

Michael Jones - Proud member of the GlideFast Consulting Team!

 
 

 

I hope this helps!
Michael D. Jones
Proud member of the GlideFast Consulting Team!

@Michael Jones - CloudPires  Hi Michael, thanks for the details. However I believe the MID servers will not be automatically upgraded if we do the clone right.

Also are you aware of any disadvantages of cloning DEV to QA in order to upgrade the QA.

I did not understand the replies mentioned here.