Upgradable contracts patterns are possible. You have to engineer it into the system before it goes into production. This so that upgradability is a property of the contract you want to change.
That would be something only a privileged user should be able do which opens a new can of worms because it's a backdoor. https://medium.com/consensys-diligence/upgradeability-is-a-bug-dba0203152ce
A solution to that problem is to let the users decide if they will accept the upgrade.
Have a look at this experimental pattern: https://github.com/rob-Hitchens/TrustlessUpgrades
You have flexibility about what to do with the remaining authority. It can be as simple as an externally owned account, but anything that can be codified in a contract is a candidate on-chain governance process.
do I create a "dump and upload again" script or do I just reference the old data somehow
Those are both options. In the end, it's about the upgrade process you propose and the assurances your users have that the privilege won't be abused. If it's too centralized, it may call into question the assurances offered by the solution.
Hope it helps.