Bring an existing frontend

What happens to a frontend built for another platform when a business moves to revenexx Revenue Cloud. What carries over, what is rebuilt, and how a migration is scoped. There is no automated migration tool.

Most projects that arrive at the platform are not greenfield. There is a shop already: a Shopware or Magento storefront, a custom Laravel or Nuxt frontend against an ERP. This page is for the partner or in-house team that has to decide what happens to it.

There is no migration tool, agent or converter. No command reads an existing storefront and produces a revenexx Theme, and no service does it for you automatically. Plan the frontend move as engineering work, because that is what it is.

Which engineering work depends on what the existing frontend is written in. Frontend stacks states the constraint in full; the short version is that a storefront Theme is Nuxt 4, and the platform runs no PHP.

What carries over, and what is rebuilt

A shop is more than its frontend. Take the layers one at a time:

Layer of the existing shop	What happens to it
Data: products, categories, prices, customers, organizations, open orders	Moves. Bulk data goes in through Import and export at `/v1/io`, through an Integration Studio workflow, or through direct API writes. Supplier catalogs in BMEcat have a ready-made template.
Business rules: pricing logic, validation, approval flows, stock rules	Rebuilt as Apps. Rules that lived in the old frontend's controllers or plugins move behind an API capability, so the new storefront, Cockpit and every integration get the same answer.
Connections: ERP, PIM, CRM	Rebuilt as Integration Studio workflows, or kept where they are and pointed at the public API.
Frontend code: templates, components, checkout UI	Rebuilt as a Nuxt 4 Theme, or kept off the platform as an API client. Only code that is already Vue or Nuxt has a chance of porting; see below.
Design and content: brand, layout decisions, copy, information architecture	Carries over as input. Design tokens take the brand; Blökkli blocks take the layouts; editors recreate pages in the visual editor, because a page is data rather than code.
Buyer accounts	Created as storefront accounts under Customers. Plan for buyers to set a new password on the new storefront rather than assuming credentials transfer.

The pattern: data and content move, logic and code are rebuilt on the platform's model. That is not a shortcoming of the migration; it is the point of it. Business logic that was scattered across a storefront's plugins becomes an App that any channel can call.

If the existing frontend is Vue or Nuxt

This is the best case, and still a port rather than a lift.

Nuxt 3 or 4 with Vue 3: components and composables carry over largely as they are. The work is structural: extend @revenexx/cover, move every call to a backend into a server route under /api/* that calls the gateway, register the page-level components as Blökkli blocks, and write the theme.json manifest. See Theme anatomy and The BFF pattern.
Nuxt 2 or Vue 2: the templates inform the new ones, but the code is rewritten on the Vue 3 composition API. Budget it as a rebuild with a very good specification.
Vue as a single-page app (Vite, Vue CLI): the components port, the architecture does not. A storefront Theme is server-rendered, so data access moves from the browser into Nitro server routes.

If the existing frontend is PHP

Shopware, Magento, Laravel and Symfony frontends cannot run on the platform. There is no PHP runtime, and no plan to add one is published. Two real options remain:

Rebuild it as a Nuxt Theme. This is the path that gives you everything the platform offers a storefront: pages editors compose, the theme marketplace, activation per tenant and domain, preview URLs, rollbacks, and the multi-tenant plumbing handled for you. It requires Nuxt skills on the team. The existing frontend is your specification: its checkout steps, its account pages, its category logic. Start from Experience Studio: getting started.

Keep it running and make it an API client. The existing frontend stays on your infrastructure and replaces its data layer with calls to api.revenexx.com, using the PHP SDK or plain HTTP with the X-Revenexx-Tenant and X-Revenexx-Api-Key headers on every request. Hosting, sessions, tenancy and deploys stay yours; page composition and the marketplace are not available. This is the sensible interim step when a rewrite cannot happen now, and the wrong end state for a storefront you intend to keep investing in.

Nothing stops you doing both in sequence: connect the old frontend to the platform first so the data and the Apps go live, then replace the frontend with a Theme domain by domain.

How a migration is scoped

Every migration onto the platform so far has been a scoped project with revenexx, not a self-serve flow. It starts with an assessment of the existing system: its code, the integrations it depends on, the business rules hidden in its customisations, and the functional gaps between what it does and what the platform provides. The output is a migration backlog and a recommended sequence, which is what the partner then delivers.

Two consequences for planning:

There is no tooling to shorten this. The assessment is people reading code and talking to the business, and the estimate comes from that.
The frontend is usually the smaller part of the estimate. Business rules and integrations decide the size of a migration; the Theme is well understood work.

To start one, open a request at support.revenexx.com describing the source system, its integrations and your timeline, or raise it with your revenexx contact if you already have one.

What to do first

Inventory the existing shop by layer, using the table above: where the data lives, which business rules are in frontend code, which systems are connected, and what the content editors maintain.
Decide the frontend path: rebuild as a Nuxt Theme, keep it as an API client, or the interim-then-replace sequence.
Stand up the tenant and move the data. Import the catalog and customers first; everything else is verified against real data.
Build the Apps that hold the business rules, and confirm each capability answers at /v1 before any frontend depends on it.
Build or connect the frontend, then cut over one domain at a time.

Where to go next

Frontend stacks: the supported stacks, the unsupported ones, and the skills a team needs.
Apps and Sites: where business logic goes and how a Theme reaches it.
Import and export: moving catalog and customer data in volume.
Build a storefront: the tutorial path for the new Theme.

Was this page helpful?