Migration is a decision about what the new system should remember. Moving every old file is rarely the same as preserving useful product history.
Fashion teams often begin migration by counting spreadsheets and folders. Start instead with the work people must perform after go-live, then identify the data that supports it.
Set the scope by business use
Decide which active seasons, carryover products, materials, suppliers, measurements and documents users need on day one. Archive the rest in a searchable location with a named owner.
Audit quality before mapping fields
Look for duplicate material codes, conflicting supplier names, missing units, inconsistent status values and attachments without a clear product. Mapping bad data precisely still produces a bad destination.
Define the new ownership model
For each core record, name who creates it, who can change it, what fields are required and how approval works. Migration should support the new operating model rather than copy old ambiguity.
Pilot one representative category
Choose a category with enough complexity to expose real issues but a manageable number of active products. Migrate it, run the live workflow and correct the mapping before scaling.
Validate outcomes, not row counts
Ask users to find a product, issue a tech pack, review a sample, update a material and see the effect on cost or timing. A successful import is not enough if the team cannot complete the work.
Plan the cutover and fallback
Set the last edit date in old systems, assign final extracts, communicate which system controls after cutover and keep a short, read-only fallback period. Avoid months of parallel editing.
A good migration produces a smaller, clearer starting point. Users know where current work lives, and the archive remains available without competing with the live record.