Most ERP migrations start with a target date and end with a surprise. The surprise almost always sits in the legacy landscape: custom fields nobody can explain anymore, interfaces only one person knows, data full of duplicates and gaps that surface during mapping. Discovery means pulling those surprises forward while they are still plannable rather than expensive.
That is why every ERP change I run starts with a documented inventory. It captures what actually runs, not what the system documentation claims, which is rarely complete in grown environments.
What discovery documents
Three layers. First, the legacy systems themselves: extensions, special cases, configuration states. Second, the interfaces, including manually maintained translation tables and file exports that appear in no architecture diagram. Third, the data: duplicates, gaps, fields whose meaning has drifted over the years. An M&A integration from my project work shows how far this can go: the acquired company’s legacy systems were undocumented, so discovery ran as reverse engineering, tracing and recording every interface one by one.
The target date follows the findings
Fixing the go-live date before discovery means planning against unknown risks. The findings show which data can be migrated, where the mapping risks sit and what that means for effort and sequence. Only then is a date reliable; unrealistic schedules are among the five most common mistakes in ERP migrations.
Clean up inside the project, not before it
Discovery does not mean scrubbing data for months before starting. Cleansing that runs ahead of the project cleans data that keeps aging in the meantime; I have written about why this data-first sequence stalls projects. Discovery makes the problems visible and prioritizes them; the cleanup happens in project context, where a field is actually needed. The result is the working basis for field-by-field mapping and validation.