Moving Your Export Business Off Excel Without Losing History
The barrier to leaving spreadsheets is rarely the software — it is the years of data inside them. This is the practical mechanics of moving that data across, and what to bring versus what to leave behind.
Most exporters who want to leave spreadsheets do not stay because they are satisfied. They stay because of the migration — years of buyer details, product data, order history and pricing sitting in files that everyone depends on and nobody entirely trusts.
This page is about that specific problem: how to get export data out of Excel and into a working system, in what order, and how to decide what is worth bringing. It is a mechanics page rather than an argument about whether spreadsheets are limiting.
The short version is that migration is more manageable than it looks, provided you resist the instinct to bring everything and sequence the move by data dependency rather than by importance.
The problem
Why spreadsheet migrations stall
The everything instinct
Teams try to migrate every historical record at once, which turns a two-week job into an indefinite one.
Masters were never masters
Buyer and product details were retyped per file, so there is no single correct version to import.
Nobody owns the cleaning
Data cleanup is real work with no obvious owner, so it falls between operations and whoever suggested the move.
Parallel running forever
Without a cut-off date the spreadsheets stay live, and the new system becomes a second place to enter things.
The solution
What makes an export migration workable
Excel bulk import
Customers, products and inventory import from Excel rather than being retyped.
Duplicate detection
Near-identical buyer records are surfaced at import rather than discovered months later.
Masters before transactions
Buyers and products load first, so orders have something valid to attach to.
Open orders as the starting set
Live orders migrate in full; closed history moves only where it earns its place.
Attachment retention
Existing documents can be attached to migrated records and are OCR-indexed for search.
Defined cut-off
A single date after which new orders exist only in the new system.
How it works
The migration sequence
Clean and load masters
De-duplicate buyers and products in the spreadsheet, then import them first.
Bring open orders across
Migrate live orders with their current stage, then set a cut-off date for new entries.
Add history selectively
Import closed orders only where they support pricing decisions or scheme reconciliation.
What to bring and what to leave behind
The single decision that determines whether a migration finishes is what you choose not to move. The instinct is to bring everything, on the reasoning that data might be needed one day. In practice, importing years of closed orders imports years of accumulated inconsistency along with them, and every hour spent reconciling a shipment from four years ago is an hour not spent getting the system live.
Masters always come across, because everything else attaches to them. Buyers, products, vendors and any production partners are the foundation, and they are also where cleaning pays off most — a de-duplicated buyer list is worth more than any amount of historical order detail.
Open orders always come across, in full, with their current production stage. These are the orders the business is actually running, and they are the reason the system exists on day one.
Closed history is the genuinely optional part, and it should be brought selectively rather than wholesale. The test is whether a record will be used: recent orders for buyers you still serve support pricing and repeat business; shipments with open scheme claims need to be reconcilable. A closed order from a buyer who stopped trading with you is an archive entry, and archives can stay in the spreadsheet where they already are.
Cleaning buyer and product data before it moves
The most common discovery during an export migration is that the buyer master was never really a master. Because each order file was created by copying the last one, buyer details were re-entered rather than referenced, and over several years small divergences accumulate — an abbreviated company name here, a superseded address there, two spellings of the same city.
Cleaning this is unglamorous and worth doing properly, because every downstream benefit depends on it. Documents generated from a buyer record are only as good as that record, and a system with three versions of the same buyer will produce three versions of the same certificate.
The practical method is to consolidate in the spreadsheet before importing, not after. Sort by a normalised company name, collapse variants, and choose one current address and legal name per buyer. Where you genuinely cannot tell which version is current, ask the buyer — it is a short email and it resolves the question permanently.
Product data deserves the same treatment, with one addition: this is the natural moment to review HS classification. Codes copied forward between orders are a well-known source of customs queries, and a migration is the one time when every product is being looked at anyway.
Setting a cut-off and avoiding parallel running
The failure mode that quietly kills spreadsheet migrations is indefinite parallel running. The new system goes live, the spreadsheets stay open because people are still comfortable with them, and within a month there are two places to check and neither is complete.
The remedy is a single announced cut-off date after which new orders are created only in the new system. Existing open orders migrate before that date; anything starting after it begins in the system. The spreadsheets remain readable as an archive, but nothing new is entered in them.
It is worth being explicit that a cut-off is uncomfortable for a week or two and that this is expected rather than a sign the migration went wrong. People are fast in the tool they know. The productivity dip is short and the alternative — two half-maintained systems — is permanent.
One practical accommodation helps considerably: keep the spreadsheets accessible read-only rather than deleting them. Most of the anxiety about leaving a spreadsheet is about losing access to something, and read-only access removes that entirely while still preventing new entry.
How long a migration actually takes
For a typical export house the work divides roughly into three parts, and only one of them is technical. Cleaning masters is usually the longest — it depends entirely on how much divergence has accumulated and how quickly someone can make decisions about which record is correct.
The import itself is fast. Customers, products and inventory load from Excel, and the constraint is the quality of the file rather than the volume of rows. Open orders take longer because current production stage has to be set correctly, which requires someone who knows where each order genuinely is.
Learning the system runs in parallel and continues past go-live. This is the part most likely to be underestimated, not because the software is difficult but because the first weeks involve doing familiar work in an unfamiliar order.
TODO(owner): if you want a specific typical timeline stated here — for example a number of working days for a given order volume — supply the figure from your own implementations. We have deliberately not estimated one, since an invented duration would set expectations you would then have to meet.
Frequently asked questions
Can I import my existing Excel data into ExportCRM?
Yes. Customers, products and inventory import in bulk from Excel, with duplicate detection surfacing near-identical buyer records at import rather than months later. The recommended sequence is masters first — buyers, products, vendors and production partners — because orders need valid records to attach to. Open orders then migrate with their current production stage, and closed history is brought across selectively.
Should I migrate all my historical export orders?
No, and trying to is the most common reason migrations stall. Bring masters and all open orders, then apply a test to history: will the record actually be used? Recent orders for buyers you still serve support pricing and repeat business, and shipments with open scheme claims need to be reconcilable. A closed order from a buyer who no longer trades with you is an archive entry and can stay in the spreadsheet.
How do I clean buyer data before migrating?
Consolidate in the spreadsheet before importing rather than after. Sort by a normalised company name, collapse the variants that accumulated from copying order files, and choose one current legal name and address per buyer. Where you cannot tell which version is current, ask the buyer directly. This matters because documents generated from a buyer record inherit its errors — three versions of a buyer produce three versions of a certificate.
What is a cut-off date and why does it matter?
It is a single announced date after which new orders are created only in the new system, with existing open orders migrated beforehand. Without one, spreadsheets stay live alongside the new system and within a month there are two incomplete places to check. Keep the old files accessible read-only rather than deleting them — that removes most of the anxiety about leaving a spreadsheet while still preventing new entry.
Is a migration a good time to review HS codes?
Yes, and it is arguably the best time. HS codes copied forward from one order to the next are a well-recognised source of customs queries, because a similar-looking article can classify differently. A migration is the one occasion when every product record is being examined anyway, so the incremental cost of confirming classification is low and the downstream benefit — fewer shipping bill queries and correct scheme eligibility — is substantial.
Plan the move properly
Book a free demo and we will walk through what to migrate, in what order, and what to leave in the spreadsheets.