This is the early access documentation preview for Custom Views. This documentation might not be in sync with our official documentation.

Moving to commercetools Frontend

When moving to commercetools Frontend, there's a lot you might want to take with you from your old eCommerce project setup, like product data, code, designs, and so on. This article will go through what you can take with you, how you can do it, and which external systems are involved.

Product data

If you're not starting a brand new business and aren't yet using the headless backend system, you'll want to take your existing data with you from your previous project setup. Such data will probably include the product catalog database, with product variants, categories, attributes, and so on.

Since we don't store this data, you'll need to look to your future headless eCommerce system to get this data. Many headless eCommerce systems come with import tools that can connect directly to your deprecated system or import in standardized formats.

If your target system doesn't support an import, you'll need to implement a transfer mechanism using your source and target system's APIs.

User data

We also don't store user data, such as accounts, passwords, addresses, carts, orders, or wishlists. So, you'll need to use the same import process as product data.

Our customers often ignore migrating existing carts and wishlists because it's too much effort. Providing a voucher with a small discount to your customers who lose their cart or wishlist might mitigate their frustration or even revive old customer relations.

It's impossible to migrate your customer passwords because they're stored in an encrypted way that's impossible to recover for security reasons. Two options to manage this are:

  • Ignore it and let your customers use the recover password function when they try to log in
  • Send a bulk mail to your customers about the system change and proactively ask them for password recovery to re-activate their account

User sessions

It's not possible to migrate user sessions due to privacy restrictions. We recommend that you either ignore this issue or put a prominent banner about your re-launch on your home or landing pages.

URLs

commercetools Frontend provides flexibility regarding your URL scheme for static pages (for example, landing pages) and dynamic pages (for example, product detail pages).

With commercetools Frontend you can:

However, it might not be desirable to keep your old URL scheme. In such cases, you can manage redirects in the Studio to maintain a good search engine score. Furthermore, if you need to add many redirects to your commercetools Frontend project, you can upload a CSV file in the Studio.

Content

commercetools Frontend allows you to store simple text and Markdown annotated rich text as page content, providing you with basic content management facilities. There's no way to import this information into the Studio. So, you'll need to copy and paste the content manually, which should be feasible for smaller content pieces.

If your site consists of large content blocks or a large number of content pages, you can also create an extension to serve content from a headless Content Management System (CMS) to commercetools Frontend. Or serve the content from an arbitrary source (for example, a database or plain text files). See the extensions article for more information.

The recommended way to transfer your existing navigation structure to commercetools Frontend is to model it using the group schema field type as any combination of commerce categories and a tree field type, as in the following example.

Example of navigation schemajson
{
// Other schema properties.
"schema": [
{
// ...
"fields": [
{
"label": "Top categories",
"field": "topCategories",
"type": "group",
"itemLabelField": "name",
"min": 1,
"max": 5,
"fields": [
{
"label": "Category name",
"field": "name",
"type": "string",
"translatable": false,
"required": true
},
{
"label": "Navigation tree",
"field": "tree",
"type": "tree"
}
//...
},
// ...
]
},
]
// Other schema properties.
}

If this approach is not suitable for you, feel free to implement the navigation structure in a Frontend component specifically to your needs. This should also allow you to transfer your existing navigation structure, for example, by:

  • Hard-coding the navigation structure into JavaScript code
  • Implementing an extension to a micro service that serves the navigation structure
  • Retrieving navigation from the page folder tree

JavaScript/ReactJS components

If you developed your previous project in ReactJS, chances are that you can re-use these within your project. The general precondition is that your components aren't hardbound to an application structure and have their logic well encapsulated. Ideally, you have a set of presentational components as a UI component library. You can wrap this into Frontend components that hold the logic and deal as an adapter towards the Frontend component API.

You can copy the existing source code to your GitHub customer repository (see the coding guide article for where to put your code or source it as a dependence on your project.

CSS

If you bring UI components into your project, these will probably already have a CSS codebase. You only need to ensure that your CSS works well with our grid system.

If you include the components using Yarn, webpack will automatically include your component CSS. If you decide to copy our UI library, you can continue using this CSS by adding it to the library.

See the styling your site article for more information.

Still confused?

You can sign up for a guided demo, and our engineers will answer all your questions.