what really has to move.
Not all history has to move. Start by asking who will look at it, and why. Customers want to see their orders, invoices and returns. Finance already has the invoices in the ERP. Everything else is archive, and archive does not have to live in the new webshop.
For each kind of data, decide what happens: move and show to the customer, move but keep internal, or keep an export only. That stops you spending weeks on data nobody will ever open. It also sets the size of the work, and so the price you can agree up front.
data quality and mapping.
The old system always holds things that do not fit the new one. Think of duplicate customers, missing email addresses, statuses the new system does not have, and products that have not been sold for years but still appear in old orders. Every mismatch needs a decision: clean it, convert it or drop it.
Those decisions belong to someone on your side, not to whoever builds. Write the mapping down: which old field becomes which new field, and what happens to the mismatches. Get that document approved before any data moves. A mapping invented during the migration leads to surprises after go-live.
dependencies and load order.
Orders refer to customers, addresses and products. Load them in the wrong order and orders end up detached from their customer, or you get duplicate customers because the integration cannot find an existing one. Work to a fixed order: products and customers first, then addresses, then orders and order lines, then invoices and returns.
Test that whole sequence on a copy of the real data. A small sample does not show the problems that appear at large row counts, such as run time, memory and the limits of the new platform's API.
validation.
You prove nothing was lost with counts and totals: customers and orders per year, revenue per month and the number of order lines, old and new side by side. Add spot checks. Take ten customers with a long history and compare what each sees in both systems.
Decide up front what "correct" means, for example no difference in monthly totals. Otherwise validation stays a feeling, and a feeling is no basis for switching the old system off.
cutover and rollback.
A migration with years of data should not run for the first time on the day of the switch. Rehearse the whole cutover at least once and time every step. Agree a freeze moment after which nothing changes in the old system, and decide what happens to orders that arrive in the meantime.
Also agree in advance the point at which you roll back if validation fails, and keep the old system unchanged until then. Anyone who first thinks about rolling back during the switch does so under time pressure.
An example from practice: a customer moved to a new webshop and a new WMS at the same time. During the switch nobody recorded which WMS each order had gone to. Other automated processes needed that information to keep working correctly. The result was that orders that went to the old WMS had to be handled manually, while new orders could run fully automatically. Together with the customer we solved it with a reconciliation flow. It is a lesson for every switch: record per order which system handled it, and think of it up front rather than afterwards.
checklist.
- For each kind of data decided: move, keep internal, or export only.
- Mapping written down and approved by an owner on your side.
- Load order fixed and tested on a copy of the real data.
- Control figures agreed: counts and totals per year and per month.
- Spot check planned with customers who have a long history.
- Rehearsal of the cutover done, with timings.
- Freeze moment, rollback point and responsible person agreed.
On Profuomo's new webshop we moved historical data across so customers could still see what they had bought before. Read the Profuomo case for the whole project. Want to know what has to move in your migration? Tell us which systems you are replacing and we will tell you in one call what it involves.
