Data migration

This page describes how existing data is handled when switching to the WEBSALE shop system (or when changing versions within WEBSALE). The focus is on:

• Data that is actually migrated (for example reviews, orders, wish lists, vouchers), and
• Data that is delivered to WEBSALE from third-party systems via interfaces (for example ERP/merchandise management) (for example products, categories, customer master data).

The graphical and functional migration of templates and layouts is not considered here.

---

​

General

In principle, the same questions should be asked for all data areas:

• Is the data held in a leading system (for example ERP) or in the previous shop system?
• Are there interfaces through which the data is to be transferred to WEBSALE in the future?
• Is it possible to export the existing data (for example CSV, database dump, API)?
• Do the existing data structures match the field definitions of the WEBSALE shop system, or is conversion necessary?

​

Data areas in detail

​

Interfaces

In many projects, data exchange already takes place via automated interfaces. Therefore, looking at the interfaces is often the simplest and most important first step in data migration. If interfaces for importing and exporting data (for example to ERP/merchandise management systems, PIM, CRM, payment, or shipping service providers) are already used in the previous shop system, these external systems generally remain the leading systems after the switch to WEBSALE as well. As part of the migration, these systems must be connected to the interfaces of the WEBSALE shop. The focus here is on:

• Mapping the previous endpoints and formats to the WEBSALE interfaces
• Adjustment of formats, fields, and protocols (mapping)
• Technical tests of the data transfers for import and export

All information about the interfaces that the WEBSALE shop provides can be found in the interface and API documentation. If certain data has not yet been transferred automatically (for example regular manual CSV import), it can be checked during the migration whether additional interfaces should be set up for this. In this context, it must be determined which party will handle the implementation (for example ERP manufacturer, supporting agency, or internal IT).

​

Products & categories

There are typically two scenarios for products and categories:

​

ERP/PIM-led

Products and categories are maintained in an ERP, merchandise management, or PIM system and transferred to the shop via an interface. When switching to WEBSALE, the focus is therefore on connecting or adapting the interfaces (see section “Interfaces”). A separate one-time data migration is usually not necessary in this case, since the data continues to be delivered on an ongoing basis from the leading system.

​

Shop-led

Products and categories were previously maintained directly in the previous shop system and not transferred from an ERP/PIM via interfaces. In this case, the data must be exported from the previous shop system, converted into the WEBSALE format if necessary, and then imported into the WEBSALE shop. In particular, field mapping must be taken into account, i.e. assigning the fields of the previous shop system to the fields in the WEBSALE data model. The assignment is made in the configuration node content.usedFields (see section “Shop configuration”).

​

Customer data

Customer data includes, for example, master data (name, address, and contact details), shipping and billing addresses, credit-related notes, permitted or blocked payment methods, customer groups, customer-specific assortments, customer-specific prices and discount scales, and other conditions. There are typically two scenarios for customer data:

​

ERP/CRM-led

Customer data and conditions are maintained in an ERP, merchandise management, or CRM system and transferred to the shop via an interface. When switching to WEBSALE, the focus is therefore on connecting or adapting the interfaces (see section “Interfaces”). Customer-dependent settings such as permitted payment methods, price lists, discounts, assortment restrictions, and credit notes remain in the leading system and are transmitted from there to the WEBSALE shop. A separate one-time data migration is usually only required to a limited extent in this scenario, since the data continues to be delivered on an ongoing basis from the leading system.

​

Shop-led

Customer data and customer-specific conditions were previously maintained directly in the previous shop system and not transferred from an ERP/CRM system via interfaces. In this case, the relevant data (master data, status information, payment method approvals/blocks, customer-specific prices, assortment assignments, etc.) must be exported from the previous shop system, converted into the WEBSALE format if necessary, and then imported into the WEBSALE shop. It must be ensured that the assignment to customer groups, price lists, payment methods, and possibly customer-specific assortments is correctly mapped in the WEBSALE shop.

​

Customer logins & passwords

