Legacy Layer Preservation: Don't Delete Past

---

Tamil Ancestry Research | Family Tree Guide

---

In this article:

1. What “legacy layer” actually means in a family archive
2. The three layers you’re juggling: legacy, operational, cosmetic
3. Typical legacy stuff you’re quietly deleting without noticing
4. How to preserve legacy patterns without turning the UI into a museum
5. Versioning: how to show “before / after” cleanly in TamizhConnect
6. Rules for editing: what you can rewrite vs what must stay as-is
7. Concrete steps to build and protect your legacy layer

---

1. What “legacy layer” actually means in a family archive

Forget buzzwords. A legacy layer is simply:

The frozen snapshot of how things used to be – names, fields, formats, place labels, caste terms, village boundaries – before you started “cleaning up” and “standardising” everything.

In practice that includes:

• earlier name patterns (initials, village tags, caste markers)
• old district / taluk boundaries and village names
• raw spelling variants in certificates
• old religious, caste, political labels people actually used about themselves
• pre-migration addresses, even if the place is renamed or gone now
• previous software or spreadsheet structures you used before TamizhConnect

If you overwrite all of that with your shiny new schema and global-facing names, your archive becomes:

• neat,
• readable,
• and historically dishonest.

The legacy layer is the record of the mess. Without it, you can’t explain transitions, only endings.

---

2. The three layers you’re juggling: legacy, operational, cosmetic

Stop mixing everything into one soup. You’re dealing with three different realities:

2.1. Legacy layer – “how it was then”

• Raw text from documents (exact spellings, ordering, initials)
• Old addresses: “Tanjore Dt”, “Ceylon”, “Madras Presidency”, “Jaffna Kingdom”, etc.
• Name patterns with caste markers or religious titles people actually used
• Historical district/border setups
• Old file formats, column names, and ID numbers

Rule: never rewrite this layer, only annotate it.

2.2. Operational layer – “how we work now”

• Clean internal schema in TamizhConnect:
  • standard fields for place, time, names, relationships
