I use similar approach but we have 3 instances:
1) Production
2) QA - Ideal copy of production, after Development completed in DEV we first move it to QA to see if all steps were captured during development, we test it here and only after success move it to PROD.
3) Dev - Fresh copy of App (sometimes it is multiple Development Environments)
It created more work as we need to move all Developments and Pipelines multiple times but at least it is save for end user.
Challenges are not only for Pipelines but also for Formula Queries, as field ID may vary.
I am not using Sandbox as it block production from any editing, and before I do big development, I may have a need for smaller releases 😀
This isn't much help - but if you have a robust and interconnected environment, there are some helper tools that you can setup to make it easier as you transition between new staging environments.
I think there is an app on the exchange, or if not its not hard to build a simple searchandreplace setup where you can copy YAML and plug in the old / new params and spit out the new one as a way to eliminate potential manual error.
If you've got apps that have connected tables that you need to remain in sync in staging, its simple enough to build a data model that you can run through a pipeline where you basically recreate the idea of a native QB Connected Table in its components. Just have table of 'syncs' where you tell it what DB to pull from, the clist for fields and query param and then where / what fields to load it to and you can make a simple Pipeline to do a genresults csv pull and load it. This helps when you QB converts the connected table to basic setup when you make copies.
