- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-12-2024 11:38 PM
Hi,
Please explain me why we clone non-prod instances before upgrade and is this mandatory?
Thanks,
Sam
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-13-2024 12:00 AM
Preservation of Customizations and Data: Cloning ensures that the non-production instance has the same data, customizations, and configurations as the production environment. This allows you to test the upgrade with realistic data and workflows.
Risk Mitigation: By cloning the non-production environment, you can identify potential issues or conflicts with custom scripts, workflows, or integrations before applying the upgrade to the production instance. It serves as a sandbox to safely test without affecting live operations.
Accurate Testing Environment: Non-production environments are often used for testing, so cloning ensures that your tests are as close as possible to the production environment. This helps in accurately simulating and resolving issues before the production upgrade.
Backup in Case of Issues: If something goes wrong during the upgrade, having a clone of the current state allows for troubleshooting without disrupting ongoing operations.
Is it mandatory?
No, it’s not mandatory, but it is a best practice. Skipping cloning increases the risk of encountering issues after upgrading the production instance because the testing may not fully reflect the live environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-13-2024 12:00 AM
Preservation of Customizations and Data: Cloning ensures that the non-production instance has the same data, customizations, and configurations as the production environment. This allows you to test the upgrade with realistic data and workflows.
Risk Mitigation: By cloning the non-production environment, you can identify potential issues or conflicts with custom scripts, workflows, or integrations before applying the upgrade to the production instance. It serves as a sandbox to safely test without affecting live operations.
Accurate Testing Environment: Non-production environments are often used for testing, so cloning ensures that your tests are as close as possible to the production environment. This helps in accurately simulating and resolving issues before the production upgrade.
Backup in Case of Issues: If something goes wrong during the upgrade, having a clone of the current state allows for troubleshooting without disrupting ongoing operations.
Is it mandatory?
No, it’s not mandatory, but it is a best practice. Skipping cloning increases the risk of encountering issues after upgrading the production instance because the testing may not fully reflect the live environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-13-2024 12:12 AM - edited ‎09-13-2024 12:13 AM
Hello @Samiksha2 ,
Cloning is important to have all the updates handy with you, if something goes wrong during the upgrades.
Recently we also migrated from Utah to Washington, so first we cloned the dev environment, so all the updates were captured and then we proceeded for Washington.
We moved the major development from dev to prod, we did clone the dev and prod. Now what happened is during the prod upgrade we lose some of the scripts. But there was not an impact because we already cloned the dev environment so all the recent updates which we moved into the prod was with us. Post finishing the upgrade we moved those codes from dev to prod smoothly that has no business impact.
So, you can think if we couldn't clone our dev before upgrading it to Washington, we might lose the updates that could take to the major business impact.
Please mark my answer as accepted solution and give thumbs up, if it helps you.