• Canonical names you use as labels
• Normalised district/state/country fields that reflect current political maps
• Tag systems (#southern-tamilnadu, #jaffna, #gulf-migration, etc.)

Rule: this is where you evolve your model and structure as TamizhConnect grows.

2.3. Cosmetic layer – “how we present it outward”

• Exported PDFs
• Screens for elders
• Public-facing family website or book
• Names chosen for resumes, visas, PR, social media

Rule: this can be edited for clarity and safety – but must be traceable back to the operational and legacy layers.

If you don’t separate these mentally, you will accidentally edit legacy data when you meant to fix only cosmetic presentation.

---

3. Typical legacy stuff you’re quietly deleting without noticing

Here’s where you’re already messing up, whether you admit it or not.

3.1. Old caste / community labels

• Original terms in documents:
  • “Harijan”, “Depressed Class”, “Paraiyar”, “Vellalar”, “Nadar”, “Mukkuvar”, “Karaiyar”, etc.
• Later “cleaned” into:
  • “SC”, “BC”, “OC”, or erased entirely.

You don’t have to parade those labels publicly, but deleting them from the archive is historical fraud.

3.2. Colonial + pre-1956 place names

• “Madras Presidency”, “Ceylon”, “Travancore”, “French India”, etc.
• Old districts like “Tanjore District”, “South Arcot”, “Jaffna District pre-split”.

You’re probably rewriting them all as modern Indian states or Sri Lankan provinces, which is fine operationally, but the legacy names must survive somewhere.

3.3. Ugly spellings and “wrong” forms

• Darmalingam vs Dharmalingam vs Tharmalingam
• Pondichery vs Puducherry
• Trichinopoly vs Tiruchirappalli vs Trichy

You’re tempted to “fix” them to a single “correct” form. If you do that by editing the original record, you’ve just destroyed evidence.

3.4. Deprecated columns / fields in old spreadsheets

• Name_1, Name_2, Initial, Village, Caste, etc.
• Old idiosyncratic tags, short codes, abbreviations

When you migrate to TamizhConnect, it’s easy to throw these away as “archaic”. A lot of them encode patterns you haven’t even understood yet.

---

4. How to preserve legacy patterns without turning the UI into a museum

You don’t need to shove every legacy artefact in everyone’s face. You just need to store it cleanly and make it accessible.

4.1. For each person, keep a “Legacy snapshot” section

Inside each profile, have something like:

• legacyRawNames – list of exact names from key documents:

  • "R. MUTHUKUMAR" (SSLC, 1982)
  • "R MUTHU KUMAR" (passport, 1994)
  • "Muthukumar Ramasamy" (UK visa, 2003)

• legacyRawCasteLabel – if present in documents, stored verbatim with a big note:

  • "Depressed Class – Government record terminology, 1930s"
  • "Harijan – typed in revenue record, 1955"

• legacyRawPlaceNames – as written:

  • "Tanjore Dt, Madras Presidency"
  • "Jaffna, Ceylon"

You then map these to modern normalised fields:

• placeNormalized: Thanjavur, Tamil Nadu, India
• countryNormalized: Sri Lanka

The UI can show normalized by default, with an option to expand “View legacy terms”.

4.2. Use tags to mark legacy content, not rewrite it

Instead of editing a caste label from Paraiyar to SC, do this:

• Keep legacyRawCasteLabel = "Paraiyar"
• Add tags:
  • #caste-oppressed, #scheduled-caste, #legacy-term

And in notes:

• “Term ‘Paraiyar’ appears in 1950 land record; modern classification SC; term is considered offensive today.”

That’s how you handle reality like an adult instead of rewriting it into something more comfortable.

4.3. Hide sensitive legacy fields by default, not by deletion

For public or shared views:

• mark legacy fields as private / restricted,
• expose them only to trusted editors or future researchers.

Deletion is permanent. Restricted visibility is reversible.

---

5. Versioning: how to show “before / after” cleanly in TamizhConnect

If you’re going to modernise names and structures (you are), you need a versioning mindset.

5.1. Per field, record transitions, not just the latest value

Instead of:

• name = "Karthik Rajan" and that’s it,

you want:

• nameHistory:
  • 1975–1990: "R. Karthikeyan" (school, village records)
  • 1990–2010: "Karthik Ramasamy" (college, early jobs)
  • 2010–present: "Karthik Rajan" (after surname adoption)

CanonicalName can be "Karthik Rajan", but you still know exactly what came before.

Same for place:

• placeHistory:
  • 1950–1969: "Tanjore Dt, Madras State"
  • 1969–present: "Thanjavur, Tamil Nadu"

Don’t flatten; layer.

5.2. Mark deprecation instead of erasing

If you decide:

• “We no longer use caste labels in public exports,”

you:

• mark legacyRawCasteLabel as deprecated for display,
• keep it in the legacy layer,
• document the policy:
  • “Caste labels preserved only for internal historical analysis; not shown in shared/public views.”

Same for ugly colonial place names or problematic terms.

5.3. Attribute changes to actual events

Whenever the structure changes, ask:

• Did a law change (e.g., state reorganisation, new district)?
• Did a migration event happen (e.g., moved from Jaffna to Toronto)?
• Did a deliberate family decision happen (e.g., adopt surname, drop caste marker)?

Tie version changes to specific events, not random years.

---

6. Rules for editing: what you can rewrite vs what must stay as-is

You need a strict internal discipline, or you’ll slowly vandalise your own archive.

6.1. Safe to rewrite (as long as you log it)

• Canonical labels:
  • Names you use for UI, as long as variants + history exist.
• Normalized place fields:
  • Updating to reflect new official boundaries.
• Tags:
  • You can retag, merge tags, rename them as your understanding improves.
• Operational schema:
  • Adding new fields, better structures, corrected relationships.

6.2. Do not rewrite – ever

• Text copied from original documents:
  • Birth certificates, land deeds, ration cards, war records, etc.
• Raw spellings, even when wrong:
  • If a clerk wrote Mutthukumar, that’s what sits in the legacy layer.
• Original caste/community terminology, even when offensive:
  • You annotate it, you don’t rewrite history.
• Original addresses and jurisdiction labels:
  • “Ceylon”, “Madras Presidency”, etc.

If you correct any of these, you’ve just turned your archive into fan fiction.

---

7. Concrete steps to build and protect your legacy layer

Enough theory. Here’s what you should actually do.

Step 1: Decide which sources count as “legacy”

For your family, pick a baseline:

• All pre-2000 government documents
• All pre-migration documents (before leaving Sri Lanka / India)
• All pre-surname-adoption records

Mark these sources as legacy sources.

Step 2: Set up legacy fields in TamizhConnect

Per person, at minimum:

• legacyRawNames[]
• legacyRawPlaceNames[]
• legacyRawCasteLabel (if present)
• legacyNotes – free text describing any uncomfortable or obsolete terminology.

Per document attached:

• documentType (birth, land, passport, etc.)
• documentYear
• rawNameOnDocument
• rawAddressOnDocument
• rawOtherIdentifiers (NIC, ration card number, etc.)

Step 3: Migrate old spreadsheets without throwing away weird columns

When importing:

• keep weird fields like OldVillage, CasteCode, Name1, Name2 as legacy columns,
• don’t pretend they never existed,
• once mapped, store them in legacy fields or notes, then mark original columns as “archived”.

Step 4: Write a short, brutal legacy policy

Something like:

• We never edit raw text from original documents.
• We preserve old caste/place terms as legacy, with context.
• Canonical names and normalized places can change, but must always link back to legacy forms.
• Any time we adopt new surname or name structure, we log the date and reason.

Put this policy note inside TamizhConnect so whoever edits later can’t claim ignorance.

Step 5: Audit once a year

Once a year, pick a sample of profiles and ask:

• Do we still have at least one legacy name stored?
• Do normalized places still link to at least one legacy place form?
• Have we silently edited away any uncomfortable labels?
• Are we tracking “before / after” for big shifts (migration, surname adoption, border changes)?

If the answer is “no” for any of these, fix it now, before the damage spreads.

---

If you get legacy layer preservation right, your archive will look more complex, but also more honest:

• You’ll see how you moved from villages, initials, caste labels and colonially-named districts
  → to passports, PR cards, Western-facing names and global migration.

If you get it wrong and keep “cleaning” instead of preserving:

• you’ll have a neat little tree with modern spellings and comfortable labels,
• and no real way to show how any of it happened.

Your choice.

Related Articles

• Document Extraction and Conversion for Tamil Family Archives
• Trace Tamil Ancestry :