What is a recommended data migration approach to move legacy addresses into the new system?

What is a recommended data migration approach to move legacy addresses into the new system?

• A. Migrate all fields in one go without cleansing or deduplication
• B. Map legacy fields to new schema, cleanse data, deduplicate, run staged migrations, verify counts, and maintain rollback plans
• C. Only rename fields
• D. Create a new system and abandon legacy data

Answer: (B)

The main idea here is to move data in a controlled, quality-focused way that fits the new system and preserves data integrity. The best approach starts with mapping each legacy field to the corresponding place in the new schema so every address component lands where the new system expects it. Then cleanse the data to standardize formats, fix invalid entries, and normalize fields like street, city, state, and postal codes. Deduplicating is crucial because legacy stores often contain duplicates that can cause confusion or errors in the new system.

Running migrations in stages lets you validate at each step—check row counts, spot inconsistencies, and confirm that the data looks right before moving the next batch. Verifying counts and sampling records helps ensure nothing unexpected slipped through. Maintaining rollback plans is essential so you can revert quickly if you discover issues after a migration step, minimizing downtime and data loss.

Why the other options don’t fit: migrating everything in one go without cleansing or deduplication transfers dirty, inconsistent data that will pollute the new system and undermine reliability. Merely renaming fields doesn’t address data structure or quality. Building a brand-new system and discarding legacy data loses valuable history and continuity. The staged, cleansed, deduplicated, and verifiable approach provides a reliable transition with a safety net.