An ecommerce migration must preserve the information and behaviour your business relies on: products and variants, identifiers, relevant customer and order records, discounts, URLs and connected workflows. Start with an inventory and test representative records before planning the live move.

A successful import message does not prove that the new store works. The important question is whether customers can buy the right products and your team can fulfil, reconcile and support those orders.

Agree what is moving and what is staying

List the source and destination platforms, the records in scope and the person responsible for each area. Identify information that will remain in an archive rather than the new store. Check what each platform can export and import; field names alone do not establish equivalent behaviour.

Keep identifiers and relationships intact

Check SKUs, variant relationships, source IDs and any external references. Decide which identifiers the destination will retain and which need a mapping. Avoid matching only by a product name that can change or be duplicated.

Include products with several variants, unavailable items, unusual characters, missing values and different image arrangements in your test set. Confirm that descriptions, prices, stock and variant selection mean the same thing after import.

Check customer and order behaviour

Separate record transfer from account access. Do not assume passwords, saved payment methods or every historical order state can move between platforms. Check the destination’s supported migration process and decide how staff will retrieve records that remain in an archive.

Use approved sample records to test relationships, totals and status. Limit access to customer information and agree which records genuinely need to move before exporting them.

Recreate discount rules, not just discount names

Check eligibility, date ranges, minimum spend, product restrictions and whether discounts can combine. A rule that imports into a field may still behave differently at checkout. Test both an order that should qualify and one that should not.

For Neto work, distinguish coupon/discount records from product sale-pricing promotions. The Neto Bulk Discount Importer reference explains its verified CSV workflow; it is not a general migration tool.

Map URLs to their closest relevant destination

Inventory important product, category, content and image URLs. Where URLs change, map each old page to an equivalent new page where one exists. Avoid sending every old product to the homepage. Update internal links, canonicals and sitemaps, then test the resulting paths.

Google’s site-move guidance covers URL mapping, redirects and monitoring. Search visibility can fluctuate while changes are processed; a migration plan should include follow-up checks.

Test the systems around the store

Trace a representative order through payment, fulfilment and any accounting or stock connection. Check field mapping, timing, repeated updates, refunds where supported and what happens when a connection fails. Assign someone to the exception queue rather than assuming every update succeeds.

Make cutover and recovery explicit

• Keep a usable backup/export and record when it was taken.
• Agree how new orders and updates will be handled during the move.
• Set reconciliation checks and acceptance criteria before launch.
• Name the person who decides whether to proceed, pause or recover.
• Document the limits of rollback once new transactions exist.
• Monitor orders, broken links and failed integrations after launch.

Recovery is a process to plan and test, not a promise that restoring a backup will reconcile everything created after cutover.