Ask HN: Architecting a SaaS for backwards-compatibile data and business logic

I have a SaaS platform where the user fills out a form and data entered into the form is saved to a database. The form UI has a large amount of config (originates from the DB) and business logic (in JavaScript). After a form is filled out and saved, the user can go back at any time and edit it.

The wrinkle is that an old form entry needs to behave like it did when it was first filled out - it needs the same config and business logic from when it was created - Even if the SaaS has gone through a data schema change and changes to business logic since then.

I need a sensible way to version the config, business logic and any dependencies (e.g. view templates).

The best I've come up with is, when the user saves their entry, to save the form's config as JSON along with the entry. When the user goes back to edit an old entry, I do not load the config from current database schema but simply dump the JSON config that was saved with the entry.

For the business logic, I save a system version number along with the entry, for example "01". When the user loads an old form, I check the version of the entry and I then load the form JavaScript from a path like "js/main_01.js". When I make a non-backwards-compatible change to the business logic, I increase the system's version number to, for example, "02". New forms would then use "js/main_02.js". I also use this cheap versioning approach for HTML view templates which is getting hairy.

This approach works but it seems a bit flimsy or homegrown. I'm trying to avoid conditionals in my business logic like `if version==2: do this`. This approach avoids that but also has it's downsides.

I don't think the stack really matters for this convo but just in case, I'm using django/mysql.