Customer logins essentially consist of the combination of access data (for example email address or customer number) and password. For data protection and security reasons, passwords are never stored in plain text in the WEBSALE shop, but exclusively in the form of cryptographic hash values. There are essentially two scenarios for migrating customer logins:

​

Password hashes can be taken over

In the previous shop system, passwords are also not stored in plain text but as hashes, and the hash methods used as well as the required technical information (for example salt, parameters) are known or exportable.
In this case, it is possible to take over the existing password hashes in compliance with data protection rules and transfer them to the WEBSALE system. This way, customers can continue to use their familiar access data after the system change and sign in to the WEBSALE shop without having to choose a new password.

​

Password migration is not possible

If technical migration of the previous password hashes is not possible (for example due to proprietary or unknown methods or lack of access), the customer accounts are migrated to the WEBSALE shop, but without the previous password. In this case, the WEBSALE shop guides users so that customers can easily set a new password, for example via:

• a targeted prompt to set a new password on the first login attempt, and
• the usual “Forgot password” function with email link.

In no scenario are passwords transmitted in plain text between systems or exported to files.

​

Order history in the customer account

This section refers to the display of orders in the customer account (order history, order status, detailed order view) from the customer’s perspective. It does not describe the technical transfer of new orders from the shop to an ERP/merchandise management system for further processing, but rather the connection or migration of the data used in the shop for the order overview. There are typically two scenarios for the order history in the customer account:

​

ERP/merchandise management-led

Orders are managed centrally in an ERP or merchandise management system. In this case, the shop uses a connection that provides order data and order status from the ERP for display in the customer account. This way, the WEBSALE shop can display not only orders that were placed via the online shop, but also orders that were captured via other channels (for example telephone, catalog/print, branch). When switching to WEBSALE, the focus in this scenario is on connecting or adapting this order management/display interface (see section “Interfaces”). The existing connection can generally be reused or switched to the WEBSALE interfaces.

​

Shop-led

If there is no connection for displaying orders from an ERP/merchandise management system, orders in the customer account are usually displayed directly from the database of the previous shop system. In this case, the orders must be exported from the previous shop system, converted into the WEBSALE format if necessary, and then imported into the WEBSALE shop. For a clean migration, the following information is particularly relevant:

• unique customer identifier (UserIndex),
• order number and order date,
• order status,
• payment method and shipping method,
• order items (article, quantity, prices).

Optionally, additional information such as shipping information (tracking codes), internal notes, or comment texts can be taken over, provided they can be mapped in the WEBSALE data model. Depending on the project, it can also be decided whether the complete history is taken over or only orders from a certain cut-off date.

​

Product & customer reviews

Product and customer reviews are generally not held in ERP, merchandise management, or PIM systems, but via the shop system’s own review functions or via specialized third-party systems (for example eKomi, Trusted Shops, Trustpilot). The reviews are usually assigned to the respective product via the product index. There are typically two scenarios for the migration and further use of reviews:

​

Reviews via external service providers

If reviews are managed by an external service provider, the actual review data generally remains with the service provider. When switching to WEBSALE, the following points are particularly relevant:

• Integration of the required widgets, scripts, or plugins of the service provider into the templates of the WEBSALE storefront,
• Ensuring that the assignment of reviews to products continues to work (for example via product ID, SKU, or URL),
• Taking over or reimplementing the processes for review requests, for example automatic sending of review requests after an order (API call, export file, webhook, or similar).

The actual data migration of reviews in this scenario does not generally take place in the WEBSALE shop but via the existing data base at the external service provider. After successful integration, the reviews are displayed automatically in the new WEBSALE shop.

​

Reviews in the previous shop system (shop’s own review system)

If product and possibly customer reviews were previously stored directly in the previous shop system, they can be transferred to the WEBSALE system, provided that a suitable export is possible. In this case:

• Export the reviews from the previous shop system (for example product identifier, review value, review text, date, approval status, optionally customer or order reference),
• Convert to the WEBSALE format and assign to the corresponding products in the WEBSALE shop,
• Import the reviews into the WEBSALE review system.

