CRM migration project plan for ecommerce: a practical checklist

1. Define the migration boundary

Write down what is changing and what remains the system of record. A store may keep Shopify for catalog and orders while moving CRM workflows elsewhere; another may also change checkout, subscriptions, or its payment processor. Those are different projects. List the systems that create, read, or update each object, then name the future owner of that object.

Decide what must work on day one: lookup of an existing customer, correct attribution of a new order, refund handling, an upcoming renewal, and support access are usually more consequential than an old campaign tag. Shopify's own migration guide separates products, customers, and historical orders and recommends importing products before customers before historical orders so relationships can be connected. Use the same dependency logic when your destination differs. Shopify migration guide.

Use the order-ID and event checklist in our ecommerce attribution guide to verify the customer-to-order trail after the move.

2. Inventory records and build the field map

Take a dated snapshot of each source and record its row count, unique ID count, newest update time, and export method. Separate active customers from archived records and test accounts. Define the migration window in one timezone. Keep a source-to-destination ID crosswalk so a customer, order, variant, and subscription can be joined after import even if the destination generates new IDs.

For every field, document the source, destination, transform, default, owner, and validation rule. The field-mapping worksheet includes example rows. They are prompts, not destination schema or an import file. Give particular care to marketing consent and timestamps: an empty value is not permission, and a date without a timezone can move a renewal to a different day.

• Customers: stable source ID, email and phone normalization, addresses, consent source and timestamp, duplicate handling.
• Catalog: product and variant IDs, SKU, price currency, archived status, and any subscription plan mapping.
• Orders: source order ID, customer and line-item links, currency, discounts, taxes, shipping, status, captures, refunds, and fulfillment state.
• Subscriptions: source subscription ID, customer, product or price, interval, next renewal, status, retries, and payment-method reference.
• External systems: ad, email, helpdesk, warehouse, tax, and analytics IDs that must survive in a crosswalk or supported custom field.

Check the destination's actual import surface before promising a field. For example, Shopify's customer CSV cannot import order information or its calculated Total Spent and Total Orders values, and passwords from another store cannot be moved through that CSV. Shopify also warns that overwriting customers matched by email or phone replaces their customer data, so test duplicate handling on a small cohort. Shopify customer CSV documentation.

3. Give each phase an owner and an exit gate

A plan is useful when every phase produces evidence for the next one. The schedule below is illustrative for a mid-sized store; volume, API limits, processor coordination, and an approaching billing cycle can change it substantially.

The billing lead's work can be the critical path. Stripe's migration documentation, for example, directs teams to coordinate with the previous processor, plan a remapping file, and include subscriptions where applicable. That is a provider-specific example of why payment portability should be established early, never assumed. Stripe data migration overview.

4. Rehearse with awkward records, not only clean ones

Choose a small test cohort that includes a guest checkout, a customer with multiple addresses, a shared email or changed phone number, a canceled order, a partial refund, a multivariant product, a paused subscription, and a renewal near midnight. Load the cohort into a safe test environment or clearly isolated destination segment. Log each source ID against the destination ID and expected outcome.

Run the real workflows against those records: support finds an order from a customer profile; a refund does not look like new revenue; a paused subscription stays paused; lifecycle messaging respects the original consent. Check that imports do not send customer notices or trigger automations unexpectedly. If migrating into Shopify, its guide specifically notes that importing historical orders can generate new-order emails to staff unless those notifications are disabled during import. Shopify migration guide.

Record each defect with severity, owner, fix, and retest result. Repeat the rehearsal from a fresh snapshot after changing a mapping rule; otherwise, a green report can be evidence for an obsolete transform.

5. Reconcile records, relationships, and money

Record counts are a first check, not a pass. Reconcile at the same cutoff timestamp and with the same definitions on both sides. Count unique source IDs, imported IDs, rejects, intentional exclusions, and duplicates separately. Then check links: every migrated order should resolve to the intended customer and line items; every active subscription should resolve to the intended customer and product or price.

For an illustrative acceptance rule, a team might require zero unexplained active subscriptions without a payment path, zero missing orders in the cutover window, and every money variance either corrected or signed off with a documented cause. The actual threshold belongs to your finance and billing owners. Keep the pre-cutover export, mapping version, queries, and results together so they can repeat the calculation after launch.

Make those buckets mutually exclusive. Count duplicate rows deliberately removed during deduplication as intentional exclusions. “Accepted source rows” counts source rows mapped successfully, not destination records: several source IDs can merge into one destination customer. Keep that crosswalk and reconcile destination record counts separately.

6. Treat payment credentials and renewals as a separate workstream

A token in one processor is not proof that another system can charge it. Before selecting a cutover date, ask the current processor and destination payment provider: Who owns the vault? Which payment methods and regions are eligible for transfer? Will they move credentials directly? What customer-to-payment ID mapping will be returned? Do network tokens, mandates, or authentication requirements change? What is the fallback for accounts that cannot be moved? Get answers in writing and assign an owner to each exception.

Never put card numbers or card verification codes in a CRM export or the field-mapping worksheet. PCI Security Standards Council guidance says card verification codes cannot be stored after authorization, including for card-on-file or recurring use. Stripe describes processor-coordinated transfer of sensitive payment details and explicit remapping for subscriptions; its process is an example, not a guarantee for another provider. PCI SSC guidance; Stripe migration overview.

Check the first upcoming renewal for each migration cohort: date in its business timezone, amount and currency, discount, tax, retry state, and whether the old or new system is responsible for charging it. Prevent both systems from billing the same subscription. If credentials cannot move, plan a customer update flow and its communications before setting the date. Our subscription payment gateway guide covers the gateway questions in more detail.

7. Cut over with a written stop condition

Choose a low-volume window away from promotions and renewal peaks. Publish a runbook with a timestamped source snapshot, import order, integration switch sequence, named decision maker, check-in times, and contacts. Pause writes or queue changes only where the source systems support it; capture the delta since the last rehearsal and prove it can be replayed once. Keep the old system accessible in read-only mode until support and finance no longer need it.

• Go: critical reconciliation checks pass, payment path is confirmed, test checkout and refund pass, support can find records, and each owner signs the log.
• Stop: missing cutover-window orders, unexplained financial variance, duplicate charge risk, broken customer lookup, or a failed renewal path.
• Rollback: name the authoritative writer for new orders and renewals, reverse routing or integration switches in the documented order, preserve transactions already made, and reconcile the delta before retrying. Never blindly re-import paid orders.

Rollback is a business decision as much as a technical one. Once a new system has charged a card or issued a refund, flipping a switch does not erase that transaction. The incident lead should record the exact point of no return for each workflow and require a manual resolution plan for anything beyond it.

8. Monitor the first cycle and close the project deliberately

For the first day, watch new customer creation, order ingestion, checkout success, refund processing, sync failures, and support search. Continue daily checks through the first meaningful renewal cycle. Compare new transactions against both the payment processor and the destination system, and assign every discrepancy to an owner. Confirm marketing and support teams know where to look for pre-migration history.

Close only when the exception queue is resolved or explicitly accepted, the ID crosswalk and mapping decisions are stored securely, access to old exports is reduced, and retention or deletion follows your own policy. If you are evaluating Admoji as the destination, its public site describes CRM, checkout, Shopify sync, and reporting together; ask the team to demonstrate your specific customer, order, subscription, and payment workflow against this plan before committing to a cutover. Admoji platform overview. For the wider question of what Shopify itself covers, see Is Shopify a CRM?