Shopify Plus Migration for Unilever Food Solutions: An Example for What Really Matters After Launch

In B2C commerce, a shop project can sometimes be relatively clearly defined: product data, theme, checkout, payment methods, tracking, launch. Of course, there is still a lot of detailed work behind it, but the basic structure is often comparatively stable.

In enterprise B2B commerce, this is different. The shop is often connected to a grown system landscape and to sales processes that cannot simply be replaced by a shopping cart. Prices, availability, suppliers, minimum order values, assortments, customer accounts, internal roles, field sales, repeat orders and local market requirements all interact with each other.

For Unilever Food Solutions, this meant that Shopify Plus could not be treated in isolation. The shop had to work with existing systems, product data and external trade partners. This included integrations with partners such as Saviva and Mercanto, which were relevant for the operational ordering process. If these dependencies are not properly understood, you can quickly end up with a shop that looks technically modern, but does not work well enough in day-to-day operations.

That is one of the most common mistakes in migrations: companies evaluate the platform, but underestimate the operating system of the business behind it.

Of course, Shopify Plus is a central part of the solution. The platform provides a strong foundation, especially when companies want to move faster and reduce technical legacy. Still, the most important question in projects like this is not only what Shopify can do.

The more important question is often: where should each part of the business logic live?

At Unilever Food Solutions, we had to make conscious decisions about which requirements should live directly in Shopify, which should be handled through custom development and which should be solved through connected systems. Authentication was implemented with Auth0 because access to customer-specific content, prices and functionality had to be controlled and thought about beyond the shop itself. At the same time, we did not use a standard theme, but developed a custom theme to properly support the UX, B2B logic and performance requirements.

These decisions may look technical at first. In practice, they decide how well a system can later be extended, maintained and operated. A standard theme can be completely sufficient for many shops. In an enterprise B2B context, however, it can become too restrictive if central requirements constantly have to be built against the structure of the theme.

The same applies to apps. Standard apps can save a lot of time when they fit the process. But when they only partially cover central B2B workflows, they create workarounds that become expensive later. That is why we used custom apps for Unilever Food Solutions, including features such as wishlists and B2B loyalty.

The order lists were especially important in the B2B context because they were not just personal favorites. They could be shared within a customer company. For professional kitchens, that is not a nice extra feature. It is a real operational advantage.

One decisive point in this project was that planning did not only happen from the central team. Throughout the entire development process, there was a super user group from the sales organization that approved designs, carried out early tests and continuously contributed feedback from real-world usage.

This super user feedback was extremely important because it made many assumptions testable early. A design can look clean internally and still miss the reality of the users. A feature can be technically correct and still not fit the way sales teams work or the way customers place orders. The super user group helped close that gap during development, not only after launch.

Before the launch in February, we also traveled to the annual meeting of the Swiss Unilever Food Solutions sales teams in December and presented the new shop there.

This was not a classic presentation where a finished system is shown and then simply rolled out. It was an important moment to get feedback from the field. The sales teams knew the customers, the ordering habits, the objections, the recurring questions and the points where a digital process can fail in everyday work.

After this meeting, we set up a feature list with Nolt.io. Salespeople could submit new ideas and upvote existing suggestions. This quickly created a clear picture of which features were truly relevant in practice. Several important features could still be added or refined shortly before launch.

This part was central to the success of the project. Not because every requested feature should be implemented immediately, but because the relevant stakeholders were visibly involved. They could see that their feedback was taken seriously. They were not simply confronted with a new system after launch, but became part of the final direction.

This support made a big difference later. A digital B2B shop does not automatically become successful just because it is technically better than the old system. It has to be accepted, explained and actively supported internally. Especially in sales, this often determines whether a new commerce channel is seen as a helpful tool or as competition.

The later results show how important this acceptance was. A 41 percent revenue increase does not come from better technology alone. It happens when platform, processes and people work together.

Before a launch, you can test a lot: data migration, checkout, performance, integrations, tracking, permissions, responsive design and many edge cases. Still, no test can fully replace real usage.

