Shopware Platinum Partner
Extension Premium Partner
200+ Projects
75+ Experts
Preparing historical order data is a key step when migrating to Shopware. This guide explains how to assess which past orders to import, highlighting best practices such as including at least the last two to three years of data for active customer continuity and analytic value. solution25 clarifies how thoughtful data selection and preparation supports operational consistency and business intelligence after migration.
Free 15 min initial consultation directly with our experts.
In today’s fast-paced eCommerce world, data is more than just information it’s the foundation of business intelligence, personalized user experiences, customer service, tax compliance, and operational continuity. When a business transitions from one eCommerce platform to another whether that’s from Shopware 5 to Shopware 6, Magento to Shopware, WooCommerce to a custom solution, or from a legacy ERP—the preparation of historical order data becomes a mission-critical step.
Historical orders contain a wealth of transactional insight: who bought what, when, for how much, from which region, under which tax category, and with what discounts or promotions applied. This data is deeply intertwined with customer records, inventory tracking, tax reporting, refunds, fulfillment records, and performance analytics. Losing or misrepresenting this information during migration can cause legal issues, customer dissatisfaction, broken reporting dashboards, or even accounting discrepancies.
Simply put, order history isn’t just “old data” it’s an essential part of your business’s DNA.
Unfortunately, historical data is often messy, inconsistent, and scattered across various sources like old databases, CSV exports, or ERP interfaces. Preparing this data for migration requires careful planning, structured cleaning, mapping to the new platform’s schema, and validation not to mention data privacy compliance and potential restructuring to match the Shopware 6 order entity model.
This guide is designed to walk you through that process in a structured, real world way. Whether you’re handling the migration in-house or working with an external agency, these steps will ensure you don’t just move data you migrate usable, trustworthy, and compliant records.
By the end of this guide, you’ll understand:
We’ll also explore common mistakes to avoid, tips for handling customer account relationships, how to work with refunds or guest orders, and what tools and scripts can help automate parts of the workflow.
This documentation assumes you’re working with some technical resources whether developers, database admins, or migration partners—but we’ve also included business-side context for project managers, eCommerce leads, and data governance roles to follow along.
Let’s begin by understanding why historical orders matter—both operationally and strategically.
Free 15 min initial consultation directly with our experts.
When planning a migration or platform upgrade, many businesses consider leaving old orders behind to save time or simplify the process. However, this can lead to significant gaps in operations, customer support, and long-term business continuity. Historical orders aren’t just a ledger of past activity they are foundational for financial, legal, analytical, and customer facing processes.
Let’s explore the most compelling reasons why historical orders must be preserved and properly imported:
Governments and tax authorities in most regions require you to retain transactional records for several years (typically 5–10 depending on the jurisdiction). These records may be subject to:
Failure to provide proper order history in a timely and accurate format could result in penalties or legal complications. Simply exporting PDFs or spreadsheets is not enough; integrated, queryable data is often needed for automated audits.
Your support and sales teams rely on quick access to customer history when handling:
Without historical orders in your new system, agents will need to toggle between platforms or worse, contact IT for legacy access—creating friction for both staff and customers.
Imagine telling a loyal customer: “Sorry, we don’t have access to your past orders anymore.” That’s an avoidable hit to brand trust.
Historical orders form the backbone of modern analytics, especially for understanding:
If you’re using tools like Google Analytics, Metabase, or BI dashboards, missing historical orders will leave gaps in segmentation and personalization strategies. This impacts your ability to run loyalty programs, smart recommendations, and marketing automation effectively.
If your business offers loyalty points, discounts, or exclusive tiers based on previous orders, then importing historical purchases is essential. You need to:
Failing to bring over this data could lead to disgruntled loyal customers and undermine the perceived value of your program.
Understanding which products perform well over time requires historical sales records. This supports:
Additionally, sales data is often linked to SKU-level performance reviews or supplier contracts, meaning that losing this history could hurt future negotiations or replenishment cycles.
Historical order data often flows into downstream systems like:
If you migrate without including historical orders, these systems may break, desync, or show incomplete data, requiring time-consuming patch fixes or partial syncs.
Before beginning any technical work exporting data, writing scripts, or formatting files you must clearly define the scope of the historical orders you want to migrate. This phase is crucial for maintaining data quality, minimizing errors, and avoiding the overhead of importing irrelevant or inconsistent records.
Not all historical data is equally valuable. Migrating every single transaction from the past 10 years might sound thorough, but it can lead to bloated databases, longer import times, and downstream complexity. On the other hand, migrating too little could result in lost business context, broken analytics, or compliance gaps.
Let’s break down the essential filters you should consider when preparing your dataset:
Best practice: Import at least the last 2–3 years for active customer continuity and basic analytics. Anything older may be archived or retained in read-only format.
Considerations:
Pro Tip: Focus your migration on orders with valid payment and delivery information. You may want to archive failed/canceled orders unless they serve a specific analytics or fraud-detection purpose.
Shopware 6 requires a valid order_customer entry for every order. If your current system mixes guest and registered users, you’ll need to standardize that data structure before import.
Recommended: Migrate both types, but distinguish them in the customer group or with metadata.
Regional rules around tax, shipping, and payment methods often vary, so you may want to segment these datasets to simplify transformation scripts.
Example: If you’re only launching your Shopware 6 store in Germany initially, skip old U.S. or U.K. orders for now.
source_system, imported_at, or import_batch_id for future traceability.This structured approach makes it easier to roll back, debug, or isolate problematic records during test runs.
• Once you’ve defined the scope of your migration, the next critical step is exporting the historical order data from your current system. The quality and completeness of this export will directly influence how well you can transform and import it into your new Shopware 6 environment.
• The export process and the available tools will vary depending on your source platform. This section outlines how to extract order data properly, what fields and tables are essential, and how to avoid common pitfalls in this phase.
• Let’s explore how this step typically works across common platforms:
Example query:
SELECT o.id, o.ordernumber, o.invoice_amount, u.email, d.articleID, d.quantity FROM s_order o JOIN s_order_details d ON o.id = d.orderID JOIN s_user u ON o.userID = u.id;
If your system doesn’t offer a clean export function:
Make sure your export includes all critical entities. Missing even one column can break your import pipeline or leave partial records in Shopware.
| Type | Description |
|---|---|
| Order headers | Order ID, status, totals, currency, date, sales channel |
| Line items | Product IDs/SKUs, quantity, unit price, tax rate, discount |
| Customers | Name, email, customer group, billing/shipping address |
| Shipping | Method, tracking number, carrier, delivery dates |
| Transactions | Payment method, transaction ID, status, refunded amount |
| Invoices | Invoice number, invoice date, PDF reference if available |
Optional but useful:
With your raw data exported, the next step is cleaning and validating it before mapping it to Shopware 6’s schema. That’s what we’ll cover in the next section.
Exporting your historical order data is just the beginning—what you now have is often messy, incomplete, or inconsistently structured. Cleaning and validating this data is essential to avoid import errors, prevent data loss, and ensure long-term reporting accuracy in your new Shopware 6 environment.
If your data isn’t cleaned properly, you’ll likely face:
Let’s break down how to approach cleaning and validation systematically.
Most exports especially from older or custom systems—will contain issues like:
Solution: Use deduplication logic based on unique fields like order_id + date + email.
Solution: Cross-reference order_items with orders to ensure 1:N integrity. Any orphaned orders must be flagged.
Solution: Normalize casing, validate required fields, and set fallback values where allowed (e.g., anonymous@example.com for guests).
Solution: Create a reference map of valid IDs and use lookup logic or placeholder mappings to fill gaps.
Solution: Set default values where appropriate, or mark records for manual review.
| Tool | Use Case |
|---|---|
| Excel / LibreOffice | Visual spotting of duplicates, nulls, formatting |
| Python (Pandas) | Automating transformations, validations |
| PHP or Node.js scripts | Working with large JSON/CSV sets |
| Shopware API testing tools | Check import acceptance (Postman, cURL) |
| OpenRefine | Deep data cleanup and clustering for text |
Always keep:
This allows reproducibility, rollback, and debugging if something fails after deployment.
Once your historical order data is cleaned and validated, it must be structured to fit the target platform’s schema in this case, Shopware 6. Unlike legacy systems that often rely on monolithic tables, Shopware 6 uses a modular, entity-based architecture for orders. This modularity is great for flexibility and scalability but it also means your import files must respect strict relational rules and entity separation.
A complete order in Shopware 6 typically involves the following interconnected entities:
| Entity | Purpose |
|---|---|
| order | Main order record with totals, status, and metadata |
| order_line_item | Each product or custom line in the order |
| order_customer | Snapshot of customer at the time of order |
| order_transaction | Payment-related info (method, status, transaction ID) |
| order_delivery | Shipping details, tracking, and delivery method |
| order_address | Billing and shipping addresses linked to the order |
When using CSVs:
Example:
order_line_item.csv should include:
order_id product_id label quantity total_price abc123 prod567 Blue T-Shirt 2 39.98
order_customer.csv might include:
order_id email first_name last_name customer_number abc123 john@example.com John Doe CUST-001
If you’re using the Sync API or Admin API, structure each order payload like this (simplified example):
{
"order": {
"orderNumber": "10001",
"salesChannelId": "...",
"currencyId": "...",
"orderCustomer": { ... },
"transactions": [ ... ],
"deliveries": [ ... ],
"lineItems": [ ... ],
"addresses": [ ... ]
}
}
By properly structuring your data into discrete, relational entities, you lay the groundwork for a seamless import into Shopware 6, ensuring all relationships remain intact and future reporting or customer service workflows remain operational.
Field names and data types may differ between systems. Create a field mapping sheet like this:
| Old Field (Magento) | New Field (Shopware) | Transformation Notes |
|---|---|---|
| customer_email | order_customer.email | Keep lowercase |
| status | order.state_id | Use Shopware state UUIDs |
| shipping_address | order_address | Flatten structure if nested |
Migrating raw order data alone is often not enough to fully retain the operational value your business has built over time. Orders don’t exist in isolation they are embedded within broader business processes, marketing strategies, and customer journeys. To maximize the benefits of your historical order data, you should enrich it with contextual information that supports smarter decision making and smoother business continuity after migration.
Adding contextual data layers helps you:
Example: If John Doe has spent €5,000 over 10 orders, adding this info enables Shopware’s marketing tools to offer personalized promotions.
By incorporating these contextual layers into your historical order data migration, you ensure that Shopware 6 doesn’t just hold your data, but also the business intelligence and operational insights needed to thrive post-migration.
Migrating historical order data is not just about the orders themselves—it’s equally crucial to handle the customer data correctly. Shopware 6 enforces a strict relationship between orders and customers: every order must link to a valid order_customer entity. This presents unique challenges when dealing with both registered customer accounts and guest checkouts.
Decide whether to:
These may require separate API endpoints or data layers. Some shops import orders without these for simplicity; others treat them as critical.
Handling customer accounts and guest orders carefully guarantees that your historical orders remain searchable, linked, and useful in Shopware 6’s backend and storefront, preserving both operational workflows and customer experience.
Importing historical order data is a complex operation with many dependencies and relationships. Attempting to import your entire dataset in one go is risky and can lead to hard-to-diagnose failures, data corruption, or system instability.
To mitigate these risks, a rigorous testing and validation phase is essential. This section guides you through best practices for incremental testing and verification of imported order data in Shopware 6.
Only proceed to a full-scale import once test imports are completely error-free and data quality is validated. This ensures a smooth final migration and minimal disruption.
Historical order data includes sensitive information:
Ensure:
Recommended tools:
Example: A Python script to convert WooCommerce orders to Shopware format.
Q: What if I don’t import orders?
A: You lose customer history, reporting depth, and might have legal issues with tax documentation.
Q: Can I import orders without products?
A: No. Shopware requires valid product references (SKUs, IDs, or UUIDs).
Q: What if some fields are missing or unknown?
A: Use placeholder values or default data just don’t break referential integrity.
Preparing your historical order data is not a copy paste task. It requires:
But it’s worth it your order history is a valuable asset for business intelligence, customer care, and legal compliance.
Take the time to prepare it well, and you’ll start your new platform migration with confidence and clarity.