WEBSALE is able to assign reviews to products, orders, and customers. If customer and order references are also transferred as part of the migration, customers can continue to see an overview of their own reviews or reviewed orders in the customer account.

​

Wish lists & favorites lists

Wish lists or favorites lists are an important part of the shopping experience for many customers. They make it possible to monitor and compare products over a longer period of time and to order them later. Especially for recurring orders or higher-priced items, wish lists help to keep customer relationships stable and to prepare purchase decisions. Wish lists and favorites lists are generally not held in ERP, CRM, or merchandise management systems, but stored directly in the respective shop system. For the migration, this means in practice:

• The entries of the wish lists or favorites lists must be exported from the previous shop system.
• The data (especially assignment to customer accounts and products) must be converted to the WEBSALE format if necessary. The following are particularly important:
  • a unique customer identifier,
  • a unique product reference (for example product index).
• The converted data is then imported into the WEBSALE shop.

This ensures that after the changeover, customers will find their existing wish lists or favorites lists in the new WEBSALE shop and can continue to use them seamlessly.

​

Newsletter subscriptions

Newsletter subscriptions are managed either in an external newsletter system or directly in the previous shop system.

​

External newsletter systems

If newsletter subscriptions are already managed via an external system (for example Inxmail, CleverReach, or comparable providers), the distribution lists and subscriber data generally remain in this system. When switching to WEBSALE, the following points are relevant:

• Integration or adaptation of the existing integration of the newsletter provider in the WEBSALE shop (forms, sign-up and sign-out processes, possibly tracking parameters),
• Ensuring that sign-ups and sign-outs continue to be transmitted correctly to the external provider (for example via API, form POST, webhook).

An actual data migration of subscriber data to the WEBSALE shop is usually not required in this scenario, since the management of distribution lists remains in the external system.

​

Shop’s own newsletter system

If newsletter subscriptions were previously managed directly in the previous shop system, this data can be transferred to the WEBSALE newsletter system, provided that a suitable export is possible. Typical procedure:

• Export of subscriber data from the previous shop system (for example email address, optionally name, sign-up date, opt-in status, language, interests/lists),
• Conversion to the WEBSALE format,
• Import into the WEBSALE newsletter system.

Depending on the legal evaluation and the procedure used, it is possible to retain the existing consent (opt-in). Optionally, additional confirmation (for example renewed double opt-in) can be triggered during the migration for additional legal certainty, in which all imported addresses are asked once again for confirmation.

​

Vouchers

Vouchers are an important marketing and service instrument. After a system change, it should be ensured that vouchers still in circulation can continue to be redeemed in the new system. There are typically two scenarios for managing vouchers:

​

ERP/merchandise management-led

If vouchers are created and managed in an ERP or merchandise management system (for example creation, validity period, remaining values, redemption status), this system is the leading system. When switching to WEBSALE, the existing voucher logic must continue to be provided via the merchandise management system. This requires connecting or adapting the corresponding interfaces (see section “Interfaces”). This ensures that:

• existing voucher codes continue to be recognized,
• validity and remaining values are checked correctly, and
• redemptions are recorded in the ERP/merchandise management system.

​

Shop-led

If vouchers are created and managed directly in the previous shop system, all relevant voucher information is in the shop database. In this case, the existing vouchers must, as part of the migration:

• be exported from the previous shop system,
• be converted to the WEBSALE format if necessary, and
• then be imported into the WEBSALE shop.

The following data is particularly relevant for the migration:

• voucher code,
• type and value (for example amount, percentage),
• remaining value (for value vouchers),
• validity period,
• redemption status,
• possibly customer assignment or restrictions (for example certain customer groups, assortments).

Depending on the project, it can be specified whether all historical vouchers are taken over or only currently valid or not yet redeemed vouchers.

​

Bonus points & credit

Bonus point and reward systems, customer card credits, or comparable models allow customers to collect points or monetary values for orders and later redeem them as discount or means of payment. In a system change, it should be ensured that already accumulated point balances and credits are not lost and can continue to be used after the changeover. There are typically two scenarios for bonus points and credit:

​

ERP/merchandise management-led

If bonus points, rewards, and credit are held in an ERP or merchandise management system, this system is responsible for calculating and managing the values (collecting, redeeming, remaining values, validity). In this case, the shop accesses this information via interfaces, for example to:

• display current point balances or credit in the customer account,
• trigger the collection of new points for orders, or
• report redeemed points and credit back to the ERP/merchandise management system.

When switching to WEBSALE, these systems must be connected to the interfaces of the WEBSALE shop (see section “Interfaces”). Configurations such as conversion factors (for example euro to points), possible redemption combinations, or conditions (minimum order value, certain customer groups, assortments) can – if represented in the WEBSALE shop – be configured via the corresponding shop settings so that customers can continue to collect and redeem points and credit as before.

​

Shop-led

If bonus points, rewards, and credit are held exclusively in the previous shop system, the relevant balances and histories are in the shop database. In this case, the data must:

• be exported from the previous shop system,
• be converted to the WEBSALE format if necessary, and
• then be imported into the WEBSALE shop.

Essential information includes in particular:

• unique customer identifier (for example customer ID, email),
• current point balance or credit value,
• possibly validity periods or expiration dates,
• optionally history information (for example when points were collected or redeemed).

After the import, the appropriate settings for the bonus or reward system must be configured in the WEBSALE shop (for example collection rules, redemption conditions, conversion of points to currency) so that customers can continue to use and build up their existing point balances and credits in the new system as usual.

​

Product subscriptions

Product subscriptions (for example regular feed deliveries for pets, deliveries of supplements or other consumables) should also continue to run reliably after a system change. The goal of the migration is for existing subscriptions to be retained and for the associated orders to continue to be generated and delivered automatically. There are typically two scenarios for product subscriptions:

​

ERP/merchandise management-led

If product subscriptions are managed in an ERP or merchandise management system (including delivery intervals, next delivery date, permitted payment methods, terms, pause functions, etc.), this system is the leading system. In this case, the shop is mainly used for displaying and capturing changes by the customer. When switching to WEBSALE, this subscription data must continue to be transferred to the WEBSALE shop via the corresponding interfaces (see section “Interfaces”). This ensures that:

• existing subscriptions are displayed in the customer account,
• automatic follow-up orders are triggered as usual, and
• changes to the subscription (for example interval adjustment, pause, cancellation) are processed correctly.

​

Shop-led

If product subscriptions are managed directly in the previous shop system, the relevant information (for example customer, product, delivery interval, next delivery date, payment method, status, possibly pause information) is in the shop database. In this case, this data must:

• be exported from the previous shop system,
• be converted to the WEBSALE format if necessary, and
• then be imported into the WEBSALE shop.

Additionally, the settings for the following must be configured accordingly in the WEBSALE shop:

• available delivery intervals,
• permitted payment methods for subscriptions,
• functions such as pausing, reactivating, or ending subscriptions

so that the subscription logic remains functional in the new system. Important: For error-free continuation of product subscriptions, it must be ensured that the associated products and customer data have also been correctly migrated to the WEBSALE shop and that the assignment (for example via product IDs and customer identifiers) continues to be uniquely possible.

​

URLs, URL structures & redirects

URLs, internal linking, and redirects are among the most sensitive areas when changing a shop system. Errors in this area can directly affect search engine visibility, campaign links, and saved customer bookmarks. WEBSALE therefore provides extensive functions to largely retain existing URL structures and to control redirects in a controlled manner.

​

URL structure / URL scheme

To avoid unnecessary redirects, the WEBSALE shop offers a flexible URL configuration. This allows URL structures (URL schemes) for SEO-relevant pages to be defined so that they correspond to the previous structures, for example for:

• product pages
• category pages
• content pages (for example “About us”, landing pages)

The goal is that the URL of a product or a category ideally does not change due to the system change. The URL for a product can therefore be the same in the new WEBSALE shop as in the previous shop system.

