> ## Content Index > Fetch the complete content index at: https://blog.tsd.digital/llms.txt > Use this file to discover other available public pages before exploring further. # How We Decide Which Commerce Engine an Umbraco Project Gets - URL: https://blog.tsd.digital/how-we-decide-which-commerce-engine-an-umbraco-project-gets/ - Published: 2026-09-16T19:11:09.000Z - Updated: 2026-09-16T19:11:09.000Z - Description: Asked at Codegarden when we switched to a commerce plugin, the honest answer is that we didn't switch. Our own engine still trades, uCommerce takes the complex builds, and Umbraco Commerce earned the mid-market tier one small project at a time. Here's how a platform earns its place. - Author: Tim Gaunt - Tags: 200k Mid Market Ecommerce, Ecommerce The last question at Codegarden was one I suspect a lot of Umbraco partners are quietly sitting with. When did you switch to a commerce plugin, and what was the hurdle? Plenty of agencies have history with other commerce engines and are weighing the same move, so here's our route on Umbraco, cautious bits included. We build on other stacks too, and I'll come to that. ## Four commerce engines, three still in production We've been building on Umbraco since around 2004\. Joe Davies, the giftware distributor from the ERP post, goes back almost that far. In those early days there was nothing to plug in, so we built our own e-commerce engine on top of Umbraco. It's still running. Joe Davies trades on it every day. When you've read this series arguing that boring, reliable technology outlives elegant theory, that engine is exhibit A. As the ecosystem matured we picked up uCommerce, which is still our go-to for larger and more complex builds, and Tea Commerce, which many in the community will remember fondly. Both brought the same trade-off: the commerce layer and the CMS were separate products with separate roadmaps, and we did the stitching. Umbraco Commerce (which grew out of Vendr, itself Tea Commerce's successor) changed that calculation for the mid-market. It joined the toolkit within the last two or three years, and we waited a few releases before starting. ## Dipping a toe, on purpose Smaller sites first, where the catalogue was modest and the risk contained. We used them to learn where the platform was strong and where it stretched. It did stretch, early on. Larger catalogues in particular showed the strain. Young platforms do that, which is why we tested with small projects. HQ has overcome a lot of those challenges since, and we're now confident putting far bigger builds through it than we'd have risked at the start. The largest and most complex catalogues still go to uCommerce, and I don't see that changing soon. If you're an agency considering the same move, I'd commend the approach over the conclusion. Pick a project where the downside is survivable, ship it, and let the platform earn the next tier of trust. Your clients are not your test environment, but your smaller projects can responsibly be your proving ground. ## Why it matters that HQ owns it I opened the Codegarden talk with the thing that makes Umbraco Commerce more than another engine choice. One licence now covers content, commerce and personalisation, all supported by HQ. For clients that's mostly a confidence question. A marketplace plugin, however good, carries a quiet risk premium. What happens if the maintainer moves on? Anyone who watched Tea Commerce become Vendr and then Umbraco Commerce knows consolidation happens. A commerce layer owned and roadmapped by the platform vendor takes that conversation out of the sales process. DynamicWeb has made the same single-vendor argument for years, and it's a fair one; Umbraco Commerce brings it to the Umbraco world. uCommerce is a different case. It's a commercial product with its own vendor and roadmap behind it, which is a large part of why we still trust it with the big builds. ## How we choose platforms now The honest answer I gave on stage is that the team largely drives it. The people who build and support these systems daily know where each platform's sharp edges are, and their confidence is worth more than any feature matrix. Then it gets balanced against what the client needs, and sometimes that points away from Umbraco altogether. Where a client wants ERP integration out of the box, with connectors maintained by the vendor, we build on DynamicWeb, which is designed around that. At enterprise scale it's Sitefinity. We're partners with all three, and the job is matching the stack to the client. Where the brief leaves us room to steer, we steer to the platforms we trust to still be boring and reliable in ten years. For most mid-market commerce that's Umbraco with Umbraco Commerce, and Umbraco with uCommerce where the catalogue size or the pricing rules push past what a younger platform should be asked to carry. ## For businesses commissioning a build Ask a prospective agency who owns the commerce layer they're proposing, and what its history is. Ask how they decided to trust it, and with what size of project first. An agency that can answer the way this post does, with a route it has tested on live projects, is telling you something about how it'll handle every other risk in your build. ## The takeaway Test on contained projects. Let the evidence expand the trust one project at a time, and weigh who owns the roadmap as heavily as what the features do. We've taken twenty years and four commerce engines to reach a position where three of them are still earning their keep, and the next one should have to earn its place the same way. That wraps the Codegarden material. Thanks to everyone who asked the questions that turned into these posts. The bar after the talk is where the best content comes from.