Direct answer
Decide before the load whether records keep their old IDs or receive new ones, and in either case store the old ID next to the new record. Then keep a crosswalk, a simple table that pairs each old ID with its new one. That table lets you rebuild the links between records, re-run a load without creating duplicates and answer the question that will come up after cutover: what happened to record number such-and-such. This page is about IDs and references. General field mapping is covered in CRM data mapping for migration.
Where old IDs live outside the system
The system's own users are not the only ones holding old numbers. Look for them in:
- Issued invoices, quotes and delivery notes
- Emails and chat messages that quote a reference
- Bookmarks and links to pages or records
- Partner, customer and supplier documents
- Spreadsheets and reports kept by individuals
New ID or preserved ID: the decision
Some targets allow you to load records with the IDs they already had, and some assign their own and ignore yours. Do not assume either. Check what your target can accept, and decide accordingly. If old IDs can be kept, references outside the system keep working, but you inherit any gaps or quirks in the old numbering. If new IDs are assigned, you get a clean start, but every outside reference now points at something that no longer exists unless you can translate it. Neither is right in general. The right answer depends on how many outside references you can not update.
A legacy-ID field and a crosswalk
Whatever you decide, keep the old ID on the new record in a field of its own, visible to users who might need it and searchable. Alongside it, keep a crosswalk table, one row per record, with the old ID, the new ID and the record type. Keep it after the migration finishes, as a document, and not only in the working files of whoever ran the load. The crosswalk is your evidence and your translation tool.
Rebuilding relationships from the crosswalk
Records refer to each other: a contact to a company, an order to a customer, a task to a project. In the old system those links use old IDs. Load the referenced records first, then use the crosswalk to replace each old reference with the new ID. If a link points to an ID that is not in the crosswalk, you have found an orphan, which needs a decision rather than a silent skip. The sample checks in data formats before migration also help here, because IDs are often altered by spreadsheets.
Re-running a load without creating duplicates
A load rarely goes perfectly the first time. If you must run it again, the process should check the crosswalk before creating a record: an old ID that is already paired with a new one is updated or skipped, not created again. That is the same principle that prevents duplicates elsewhere, and it is the reason to keep the crosswalk updated during the load, not only at the end. When a load goes wrong, see what to do when a data migration partly failed.
Looking up an old number after cutover
Someone will phone with an old invoice number. Decide in advance where they look it up: a search box on the legacy-ID field, or the crosswalk file held by a named person. Tell the team where it is. If the old system stays available read-only for a time, say who may use it and until when. A quiet answer at the point of need is worth more than a perfect migration nobody can navigate.
Make it a sign-off item
Add explicit checks to the acceptance list: pick a sample of old IDs from real documents, find each in the new system through the legacy-ID field, and confirm that the related records also carry over. The general planning around this sits in the legacy system data migration plan, and the spreadsheet case in spreadsheet to database migration.
Where LATYNEX fits
If your target is a custom web application, portal, integration or internal tool, we can include the legacy-ID field, the crosswalk and the relationship rebuild in the data migration plan, agreed in writing before work starts. See Web Application Development.
When LATYNEX is not the right fit
It is not the right fit for a pure vendor-to-vendor move that needs no custom build, where the target platform's own import rules decide what is possible. It is also not the right fit for an IT file-server migration. Nothing on this page claims that any given platform accepts imported IDs.
Questions
Should I keep the old IDs or let the new system assign new ones?+
It depends on what the target accepts and how many outside references you cannot update. Whichever you choose, store the old ID on the new record.
What is a crosswalk?+
A table pairing every old ID with its new ID, with the record type. It lets you rebuild links, re-run loads safely and translate old references.
Where might old IDs be referenced outside the system?+
Invoices, emails, bookmarks, partner documents and personal spreadsheets are the usual places. Check each before deciding.
How do I avoid duplicates if I run the load twice?+
Check the crosswalk before creating each record. An old ID already paired with a new one is updated or skipped, not created again.
How does someone find an old record after cutover?+
Through a searchable legacy-ID field on the new record, or through the crosswalk file kept by a named person.