While it may seem easier to copy databases across Sitecore environments, there are some risks you need to be aware.
These risks should push you to what many in the industry do: content syncing.
But first, why are users copying databases into Sitecore environments, often replacing the databases deployed in the new environment by SIF or the PaaS ARM Templates?
One reason: its easy and faster (until you end up in remediation, and realize how big of a mistake this can be!)
And when its “easy”, either something is really right… or something could be terribly wrong…
Lets pretend you have upgraded Sitecore in your local development environment and now want to deploy your updated content to a brand new Sitecore environment that already has databases deployed as part of its deployment. You can either:
- Replace the databases you have, because its “the same version of Sitecore” OR
- Sync the content in your databases to the destination databases
If you choose to go with number 1, you must be aware of the following:
- Often, the local database you just upgraded may have artifacts from your local environment such as Visual Studio generated tables, or any schema customization you did while developing. This means, the actual schema Sitecore needs to work (that was in the brand new database you just overwrote with yours) could have missing or incorrect schema. This may cause Sitecore to not function in a way that you will always wonder “that’s odd, it keeps complaining about X, maybes its part of my code or just a Sitecore bug”
- You could have had a “hiccup” during the upgrade process that creates missing tables or other key database items within the schema
- If you copy a database in, you will overwrite all the validated and deployed aspects of the destination environment with your full copy
- You will overwrite any environmental specific data such as usernames and passwords in Core
- You will need to clear the event queue every time you copy
- You will need to clear the properties table every time you copy
- You will need to compare your schema with a schema tool every time you copy and remediate any schema differences
Given the aforementioned, you can see how this introduces risk and is a bad practice.
Now, if you choose option 2, you are not overwriting schema. You could use Razl, Unicorn Sync, or other tools (for those with SPE check out https://github.com/michaellwest/Spe-Content-Migrator) to compare and then safely migrate your data in.
This video gives some good detail re: content syncing with Sitecore PowerShell Extensions (Thanks Michael West). The sync discussion starts at 39:33:
Does it take more time to learn how to use a content sync method? Sure, but it will increase your DevOps maturity and reduce risk in the process.