Preserving Source IDs When Importing Records
Imports bring years of an organization's history into our platform: members and their memberships, blog posts and their categories, products and their variations, forms and their submissions. Getting each record across is only half the job. The other half is keeping track of where each record came from.
We preserve the original identifier of every imported record, along with enough information to rebuild its relationships. That small habit makes imports safer, more repeatable and easier to troubleshoot.
What a source identifier is
Every system gives its records an identifier: a member number, a post ID, a product code. When a record is imported into our platform, it gets a new identifier of its own. If the original identifier is thrown away, the connection to the source is lost forever.
So we store it. An imported blog post remembers its original post ID and the address where it lived. An imported member remembers their original member record. An imported image remembers the address it was downloaded from.
Imports become safe to repeat
The most immediate benefit is repeatability. Large imports are often run more than once: a rehearsal, a fix and a final run, or an import interrupted partway through. With source identifiers, a second run can recognize records that already arrived and update them instead of creating duplicates.
Without source identifiers, the only way to detect duplicates is to compare names or titles, which fails as soon as two records share a name or someone edits one after import.
Relationships can be rebuilt
Records in the source system point at each other: a post belongs to a category, a membership belongs to a member, a product variation belongs to a product. Those pointers use the source system's identifiers. Our importers bring records across first, then rebuild relationships by looking up each source identifier to find the matching new record.
That approach lets imports bring complex structures across accurately, even when records arrive in an order different from how they relate.
Redirects use the original addresses
Imported pages and posts remember the addresses they had on the old site. That makes it possible to build a redirect map from each old address to its new home, so links and search results keep working. You can read about that in keeping old links alive with redirect maps.
Media remembers its source too
When an importer downloads an image, the media record stores where it came from. If the same image is referenced again, the importer can reuse the stored copy instead of downloading it twice, and the record can explain its origin later. Combined with content fingerprints, this keeps libraries tidy, as described in deduplicating media uploads.
Each import is its own record
An import is not just a background task; it is a record of its own, with the source it came from, when it ran, what it found, what it imported, what it skipped and what failed. If an import stops partway, it can be resumed from that same record rather than starting a new one that might duplicate work. That durable record is also where its verified backup and review results are kept.
Some data stays behind on purpose
Preserving source identifiers does not mean importing everything. Some data should not be recreated, such as old payment charges, which could be confused with new ones, or scheduled campaigns, which could send unexpectedly. Imports bring history as history and leave live actions behind. Source identifiers help here too: it is clear which records came from the old system and which were created new.
Troubleshooting becomes possible
When an organization notices something odd after an import, such as a member in the wrong group or a post with the wrong date, source identifiers let us trace the record back to exactly what the old system said. Without them, troubleshooting becomes guesswork.
Frequently asked questions
Why keep the old ID of an imported record?
Keeping the original ID lets imports be repeated without duplicates, lets relationships between records be rebuilt and lets each record be traced back to its source.
Can an interrupted import be resumed?
Yes. Imports keep a record of their progress, so they can be resumed without duplicating records that already arrived.
Are past payments imported as new charges?
No. Payment history is never recreated as new charges, to avoid confusion with real payments.
Related Posts
Unique Per Customer, Not Unique Everywhere: Composite Keys
Two organizations can both have a page called About. Here is how composite unique keys keep addresses unique inside each account without blocking other customers.
Background Jobs That Remember Whose Work They Are Doing
Slow work like sending email or resizing images happens in the background, long after the request ends. Here is how our jobs carry the right customer with them.
Code That Works on the Marketing Site and Inside Customer Accounts
Some of our code runs on public pages with no customer account at all. Here is how we write shared code that works safely in both places without crashing or leaking.
Letting Customers Get Paid Directly With Connected Accounts
When an organization sells through our platform, the money should land in its own account. Here is how connected accounts, platform fees, refunds and disputes work.
Deduplicating Media Uploads With File Fingerprints
The same logo gets uploaded again and again. Here is how a simple file fingerprint keeps media libraries tidy without ever mixing one customer's files with another's.
Comments (0)
No comments yet. Be the first to share your thoughts!