Sterling
Sterling did not need another workaround. They needed a platform the business could grow on.
Client
Sterling
Sector
Furniture retail / Omnichannel
Challenge
End-of-life platform, years of data and process debt, broken ERP integration, manual operations across every team
Solution
Umbraco to Shopify migration, Swan ERP integration, data and process debt remediation, custom omnichannel sales tools
Outcome
A platform every team can actually use - and a development budget finally available for improvement, not survival.
The Inflection point
There is a particular kind of infrastructure problem that doesn't announce itself all at once. It accumulates. A manual workaround here. A spreadsheet export there. A process that only works because one person knows how to read a particular set of handwritten notes. Individually, each compromise feels manageable. Collectively, they become the operating model.
That was Sterling's situation when they came to us.
A Scottish household name in furniture retail, with large showrooms across most major towns and cities, Sterling had built a strong business on the strength of its physical presence and the trust of generations of customers. But the digital side of the business had been running on borrowed time. An ageing Umbraco platform that was approaching end-of-life and a Swan ERP with no programmatic connection to the website meant that order data exported weekly to spreadsheets, processed manually, and handed off through a chain of steps that depended on institutional knowledge rather than reliable systems.
Online orders sat at around fifty per week. Not because demand wasn't there, but because the infrastructure couldn't support more without the manual overhead becoming unmanageable.
The pressure to change was already building before anyone used the word 'transformation.' Umbraco upgrades alone would have cost tens of thousands of pounds, just to stay operational, with no improvement to the customer experience or the underlying processes. Online-first competitors with lower overheads were beginning to undercut Sterling on price. Store footfall was declining. The digital channel, under-invested for years, was now a business resilience question.
The inflection point wasn't a single moment. It was the point at which continuing as before became more expensive than changing, commercially, operationally, and competitively.
Every pound Sterling spent on its digital infrastructure was going to keeping the lights on. Nothing was left for improvement. That's not a technology problem. It's a strategic one.
The Enemy: Accumulated Debt Across Every Layer of the Business
Transformation projects that start with a platform migration brief often have a more complex problem underneath. Sterling's was a clear example. The brief was to move from Umbraco to Shopify.
The actual problem was years of compounded debt across every layer of the business: technical, data, and process.
A platform past its end-of-life
Umbraco was no longer a viable long-term foundation. The cost of keeping it running was escalating with every upgrade cycle, and the platform's limitations meant that meaningful improvements to the customer experience were effectively off the table. Development budget was consumed by maintenance, with nothing available for the iteration and improvement the ecommerce team needed.
An ERP that couldn't talk to the website
Swan, Sterling's ERP, sat entirely disconnected from the digital channel. There was no programmatic data flow between the two systems. Product data had been entered inconsistently by the buying team over years, with no standardisation and no governance. The result was a product catalogue that couldn't be reliably served to the site, and an order process that required manual intervention at every stage.
Process debt that had become the operating model
The manual workflows weren't exceptions, they were the system. Orders were exported to spreadsheets on a weekly basis. Handoffs between teams involved paper notes. Key steps in the process depended on specific individuals who held institutional knowledge that existed nowhere else. This wasn't just inefficient; it was fragile. Any disruption to the people or the process introduced immediate operational risk.
Data that nobody owned
The buying team had complete freedom to set up products however they chose, with no standardisation across naming, fields, or structure. What looked like a product catalogue was actually a collection of individually configured records with no consistent logic connecting them. Before any integration could be built, this problem had to be solved and solving it meant convincing the people who had always worked this way that there was a better one.
Stakeholder complexity
A transformation of this scope doesn't succeed or fail on technical execution alone. Sterling's internal stakeholder landscape was complex: a generational, family-run business with established ways of working, teams with different priorities and concerns, and natural resistance to a project that would change how most of them did their jobs. Getting to launch required as much work on buy-in and change management as it did on the build itself.
The Decision: Clear the Debt Before You Build
The most important decision we made on this project wasn't technical. It was sequencing.
A typical migration engagement moves quickly to build. Brief in, architecture agreed, development starts. The problem with that approach on a project like Sterling's is that it builds on unstable foundations. You migrate the data debt. You automate the broken processes. You replicate the problems, just on a newer platform.
We pushed for something different: a three-month discovery and consultancy phase before a line of code was written for the new platform. Not an audit for its own sake, a structured programme of debt remediation, data mapping, and process design that would determine what the build actually needed to do.
This meant working through questions that don't appear in a typical project brief:
‣ What does product data need to look like in Swan before it can be reliably served to Shopify, and who is responsible for maintaining it?
‣ How do you build an integration with an ERP that has limited documentation, minimal vendor support, and an on-premise server sitting in a client office with firewall restrictions?
‣ How do you get teams who have worked a certain way for years to trust a new system enough to use it?
‣ Which manual processes can be automated, and which need to be redesigned before automation is possible?
The question wasn't whether to migrate to Shopify. It was whether the business was ready to migrate to Shopify, and if not, what needed to change first.
What we built
Discovery and consultancy: paying down the debt
The first phase of the project was dedicated entirely to the work that makes a migration last. Conceptual data mapping to define what product data needed to look like in Swan and how it should appear in Shopify. Tabletop exercises and process diagramming to validate data flows before anything was committed to build. Direct engagement across Sterling's teams; operations, buying, e-commerce and sales, to understand how work actually happened, and where the real bottlenecks were.
Sterling's stakeholders needed more than information. They needed to understand why the change was necessary, what it would mean for their teams, and what they were being asked to do differently. That work happened largely behind the scenes, but it was as consequential as anything on the technical side.
Swan ERP integration via Patchworks middleware
The integration between Swan and Shopify was the most technically demanding element of the project, and the one with the least predictable risk profile. Swan is an older ERP provider with limited documentation and minimal vendor support. Sterling's infrastructure was on-premise, meaning development access required navigating internal network restrictions, firewalls, and in some cases a physical laptop to access the environment directly.
We built end-to-end data flows covering product creation and catalogue sync from Swan into Shopify, and order and fulfilment workflows back to the ERP. Patchworks, the middleware platform already engaged by Sterling, sat in the integration stack as the intermediary layer. The work required solving problems under high uncertainty, in an environment where standard integration assumptions, documented APIs, responsive vendor support, accessible infrastructure, simply didn't apply.
The milestone; the first several hundred products successfully flowing through from Swan into Shopify after six months of consultancy and development, was a genuine turning point for the project.
Custom sales agent quote builder
One of the most commercially significant pieces of work on this project wasn't the storefront. It was a custom application built for Sterling's in-store sales teams.
The existing process for in-store assisted selling was broken. Quote creation in Swan was unusable in practice, which meant it wasn't being used. Sales staff had no structured way to build a quote on the shop floor and move a customer toward checkout. The result was friction at precisely the moment a customer was ready to buy.
We built a custom quote and basket builder inside Shopify that allows sales staff to construct a quote on the floor, email a link directly to the customer, and have the customer complete checkout online. The tool also tracks orders by store, giving Sterling visibility into in-store performance that didn't exist before. Every assisted sale now flows through Shopify, standardising the data, removing the manual handoff, and creating a consistent record across online and in-store channels.
Bespoke shipping logic
Sterling's product range presented a shipping complexity that Shopify's native capabilities couldn't handle out of the box. A catalogue spanning everything from small accessories to six-seater sofas, with mixed carts carrying items across different dispatch methods and lead times, combining Sterling's own delivery network with supplier-made-to-order timelines. Each combination required different pricing and fulfilment logic.
A custom application extended Shopify's shipping to handle this correctly: pricing based on product type and fulfilment method, with the right rules applied to mixed carts regardless of what a customer had added to their basket.
Complex catalogue and variant architecture
Tens of thousands of SKUs, many with high variation complexity across configurations, fabrics, and finishes. Getting the product architecture right on a catalogue of this scale matters not just for the customer experience. It affects how the merchandising and buying teams administer the range day-to-day, and how the site performs for SEO over time.
We made deliberate decisions about how variants were structured to avoid the kind of front-end technical debt that accumulates when complexity is handled with workarounds. The goal was a catalogue architecture that remained maintainable as the range evolved, and that aligned with how products were set up and managed in Swan.
Storefront and ongoing retainer
he storefront design phase was, by the client's own account, the smoothest part of the project. Delivering close to first time, and a clear step forward in how Sterling showed up online. Post-launch, Underwaterpistol continues on retainer, supporting the iteration and improvement that was previously impossible when every pound went to keeping the lights on.
The outcome
The measure of a transformation project isn't the launch. It's whether the business that comes out the other side can do things it couldn't do before.
‣ Sales floor teams now have a structured tool for assisted selling. Quotes built in Shopify, completed online, tracked by store.
‣ Operations and warehouse teams receive orders through a consistent, automated process. No spreadsheet exports, no manual handoffs, no reliance on one person knowing how the system works.
‣ Merchandising and buying teams work within a standardised data structure. Product setup governed by clear rules rather than individual preference, and a catalogue that stays maintainable as the range grows.
‣ The ecommerce team can finally iterate. Development budget that was entirely consumed by platform maintenance is now available for improvement.
Sterling went from a business where the entire digital budget was absorbed by a platform past its end-of-life, to one where every team has a system they can actually use, and the capacity to keep improving it.
what this tells us
Sterling is a useful case study in what the infrastructure ceiling actually costs a business. Not just the direct cost of platform maintenance but the opportunity cost of everything that can't happen while the budget is committed to keeping something broken running.
The decision to spend three months on discovery and debt remediation before building anything was the right one, and it's a decision that requires conviction to make. The pressure on any transformation project is to move quickly, show progress, and get to launch. Slowing down to do the foundational work properly can feel counterintuitive.
But migrations that skip this phase tend to replicate the problem on a new platform. The technical, process and data debt moves. You spend the same budget and arrive somewhere that looks different but works the same way.
The harder question and the one worth asking at the start of any project like this, is not what platform you should move to. It's whether you're ready to move, and what needs to be true before you do.
Answering that question honestly, and building a programme of work around the real answer, is the difference between a migration that lasts and one that creates the next problem.
Technology
Shopify Plus
Swan
Patchworks
Klaviyo
Services
Migration to Shopify Plus
Redesign
Custom build
ERP Integration
Business Transformation
Discovery
Consultancy
Is your infrastructure still fit for the next stage of growth?
If your development budget is going to maintenance rather than momentum, we should talk.
Free 1-hour senior consultancy. For brands at an inflection point.
A working session with our Delivery Director - not a pitch. For qualifying brands only.
