The order history migration is the part of a Magento 1 to Adobe Commerce project that most teams treat as a checkbox and then discover, three weeks after launch, was actually a customer experience program in disguise. Customers log in to the new store, expect to see the orders they placed last year, and either find a smooth presentation of their history or find a confusing patchwork that drives them to support. The work behind that customer experience is mostly invisible to the project sponsors during the build, and the decisions that produce a clean post-cutover experience get made early, or they don’t get made, and the team pays the cost in support tickets for the next year.
This piece walks through the order history migration decisions that matter most for customer trust on the new store. It is written for engineering leaders, eCommerce managers, and customer service operations leads responsible for Magento 1 to Adobe Commerce migrations. The patterns below come from Bemeir’s migration work and from the postmortems on migrations where order history was treated as an afterthought.
What Customers Actually Expect
Returning customers on a newly migrated store have a small but specific set of expectations about their order history:
- They expect to see the orders they remember placing
- They expect to see those orders with enough detail to be useful (line items, totals, fulfillment status)
- They expect to be able to reorder items from old orders
- They expect their reward points, store credit, and loyalty balances to be unchanged
- They expect any active subscriptions or recurring orders to continue without interruption
Each of these expectations becomes a migration scope decision. Skipping any of them produces specific customer-experience failures, and the failures are predictable. Customers who can’t see old orders email support. Customers whose loyalty balances reset call support angry. Customers whose subscriptions break churn.
Scope Decision One: How Far Back Goes the History
The first scoping question is how much order history to migrate. The default instinct is “all of it,” but the practical answer often turns out to be more nuanced.
Practical considerations:
- Database size and migration runtime grow with history depth
- Very old orders may reference SKUs, customers, or configurations that no longer exist
- Tax law in some jurisdictions requires retention for 7+ years, which is a separate concern from customer-facing presentation
- Customer behavior data suggests most reorders happen within 12-18 months of the last order
A reasonable starting position is to migrate full transactional history (for legal and accounting purposes) but to limit the customer-facing display to the most recent two or three years. Older orders can be made available on request, but they don’t clutter the default customer dashboard.
Document this choice and communicate it. Customers who try to find an order from 2020 should see a helpful message, not a 404.
Scope Decision Two: Status and Lifecycle Mapping
Magento 1 and Adobe Commerce represent order status differently in subtle ways. The default migration tools map most statuses cleanly, but edge cases need attention. Custom order states from Magento 1 customizations need explicit mapping decisions. Fulfillment statuses tied to integrations with external systems (3PL, WMS) need to be preserved or recalculated based on the new state of those integrations.
The most common gap is partial fulfillment status. A Magento 1 order with two shipments that fulfilled in different states can land on Adobe Commerce showing the wrong overall status if the migration only looks at the parent order. Build the mapping with explicit handling for partial shipments, partial cancellations, and partial refunds.
Scope Decision Three: Reorder Functionality
The “reorder” button on a past order is one of the most-clicked features on most eCommerce stores. Customers expect it to work, and they expect the products to be the same products. The migration has to deal with three categories of complication:
- Products that have been discontinued and no longer exist in the catalog
- Products whose attributes have changed (size options renamed, variants restructured)
- Products that exist but are now out of stock or unavailable in the customer’s location
Each category needs an explicit handling pattern. Discontinued products can be shown in the reorder flow with a “no longer available” indicator and a “similar products” recommendation. Products with changed attributes can attempt to match the old configuration to the closest current variant. Out-of-stock products can be added to a wishlist or notify-me list rather than the cart.
The default Adobe Commerce reorder behavior handles some of this but not all of it. The migration team has to specify the behavior explicitly.
| Order history element | Default M1→M2 migration | Customer-trust-aware migration |
|---|---|---|
| Order data | Full migration | Full migration, with display limited to 2-3 years |
| Order status | Direct status map | Explicit handling for partial fulfillments |
| Line items | Direct copy | Mapped to current catalog with fallbacks |
| Reorder button | Default M2 behavior | Discontinued/changed product handling |
| Returns and RMA | Often skipped | Migrated with state mapping |
| Loyalty points | Often skipped or reset | Migrated with audit trail |
| Store credit | Often skipped | Migrated with audit trail |
| Subscriptions | Often broken | Migrated with explicit cutover plan |
| Invoice and shipment numbers | Default reuse or reset | Preserved with documented continuity |
Scope Decision Four: Loyalty Points and Store Credit
If the Magento 1 store ran loyalty points, store credit, or gift card balances, these are not nice-to-have migrations. They are dollars sitting in customer accounts that customers will absolutely notice if they disappear. The migration must account for them.
Most loyalty extensions on Magento 1 store their data in custom tables that the standard migration tools do not cover. The migration team has to either:
- Build a custom migration script that reads from the source tables and writes to the new loyalty extension on Adobe Commerce
- Export balances as a flat file and import them through the new extension’s bulk-update API
- Issue equivalent balances as gift cards or store credit if loyalty extensions differ between the two platforms
Whatever the path, the audit trail is critical. Customer service will receive questions about why a customer’s balance changed, and the team needs to be able to answer.
Scope Decision Five: Subscriptions and Recurring Orders
Subscription-based commerce is one of the hardest things to migrate cleanly. The subscription engine, the saved payment methods, the recurring order schedule, and the customer expectations all need to line up after cutover. Stores running subscriptions on Magento 1 with extensions like Aheadworks or Mageworx have to think about this very carefully.
The practical pattern is to migrate active subscriptions with explicit communication to subscribers. Notify them by email that the migration is happening, what they should expect to see, and how to update their preferences. Give them an opt-out window. Customers feel respected when they’re told what’s happening, and they feel betrayed when subscriptions silently change.
Adobe Commerce’s subscription documentation and the Stripe subscriptions integration guide cover the platform-level concerns, but the customer-experience concerns require the migration team’s explicit attention.
The Cutover Communication Plan
Order history migrations need a customer communication plan. Before cutover, returning customers should receive an email explaining:
- That the store is migrating to a new platform
- What they can expect (their order history will be available, their account will work the same way)
- Any specific actions they may need to take (resetting passwords, re-saving payment methods)
- Where to go for help if something looks wrong
The communication is not just for the customers. It is also for the customer service team, who will receive a wave of questions in the days after cutover and who need to be able to answer them confidently. Pre-staffing the support queue for the cutover window is a discipline most teams underinvest in.
Bemeir’s Magento 1 migration practice treats the customer communication plan as a project deliverable, not as a marketing afterthought. The same discipline applies on broader Adobe Commerce engagements and on platform transitions to Shopify Plus or Shopware.
Post-Cutover Monitoring
The first two weeks after cutover are when order history issues surface. Monitor support ticket categories specifically, questions about missing orders, broken reorder buttons, lost loyalty points. Each category has a different root cause and a different fix path.
Build a dashboard during the migration that tracks order history-related metrics: number of unique customers viewing order history, number of successful reorders, number of failed reorders, distribution of order ages being viewed. The dashboard tells the team whether the migration is producing the customer experience they intended.
Adobe Analytics for Commerce documentation covers the relevant event tracking, and most retail teams already have the tools to instrument these events.
The Trust Equation
The order history migration is, ultimately, a trust exercise. Returning customers are trusting that the new store is a continuation of their relationship with the brand. When the order history looks complete, accurate, and continuous, that trust is reinforced. When it looks broken, scattered, or missing, the trust is damaged in ways that often don’t show up in immediate metrics but do show up in lifetime value over the following year.
The teams that get this right plan order history as a customer experience project from the start of the migration. The teams that treat it as a database copy task discover, three months in, that they need to revisit it anyway, only now with worse data, less customer goodwill, and more pressure. Doing the work upfront is dramatically cheaper than doing it under duress later.
