Changing a database field takes about ten seconds. Deciding what happens to the three years of data already sitting in it takes considerably longer, and most teams never make that decision consciously. They rename the field, or they delete it and add a new one, and the history quietly stops making sense.
In ordinary business software that is an inconvenience. In regulated work it is a defect, because the record you can no longer interpret is the record you still have to produce.
Changing a database field: what actually happens to the data?
Three things can happen, and platforms differ in which ones they allow. You can delete the field, which takes its data with it. You can rename or repurpose it, so old entries now sit under a label that no longer describes them. Or you can retire it, leaving its data intact and readable while new records simply stop using it.
Only the third option preserves the meaning of what you already collected. However, it is also the one most systems do not offer, because it requires the platform to distinguish between a field that has gone and a field that has simply finished.
That distinction sounds small. In practice it decides whether a record from 2023 can still be read in 2027, which is exactly the problem teams inherit when they migrate off a legacy system and discover the old data no longer explains itself.
Why changing a database field is riskier in regulated work
Regulated processes change constantly. A form gains a question after an incident. A regulator adds a data point. Someone amends a protocol, so the intake that made sense in March no longer matches the one running in October. None of that is unusual, and none of it is optional.
What is unusual is the obligation attached to it. You still have to produce the March records, and you have to explain what each value meant at the moment of capture. That is the substance of contemporaneous record-keeping, and it runs through every data integrity framework worth reading, from the FDA's guidance on data integrity and drug CGMP to the MHRA's GXP data integrity guide.
So the risk is not that your process changed. Every process changes. The risk is that your system offered only two options, keep or delete, and someone chose delete because there was no third choice.
The three capabilities this actually requires
Teams tend to treat this as one problem. Changing a database field safely is really three, and each part needs its own mechanism.
Retiring a field without erasing its data
A field that is no longer collected should stop appearing on new records while remaining readable on old ones. In other words, deactivation rather than deletion. Kohezion lets you deactivate a data field while preserving its data, so the schema can move forward without the history moving with it.
Retiring a record without erasing it
Records go out of scope too. A closed study, a decommissioned vehicle, a former supplier. Archiving takes them out of daily views without removing them from the system, so a search two years later still finds them.
Keeping what a record used to say
Retiring things is only half of it, because you also need the earlier states of records that are still active. Kohezion tracks and audits changes to data fields, keeps every version of a record, and versions file attachments as well, so a document replaced in June does not take its predecessor with it.
Notice that these answer different questions. The first is about the shape of the data, the second about its scope, and the third about its history. A platform that offers one and calls it archiving has not solved the other two, which is worth testing before you buy rather than after.
What does an auditor actually ask about this?
Auditors rarely ask whether changing a database field is possible. They ask you to produce a record from a specific date and explain it. Then they ask what has happened to it since.
Answering that needs four things at once: the values as captured, the labels those values sat under at the time, any subsequent changes with who made them and when, and the version of any attached document current on that date. Miss one and the answer becomes a reconstruction rather than a record. Reconstructions do not carry the same weight, which is why Part 11 treats audit trails and record retention as inseparable.
Here the difference between deactivating and deleting becomes concrete. Delete it and the field is not merely unavailable, because nothing documents its absence. Deactivate it and the field remains, still labelled, still explaining what the person entering data in 2023 was actually asked.
How to design for changes you cannot predict
You cannot anticipate which fields will change. Still, changing a database field can be survivable rather than costly, and four habits do most of the work.
- Treat deletion as the exception. Default to deactivating a field and archiving a record, then require a reason when someone wants the other thing.
- Never repurpose a field. Reusing an old field for a new question is the fastest way to corrupt history, because nothing marks where the meaning changed. Retire it and add a new one instead.
- Write down why you retired a field. The system records that it happened, but it cannot record why, and why is what someone eventually asks.
- Check that version history covers attachments, not just fields. Documents change more often than data, and they are frequently the thing under review.
None of this is exotic, and none of it costs anything while you are configuring. It costs a great deal later, if you skipped it. The international records management standard, ISO 15489, makes the same point in more formal language: retention and disposition are design decisions, not afterthoughts.
Changing a database field is a records decision
That is the whole argument, and it is worth stating plainly. Changing a database field is a schema action that behaves like a records action. That is precisely why it gets made badly. It looks like configuration, so it receives the care people give configuration, which is not much.
A platform offering only keep or delete forces that decision to be made carelessly. A platform that lets you retire a field, archive a record and retain every version lets you change your process without editing your past. In regulated work that is not a convenience feature. It is the difference between holding records and holding current data, and the gap between those two only becomes visible on the day somebody asks you to prove something.
On Thursday I take the other half of this, which is why nobody is ever asked to justify a deletion. If you want to talk through how your own retention obligations would sit inside a system, talk to an expert. You can also see how retained history feeds reporting and dashboards once it carries proper structure.
