What to back up before downgrading
Downgrading does not write to your original project, so that part is safe. But handovers carry other risks, and a standing backup habit saves far more time than recoveries do.
Separate the master from the deliverable
The master is the highest-version, complete project and it stays on your own machine. The deliverable is the downgraded copy for older environments. Give the two clearly different filenames — a target-version suffix works well — so you never send the wrong one.
Back up more than the project file
The project file alone is often not enough. It stores paths to media, so move or rename the media and the project opens with everything offline. Package the media folders alongside it, or confirm the project uses relative paths.
Does version control replace backups?
Putting projects under version control helps, but binary project files gain less from it — every commit stores a full copy and the repository balloons. Saving copies at milestones, with date and version in the name, is the more practical habit.
Why rollback is trivial
Because a downgrade only produces new files and never writes the original, rolling back needs no recovery step at all — bring the original back and it is complete. That is the reason to keep a copy: not because downgrading might fail, but because you might delete the wrong thing.