Headless commerce in a large online shop: architecture and implementation

A headless commerce architecture for a large online shop separates the front-end from the back-end, with both parts connected via an API. This allows a single system to provide product data to a website, a mobile app or a B2B platform, whilst enabling further channels to be developed without having to rebuild the entire shop.

This approach offers flexibility, but requires careful consideration when choosing the platform, integrations and the expertise of the team that will develop the interconnected systems. A headless approach is not automatically suitable for every business: with a smaller product range and simpler requirements, it may be more sensible to develop the existing online shop.

You’ll learn how to assess whether this architecture is suited to the scale and plans of your shop, what criteria to consider when choosing a platform, and how to plan the implementation. You’ll also see how to integrate the front-end with the back-end and break the migration down into stages, so you can develop your shop without having to replace the entire back-end in one go.

Key findings

• Assess whether the scale of the catalogue, the number of channels and the expansion plans justify a change in architecture.
• When choosing a platform, take into account integrations, the team’s expertise and the environments you wish to develop.
• Break the implementation down into stages and decide which parts of the shop will be migrated to the new system first.
• Plan your tests, product data and analytics to monitor the shop’s performance during the migration.

Table of Contents

• Can the migration to a headless architecture be carried out in stages?
• What is headless commerce?
• What does the process of implementing a headless shop look like once a platform has been chosen?
• Criteria for selecting a headless commerce solution for a growing online shop
• Internet Stars: Online shops

Can the migration to a headless architecture be carried out in stages?

Yes. The migration of a large online shop can be broken down into stages, separating the front-end from the back-end and linking them via an API. Start by selecting a channel or feature to migrate, such as the category pages, and then gradually expand the scope without replacing the entire back-end at once.

Each layer has a separate function. The frontend displays the product range and handles user interactions, the backend implements the shop’s logic, and the database stores information about products, customers and orders. The API relays requests between the frontend and the backend. This makes it possible to change the website’s design without having to rebuild the engine that handles orders.

In the composable approach, the backend can be divided into microservices handling specific functions. Each microservice has its own database. This division allows, for example, the product search function to be developed independently of the payment processing, but it increases the number of integrations that require maintenance.

How do you plan, step by step, the migration of a large online shop to a headless architecture? First, map out the dependencies between the systems, select a pilot phase, integrate the new front-end via an API, and test the data flow. Next, migrate further features, whilst ensuring the accuracy of the product catalogue, orders and analytics.

1. Identify the interdependencies. Determine which data and processes link the shop to the ERP, PIM, payment systems and delivery management.
2. Select the scope of the pilot. Migrate a single channel or section of the website, whilst retaining the existing backend where it continues to handle sales.
3. Integrate the layers via the API. Check that the frontend retrieves the latest products and correctly passes the shopping basket and order.
4. Expand the roll-out. Once testing is complete, roll out the next set of features and channels, rather than switching everything over at once.

An example of another channel could be a mobile app that uses the same product data as the website. A single source of information facilitates the development of an omnichannel model, but requires seamless integration. A PIM can synchronise descriptions, specifications and stock levels with an ERP system, as well as B2B and B2C platforms.

During the front-end migration, ensure that search engine visibility and sales tracking are maintained. Content should be served server-side, and the sitemap and e-commerce event tracking should be correctly configured. If the shop operates as a PWA, it requires HTTPS and an up-to-date application supported by a Service Worker.

A phased roll-out offers flexibility, but does not eliminate the need for integration work. Every new front-end, system and data flow must be tested together. In the case of a shop with a small product catalogue, developing the existing monolith may be a more sensible approach than separating the layers.

What is headless commerce?

Headless commerce separates the shop’s interface from the sales engine. An API connects these layers to the systems that support the business’s day-to-day operations.

System integration and content management

A CMS manages content, a PIM manages product data, and the search engine helps customers find what they’re looking for. The shop’s backend provides them with data via an API, rather than tying them to a single interface. This allows the team to update content and the catalogue using the appropriate tools.

In a Polish online shop, ensure the GDPR is taken into account in the flow of customer data. Design integrations with ERP, CRM, payment systems and logistics around specific processes: an order is sent to the ERP system, its status is fed back to the shop, and the delivery details are passed on by the logistics system. The API links these stages together.

Flexibility and scalability of integration

