# Split a legacy address field without inventing its components

Moving from free text to structured addresses is a data interpretation task. Preserve the original, isolate ambiguous records and avoid turning guesses into verified locations.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Keep the original available during conversion

Add structured fields alongside the legacy value before replacing any existing path. Store the parser or matching version and the original text so an incorrect conversion can be reviewed.

A slash may indicate a unit arrangement, but a parser should not treat every punctuation pattern as proof. Organisation names, building details and informal instructions can share the same old field.

Classify results as confidently mapped, ambiguous or unresolved according to explicit rules. A high conversion percentage is not useful if it silently loses destinations.

## Test the outputs the business actually uses

Build a representative sample from permitted, sanitised records. Include multi-line addresses, PO Boxes, long building names and leading-zero postcodes.

Render both old and proposed labels and service destinations. Compare component loss and role assignment, not merely string similarity. Normalising a street abbreviation may be harmless, while dropping a unit changes the intended recipient.

Use manual review for ambiguous role changes. The migration cannot infer whether a customer's old address was their postal office or their service premises from geography alone.

## Introduce readers before switching writers

Deploy application code that can read the structured representation while retaining the legacy fallback. Then update entry and edit flows to write the new model.

Run the backfill in bounded batches with resumable progress. A failed batch should not duplicate address records or create a different customer linkage when retried.

Protect concurrent edits. If a user corrects an address during migration, the backfill must not overwrite the newer revision with a parse of the old value.

## Retire the old field after reconciliation

Count unresolved records and identify the workflows that still read the legacy representation. Validate exports, labels, search and integrations before removing compatibility.

Preserve historical destinations according to the application's records policy. A migration should not rewrite the evidence of an earlier delivery merely to make the schema look consistent.

Rollback may mean returning readers to the old field while retaining new edits for reconciliation. Write that procedure before the cutover, because a database restore could discard unrelated changes made since migration began.

## Sources

- [Australian Government: G-NAF and administrative boundaries](https://www.industry.gov.au/publications/geocoded-national-address-file-g-naf-and-administrative-boundaries-ab-data)