Plan and execute structured migrations from spreadsheets, legacy websites, warehouse systems, CRM platforms, rental systems and supported exports using source assessment, field mapping, cleansing, deduplication, staged imports, reconciliation, cutover and rollback controls.
Data Migration is a finite implementation workstream. It prepares trusted opening data for Commerce OS; ongoing connections after go-live belong under Integrations or the relevant connected module.
The correct migration scope depends on what the client needs to operate from day one, what must remain accessible for reference and what can safely stay archived outside Commerce OS.
Move the current catalogue, inventory, locations, users and core relationship data needed to begin operations.
Add the history required for continuity, reporting, service, rental, transaction or custody context.
Move several source systems in controlled waves while maintaining cross-system identifiers and reconciliation.
Migration quality depends on more than import scripts. The source data, transformation rules, relationships, exception handling and acceptance criteria all need to be explicit.
Inventory the systems, files, tables, media, identifiers, owners, history and data-quality risks before transformation begins.
Translate fields, categories, statuses, relationships and identifiers while resolving invalid values, duplicates and missing required data.
Test imports, compare source and destination counts, values and relationships and resolve exceptions before production cutover.
Control the final source freeze or delta, final import, opening-state validation, rollback evidence and production acceptance.
Start with the complete migration architecture, then move through source inventory, profiling, field and relationship mapping, cleansing, deduplication, dry-run imports, reconciliation, cutover, rollback evidence and migration close.
The first migration task is to identify what data exists, where it lives, who owns it, how trustworthy it is and what the source system can actually export.
Current operational data and historical reference data do not always need the same migration treatment. The assessment should define what must become live Commerce OS data, what may remain read-only history and what can be archived.
Document every source that contributes to the intended opening state.
Measure what can be migrated reliably and what needs remediation.
Decide which historical connections must survive the move.
Define what counts as a complete and accepted migration before execution begins.
Migration rules should show exactly how each source field and value becomes a Commerce OS field, category, status, relationship or retained legacy reference.
Cleaning and deduplication should be controlled. Records should not be merged, discarded or normalised without a traceable rule and, where necessary, review.
Translate source structures into the destination schema.
Preserve the structural relationships the operating platform needs.
Resolve unreliable source data without hiding the original problem.
Retain enough source reference to trace destination records back to the migration input.
A dry run should use the real mapping rules and representative source data in a controlled destination environment, not just a sample spreadsheet transformation.
Reconciliation should compare what was expected with what was successfully created, skipped, transformed, rejected or linked so the client can approve the migration rules before go-live.
Execute the migration logic in staging before production data is affected.
Compare source and destination at the level relevant to the data set.
Fix the migration rule rather than repeatedly patching individual destination records.
Approve the migration based on defined evidence rather than visual spot checks alone.
The final migration should define what happens to source-system changes during cutover. Depending on the implementation, the old source may be frozen, a final delta may be extracted or the migration may occur in controlled waves.
Production acceptance should confirm the usable opening state and retain enough evidence to diagnose or reverse the cutover if a critical migration issue is found.
Control what changes are allowed between final source extraction and go-live.
Run the approved migration rules and validate the destination opening state.
Prepare a response if a critical defect is discovered during cutover.
Close the migration programme without losing historical evidence or ownership context.
The sequence makes data quality, transformation rules and acceptance visible before the client depends on the migrated data operationally.
Inventory systems, exports, media, owners, counts, data quality and required historical depth.
Define destination fields, categories, statuses, relationships, identifiers and transformation rules.
Address invalid values, duplicates, missing required data and relationship exceptions.
Import into staging, compare expected and actual results and correct rules before production.
Run the final freeze or delta strategy, approved import and opening-state checks.
Complete acceptance, archive migration evidence and transition ongoing changes to operations or integrations.
Migration moves and reconciles a defined body of legacy data into the opening Commerce OS state. Integrations maintain ongoing data exchange after the destination is live.
The Services page describes a broader managed onboarding and migration service. This page describes the Commerce OS migration workstream and controls used when bringing client data into the software platform.
The implementation should identify who can authorise source extraction, who owns the meaning of the legacy data, who configures transformations and who accepts the destination opening state.
A spreadsheet catalogue, long-running rental platform and multi-site WMS require different extraction, transformation, reconciliation and cutover approaches.
The final migration scope depends on source access, data quality, historical depth, identity relationships, required opening state, downtime constraints and acceptance requirements.
Yes, where the source data can be structured and mapped. Spreadsheet migrations still require field definitions, validation, duplicate rules and reconciliation before production use.
Potentially. The approach depends on the source system’s export capability, schema, data quality, identifiers and the scope of data the client needs in Commerce OS.
No. The client can define the history required for operational continuity and reporting, while older or less useful data may remain in an approved archive if that better fits the implementation.
Deduplication rules should identify probable matches and route material merge decisions through approved rules or review. Original source references should remain traceable.
Yes, where useful. Legacy identifiers can be preserved as source references so migrated records can be traced back to the originating system or export.
A dry run executes the intended mapping and transformation rules in a controlled environment so counts, relationships, values and exceptions can be reconciled before production cutover.
The migration should use agreed acceptance criteria such as counts, opening balances, relationship checks, media completeness, sample operational testing and a documented exception register.
The cutover plan should define a source freeze, final delta extraction or phased boundary so changes are not silently lost between the final source extract and go-live.
No. Data Migration moves a defined legacy data set into the opening Commerce OS state. Integrations maintain ongoing exchange between live systems after go-live.
No. Services → Implementation & Migration is the broader managed service proposition. This page describes the Commerce OS migration workstream and platform controls used when moving client data into the software.
We will map source systems, fields, categories, identifiers, relationships, duplicates, historical depth, dry runs, acceptance criteria, cutover, rollback, archive and the transition to ongoing operations or integrations.
Login