Flexibility means being able to change the interface or add a system without having to rebuild the entire shop. You can develop the website, mobile app and B2B platform separately, whilst using a shared engine and data. This makes it easier to align the development of new features with your business plans.

Such flexibility requires technical expertise. The team must manage APIs, data quality and dependencies between platforms. For each integration, determine which system stores the information and which makes it available. The more tools that are connected, the more elements need to be tested.

Impact on productivity and sales

A headless architecture offers greater control over the front-end, but the system architecture alone does not guarantee a faster online shop or higher conversion rates. Performance is influenced by factors such as the method of data retrieval, the number of integrations and the functioning of the search engine. The interface can be designed with a specific channel and purchasing process in mind.

Ensure that content is served on the server side and that the sitemap is configured correctly. Analytics requires accurate tracking of e-commerce events, such as adding a product to the basket and making a purchase. A single engine can support a website, an app, kiosks and points of sale, facilitating multi-channel sales.

What does the process of implementing a headless shop look like once a platform has been chosen?

Once you have chosen a platform, establish who will make the decisions, what objectives the project is intended to achieve, and how the team will evaluate its results. The headless commerce architecture for a large online shop should be based on specific sales requirements, rather than simply a desire to change technology. Set out the requirements in a single document accessible to business stakeholders, designers and developers.

Before you start work, define the scope. Select the features needed to get started, and include the rest in a long-term development plan. This will enable the team to set priorities based on value for customers and the impact on day-to-day shop operations. Also, appoint someone to be responsible for business decisions. Without this person, questions about the scope could hold up the work.

1. Agree on the objective. Identify the sales or organisational problem that the project is intended to solve.
2. Assign responsibility. Designate the people authorised to approve the scope, content and project decisions.
3. Set out the acceptance criteria. Describe how the team will determine that the requested features meet the requirements.
4. Plan the decision to go live. Specify who approves the go-live and how the team will proceed if a problem arises that requires the change to be rolled back.

One of the criteria might be whether the customer is able to find the right product and complete their purchase without encountering unclear messages. Keep the assessment of the shopping experience separate from the technical evaluation. Both areas should have a designated person in charge and clear acceptance criteria in place before the project reaches the launch stage.

You should also draw up a plan for transferring knowledge to the people who will be responsible for developing the shop in the future. Document the decisions made and the reasons behind them, so that new team members can understand the context. In a headless commerce architecture for a large online shop, this continuity makes it easier to plan future changes without having to revisit the same issues.

A project prepared in this way combines business decisions with the team’s accountability. It also allows subsequent proposals to be assessed according to shared criteria, rather than adding features without a clearly defined purpose.

It is worth assessing whether the extra work carried out by designers, developers and programmers will subsequently be put to effective use. Migrating to headless commerce can be a lengthy and labour-intensive process, particularly when it involves transferring and organising product databases, customer data and order history.

Criteria for selecting a headless commerce solution for a growing online shop

A headless approach is worth considering when the development of an online shop requires support for multiple channels, markets or personalised experiences. With a catalogue comprising tens or hundreds of thousands of products, independent layers can facilitate the development of user interfaces and the servicing of different customer groups. However, the size of the catalogue alone does not determine whether to implement this approach. Sales processes and the team’s readiness to maintain integrations are also important factors.

Check whether your current platform is limiting your planned changes. If every modification to the front-end blocks the development of the back-end, separating the layers could give your team greater freedom. If the shop has a small product catalogue, operates on a single channel and does not require new features, developing the existing monolith may be the better choice. A headless architecture means more interconnected systems that need to be maintained.

You should also consider who will be responsible for developing the solution once it goes live. The choice of front-end technology depends on the team’s expertise and the planned environments, such as a website, a mobile app or a PWA. If the company lacks experience in working with APIs and integrations, the technical support required should be an integral part of the decision, rather than an afterthought.

• Markets and channels: check whether a single system is intended to handle sales in different countries and across various points of contact.
• Catalogue and personalisation: assess the complexity of the data and the need to tailor the interface to the audience.
• Team and technology: tailor the front-end to your skills and the channels you plan to develop.
• Customer data: take the GDPR into account when designing the flow and storage of personal data.

Base your decision on business plans, not on the popularity of the architecture alone. First, set out the target channels, integrations and limitations of the current shop, and then compare them with the scope of the changes. Plan the development of the online shop around customer needs and the team’s capabilities.

