Systems that become painful to change usually share one origin: the data model was drawn around a screen instead of around the entities the business actually deals with.
Model entities, not interfaces
Screens change every year. Customers, orders, products, appointments and invoices do not. Model those first, with the relationships between them stated explicitly.
When the model reflects the business, a new interface becomes a new query. When it reflects last year's dashboard, every new requirement becomes a migration.
Let the database enforce the rules
Constraints, foreign keys and correct types are cheaper than the code that would otherwise clean up bad data later.
Rules enforced in one place stay true regardless of which application, script or integration writes the row.
Keep history
Overwriting a record destroys the answer to a question the business will eventually ask: what did this look like before, and who changed it?
Timestamps, soft deletes and an audit trail on the records that matter cost very little at design time and are close to impossible to reconstruct afterwards.
Takeaway
Model the business, enforce rules at the source, and keep history. Those three decisions determine how easily the system evolves.