For me #1 would be to add a version to any data format or communication
protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.
Versions make sense in a lot of areas where stability is needed. But they should be seen as issuing binding contracts to your users. You should spend a lot of time thinking about what the terms and conditions are before doing so.
https://aws.amazon.com/builders-library/ensuring-rollback-sa...
> With each change, we explicitly assign a distinct version to serializers.
> We do this independent of source code or build versioning. We also store the serializer version with the serialized data or in the metadata. Older serializer versions continue to function in the new software. We find it’s usually helpful to emit a metric for the version of data written or read. It provides operators with visibility and troubleshooting information if there are errors. All of this applies to RPC and API versions, too.
Backwards compatibility and the ability to roll out new changes (that can co-exist with current data) are the primary drivers.