When comparing options, consider the requirements relating to markets, the product catalogue and personalisation, rather than assessing each element separately. Headless e-commerce is worth considering for a shop operating across multiple markets, with a large product catalogue and high personalisation requirements. This architecture may also be worth considering for a catalogue comprising tens or hundreds of thousands of products. These criteria help to assess whether the development plan meets the shop’s needs.

Before selecting a front-end for a headless back-end, ensure that the planned environments align with the team’s expertise. Consider whether the solution is intended to run on the web, in a mobile app or as a PWA, and whether the team is capable of developing the chosen technology. At the same time, plan for the protection of personal data in accordance with the GDPR. It is worth taking this requirement into account right from the design stage, so that the architectural decision covers both the target channels and how customer data is handled.

Internet Stars: Online shops

Internet Stars creates online shops for businesses looking to grow their sales and requiring an architecture tailored to their processes. If you’re considering a headless solution, the team can help translate your requirements into the shop’s design, its integrations and the subsequent stages of implementation.

It is worth initiating a discussion when the current platform is limiting the development of new channels, and changes to the interface require modifications to many areas of the system. Depending on your needs, you may also wish to consider an e-commerce conversion, a dedicated app or automations to support sales processes. First, define what needs to change for customers and the team. It will then be easier to determine the scope of work and the sequence of actions.

Please contact Internet Stars to discuss your shop’s growth plans.

Turn your architectural plan into the next stage of development

Don’t start by overhauling everything. Choose a change that will best support the shop’s future growth, such as a new sales channel or more efficient order processing. Next, determine how you’ll know the implementation is working: whether customers find products more easily, whether the team updates the product range more quickly, and whether the integrations are passing data in line with the process. In this way, you’ll translate the headless commerce architecture for a large online shop into concrete business decisions.

Internet Stars develops online shops, bespoke applications and automation solutions. If you’re planning changes to your digital sales strategy, identify which processes need to change for your customers and your team. This starting point will help you define the scope of work and choose the first step.

Get in touch with Internet Stars to discuss the development of your shop and possible implementation strategies. Start with your goal, then build the solution step by step.

Frequently Asked Questions

Which headless platform should you choose in 2026?

Choose a platform that suits your current systems, planned sales channels and your team’s skills. Compare how the catalogue, shopping basket and orders are managed, as well as integration with ERP and PIM systems. Also check how the solution supports the development of your own front-end. Sylius may be one example to consider, but base your decision on your shop’s requirements, not on the name alone.

Does a headless approach make it easier to personalise customer experiences?

Yes, it allows you to design separate interfaces and shopping journeys for different audience groups. For example, you can create a different home page for retail customers and B2B partners, using the data available in the shop’s systems. Plan personalisation alongside your customer data usage policies. Also check whether content changes can be made without having to rebuild the entire interface each time.

Does a headless solution require the entire online shop to be replaced?

Not always. You can start by implementing a new interface for a selected channel, whilst keeping the existing shop engine running. This approach allows you to test the new shopping journey before rolling out more extensive changes. Replacing the backend may be necessary if the current system does not support the required features or integrations. The scope depends on the technical dependencies and processes that the shop needs to retain.

Can I migrate an existing shop to a headless platform?

Yes. You can plan the migration for an existing shop by transferring data and functions in a pre-determined order. Prepare a mapping of product fields, customer IDs and order statuses. Next, test a sample of data and purchase scenarios, including a customer placing an order again. This check helps to identify discrepancies before the new solution handles a larger proportion of sales.

How does a headless approach affect the development of new features and integrations?

Separate layers allow the user interface and back-end to be developed at different rates, provided that the rules governing their integration are clearly defined. For example, a new search engine can be integrated via an API without having to change the entire payment flow. Record the scope of data exchanged via integrations and test them following updates. This makes it easier to determine which part of the system requires modification.

What is headless commerce architecture and how does it work?

This is a way of building a shop where the customer interface is not permanently linked to the sales engine. The frontend retrieves the necessary information and passes the user’s actions via an API. For example, a customer browses the range in the app, and their order is sent to the same back-end system as purchases made on the website. This allows different channels to utilise shared sales processes.

An article by

Andrzej Klimek

Owner of Internet Stars since 2008