​

Short addresses & campaign URLs

Many shops use special short addresses or campaign URLs to address landing pages for marketing activities, newsletters, social media posts, or print campaigns. These short addresses can also be represented in the WEBSALE shop:

• Existing short or campaign URLs from the previous shop system can, if they are known or exportable, be taken over and set up in the WEBSALE shop.
• Alternatively, these URLs can be redirected to the corresponding target pages via the redirect service of the WEBSALE shop.

This way, campaign links remain functional even after the system change.

​

Existing redirects from the previous shop system

Many shop systems have their own redirect logics, for example for:

• delisted or replaced products (“continued products”),
• discontinued categories,
• structural URL changes.

WEBSALE itself has its own mature redirect concept for products and categories. Products or categories that are no longer available can be automatically redirected to suitable targets, for example to:

• successor or replacement products,
• superordinate categories,
• defined target pages.

If redirects for such cases are already stored in the previous shop system and this information can be exported (for example in the form of “old URL → new URL” lists), this data can be taken over as part of the migration and mapped in the WEBSALE shop. This enables already-configured redirects to continue working after the system change. A significant drop in search engines therefore does not have to be feared with clean planning and implementation.

​

Redirect concept in the WEBSALE shop (redirect service)

Regardless of any migrated old redirects, the system’s own redirect concept takes effect when the WEBSALE shop goes live. Essential components are:

• Automatic redirects for products and categories marked as replaced, moved, or removed in the system.
• A redirect service that can be used to configure targeted, individual redirects, for example:
  • 301 redirects from old URLs to new target pages (products, categories, content pages),
  • targeted redirects to a defined landing page,
  • redirects to a 404 page when content is deliberately no longer offered.

For URLs that cannot be clearly assigned, a generic redirect behavior can be configured (for example 301 to an overview page or 404 with a sensibly designed error page). This allows unclear old links to be intercepted and controlled in a targeted manner.

​

SEO support during the system change

Due to the importance of URLs, redirects, and SEO settings, it is strongly recommended to have the system change accompanied by an SEO specialist. This person can, for example:

• help plan the URL scheme in the WEBSALE shop,
• create a list of particularly important URLs from the previous shop system and check their mapping or redirect,
• configure redirects and URL adjustments via the Admin Interface,
• make further SEO settings in the WEBSALE shop, for example:
  • configuration of metadata (title, description),
  • maintenance of SEO-relevant schemas and structures,
  • setup and updating of sitemaps.

This ensures that the system change succeeds not only functionally but is also prepared and implemented cleanly from an SEO perspective.

​

Tracking information & analytics

Tracking information and analytics include, for example, page views, clicks, events, conversion tracking, funnel evaluations, and comparable measurements of user behavior. In practice, this data is often processed via external tracking and analytics services, for example Google Analytics / GA4, Matomo, econda, or comparable systems.

​

External tracking and analytics systems

For these systems, the following are generally integrated in the shop:

• tracking snippets,
• tag manager containers (for example Google Tag Manager),
• or individual scripts and events

which transfer certain actions, states, and events (for example page views, basket events, order completion) to the respective service. Regardless of whether the WEBSALE shop is built via the template engine or via the Storefront API:
the WEBSALE shop can provide the information required for the tracking snippets (for example product data, order values, customer states, dataLayer information) so that the existing tracking pipelines can continue to be filled. When switching to WEBSALE, the focus is therefore in particular on:

• taking over or reintegrating the existing tracking IDs, container IDs, and snippets,
• mapping the previously used events and parameters in the new shop (for example via dataLayer or direct transfer),
• functional testing of the integration (test orders, test events).

The historical tracking data remains in the respective external system (for example Google Analytics, Matomo) and is not migrated to the WEBSALE shop. After go-live, new data is captured in the same or new properties/accounts and can be evaluated there.

​

Shop-internal statistics

Many shop systems additionally provide internal statistics and evaluations, for example:

• evaluations of usage behavior,
• key figures on products and categories,
• order and revenue statistics.

These statistics generated internally in the previous shop system cannot be transferred or imported into the WEBSALE statistics system. If you continue to need this data, the relevant reports and key figures should be exported or saved in the previous shop system before the system change (for example as CSV or PDF) so that they can later be compared with the WEBSALE statistics if necessary. The statistics in the WEBSALE shop start with productive operation of the new system and build up a new data base from that point on.

​

Inquiries

Forms (for example for contact inquiries, withdrawals, callback service, complaints) serve to capture customer concerns in a structured way and forward them to the right places. In WEBSALE, the required forms can be created directly in the system. Form creation is flexible and enables, among other things:

• freely definable fields,
• dependencies between entries (for example additional fields depending on selection),
• plausibility checks and validations,
• address checks analogous to billing and shipping addresses.

Filled-out forms can in WEBSALE:

• be sent by email to defined addresses at the merchant,
• be forwarded to external systems (for example CRM systems),
• be viewed and processed directly in the Admin Interface.

When processing in the Admin Interface, inquiries can be marked with processing status and documented without the need for an external system. Inquiries that have already been received in the previous shop system and are still being processed at the time of the changeover are not migrated to WEBSALE. Usually, these open inquiries continue to be answered in the previous shop system and closed there (including status changes, internal notes, etc.). New inquiries after go-live are then captured via the forms set up in WEBSALE and processed via the new processes.

​

Availability alerts or availability notifications

WEBSALE offers the option of storing availability alerts or availability notifications for products that are currently not available. Customers can register when a product is sold out and are automatically informed as soon as the item is available again. The information required for this (for example product reference, contact details, time of registration) is stored in the WEBSALE shop database and evaluated when stock changes. If the previous shop system provides a comparable function and the availability alerts stored there can be exported, this data can:

• be exported from the previous shop system,
• be converted to the WEBSALE format if necessary, and
• then be imported into the WEBSALE shop.

It is essential that:

• a unique assignment to the respective product (for example product index, article number, StoreID, etc.) is possible, and
• only open, not yet triggered notifications are taken over.

In the WEBSALE shop, it can be configured:

• from when a product is considered “available” again (for example from a certain stock quantity),
• under which conditions an availability notification is triggered, and
• in what form the notification should take place.

This ensures that existing availability alerts are not lost during the system change and that customers are automatically informed even after the move to the WEBSALE shop system as soon as their selected products are available again.

​

Content & content pages

Content or content pages include, for example:

• legal pages such as imprint, GTC, privacy policy,
• information pages such as “About us”, FAQ, service pages,
• landing pages and campaign pages,
• content elements and widgets such as sliders on the home page, teaser areas, banners, and similar.

There are also typically two scenarios for content:

​

External CMS-led

If pages and content elements are already maintained via an external CMS system and delivered via a connection in the previous shop system, the content generally remains in the CMS. When switching to WEBSALE, the following is particularly relevant:

• the connection of the existing CMS to the WEBSALE shop (for example via APIs or feed formats),
• adapting the templates in WEBSALE so that the delivered content is output at the desired places,
• possibly taking over existing URL structures for important content pages (see also SEO URLs).

An actual migration of the content to the shop database is usually not necessary in this scenario, since the CMS continues to be the leading system.

​

Shop-led

If content is maintained directly in the previous shop system (for example CMS functions of the shop, static pages, content widgets), the content is in the shop database or in shop-specific structures. In this case, it should be checked:

• whether an export of the content is possible, ideally in a structured format (for example JSON),
• whether metadata such as page type, position in the shop, language variants, SEO information (title, description) is output as well.

If export data is available in a suitable format, this content can be made available to the WEBSALE shop, converted if necessary, and then mapped in the WEBSALE content structures. The output then takes place via the corresponding templates in the desired layout or design. Where no meaningful export is possible or content is to be heavily redesigned, the project can determine which pages and content are manually recreated in the new WEBSALE shop and taken over in terms of content from the previous system.