After launch, it became visible what the new setup could do better in day-to-day operations. The APIs were more stable. Important pages went down far less often. Feature requests and bugs could be handled more quickly than in the old system. The UX was better, performance was better and features could be implemented that had previously not been possible, or only possible in a limited way.

At first, this may sound like a technical improvement. For the customer, however, it means something more concrete: less friction in daily work.

When professional kitchens order online, this is not a relaxed shopping experience. Users have little time, recurring orders and clear expectations around availability, speed and clarity. A better product detail page, a shared order list or a more stable ordering process are not cosmetic improvements in this environment. They reduce effort, avoid mistakes and make the digital channel more reliable.

This is also visible in the numbers. 15 percent more B2B orders does not simply mean more traffic or more usage. In a B2B context, it suggests that the channel became more accessible and more reliable for customers. A 4 percent higher average order value also shows that the shop was not only used more often, but also became better at supporting relevant orders.

This is exactly why post-launch optimization is not just bug fixing. After launch, the phase begins in which a commerce system is sharpened against real users, real processes and real requirements.

In many projects, stakeholder management is treated as an organizational topic. It sits next to architecture, development, UX and integrations. In enterprise commerce projects, this separation is often artificial.

When relevant stakeholders are involved too late, technical problems emerge. Requirements become visible too late. Interfaces are prioritized incorrectly. Features are optimized for the wrong users. The central roadmap may look clean, but local teams do not recognize their reality in it.

At Unilever Food Solutions, one of the most important lessons was to identify the relevant stakeholders even earlier and involve them more deeply. Not only the central project group, but also the people who are close to customers, sales and operational processes.

The super user group was an important mechanism for this. It did not reduce feedback to one big approval meeting at the end, but made it usable throughout development. This allowed designs, flows and features to be validated early with people who could assess the later reality of the system much better than a purely central project team.

This is especially important when a project touches several layers: global brand structure, local markets, external trade partners, internal IT, ecommerce, sales and end customers. In such environments, it is not enough to collect requirements once and then implement them. You have to understand who can really judge whether a solution works in daily operations.

The technical architecture can be as clean as possible. If the wrong people speak too late, the project still becomes unnecessarily risky.

A common mistake in Shopify projects is to either avoid custom development on principle or use it too quickly. Both can be wrong.

Too much custom development makes systems harder to maintain, more expensive and more dependent on specific implementation details. Too little custom development, however, can force central business processes into standard solutions that were not built for them.

In enterprise B2B, this decision has to be made especially carefully. Not every special requirement deserves an individual solution. But some processes are so close to the business model that they need to be modeled properly.

At Unilever Food Solutions, this included authentication, customer-specific functionality, shared order lists, loyalty and the integration of external trade partners. These were not just feature requests. They were relevant to whether the new shop could actually support B2B sales.

The better question is therefore not: standard or custom?

The better question is: which parts of the system are differentiating enough that they need to be built precisely, and which parts should stay as close to the Shopify standard as possible?

Projects like this show several points that companies should take more seriously before starting a migration.

The first point is stakeholder mapping. Who officially makes decisions, who influences the project informally, who will work with the system every day and who can identify early whether the solution misses practical reality? These groups are not always the same.

The second point is a continuous feedback process. A super user group can be very valuable here because it evaluates designs, prototypes and early features not only from a project perspective, but from the perspective of later usage. This makes feedback more concrete, earlier and easier to prioritize.

The third point is system boundaries. Companies should clarify early which logic belongs in Shopify, which belongs in the ERP, which belongs in the PIM, which belongs in middleware or custom apps and which should intentionally be kept out of the first launch. The later these boundaries are clarified, the higher the risk of workarounds.

The fourth point is post-launch capacity. Many project plans treat the launch as the destination and underestimate the first months afterward. But this is exactly the phase where many of the most important learnings appear. Teams need more than technical support here. They need decision-making capacity, prioritization and fast implementation.

The fifth point is internal communication. A new system does not only have to work. It has to be understood and accepted. Especially in B2B commerce, sales should be involved early because it often forms the bridge between the digital channel and customer reality.

The sixth point is the willingness to change the right things shortly before launch. Not randomly, not chaotically and not based on every individual request, but deliberately where practical feedback shows that a feature is critical for acceptance and usage.