In brief
Before committing to a new business platform, export a representative sample and prove that it can be imported with the right relationships, files and totals. Treat missing fields and broken attachment links as planning findings, not surprises for launch day.
1. Export one real workflow before choosing the replacement
A software demonstration shows how the new system works with clean sample data. A migration test asks a different question: can your business keep working with the records it already has?
Choose a small, authorised sample that follows one complete workflow, such as a customer, an order, its line items, a payment and an attached document. Include an awkward case too: a cancelled order, a partial payment or a customer with multiple contacts. Keep personal data out of sales demos and use a restricted test environment for any real records.
Write down what must survive the move before you export. That list becomes an acceptance checklist for the new platform, whether you select packaged software or commission a custom system.
2. Keep record IDs and relationships together
A list of customers and a list of orders are only useful if each order can still be linked to the correct customer. Preserve stable identifiers and document how records refer to one another. A familiar display name alone can be ambiguous when two people or companies share it.
HubSpot's official documentation provides a useful example of why export settings matter: record exports include current property values and associations, while activities such as calls and notes require other export routes. Its import guidance also requires unique identifiers when updating records or avoiding duplicates. These are product-specific details, not a promise that every platform behaves the same way.
For your own migration, keep a mapping between each source ID and its destination ID. Check one-to-many relationships, ownership and status history separately instead of assuming that a successful file upload preserved them.
3. Download the files, not just their links
An attachment column may contain a URL rather than the document itself. Test whether the file can still be retrieved after the export session ends, and whether access depends on the old account.
Airtable, for example, documents that attachment download URLs expire and recommends downloading attachments before those links expire. A CSV containing such URLs is therefore not a durable copy of the files. This is an existing platform behaviour, not a new product announcement.
Where permitted, preserve the actual files in controlled storage together with a manifest linking each file to its source record. Retain filenames, file types and a checksum where useful. Open a sample of images and PDFs in the destination system, and check that access restrictions still match the intended audience.
4. Reconcile meaning as well as row counts
The same number of rows in two systems does not prove that the migration is correct. Dates can shift with time zones, leading zeros can disappear from reference numbers, and a blank value may be interpreted differently from zero.
Before importing, record the meaning and format of important fields: currency, tax treatment, payment status, units, local dates and timestamps. Keep the original export unchanged and perform transformations on a working copy. Record deliberate exclusions and any values that need manual review.
After a sample import, compare counts by record type and status. For financial records, reconcile the relevant totals using consistent currency and rounding rules. Then ask an operational user to follow a few records from beginning to end. Check the exceptions deliberately; they often reveal missing rules that a clean sample would hide.
5. Make the test a decision gate
Agree on the evidence needed before switching systems: required fields mapped, essential relationships intact, attachments accessible, totals reconciled and exceptions assigned to an owner. Document how long export and import take, who can run them, and any subscription or permission requirements.
Plan how changes made during the move will be captured. Keep the old system available under an agreed read-only or rollback plan until the new records have been checked. A trial import should not trigger live customer emails, invoices or other automation.
MIRA CODE builds custom software around business workflows. For a replacement project, these test results give the team a concrete starting point: which data needs to move, what the new workflow must preserve and where an integration may be more practical than a full replacement. Resolve those questions before committing to the cutover date.
