What would it take for the cost of doing nothing to finally outweigh the risk of making a move? That’s the question most CIOs running IBM Sterling Order Management are quietly sitting with, not because the system doesn’t work, but because they can feel, in the day-to-day, exactly where it’s slowing them down. You feel it every time a new integration request lands on the backlog. Every time an upgrade cycle breaks something that took months to build. Every time a business stakeholder asks why a feature that sounds simple is going to take six months. And the longer that feeling goes unaddressed, the more it’s worth putting a number on.
So here’s that number, or at least, the shape of it: how much is that friction actually costing you?
Not just in license and maintenance fees (though those compound every year) but in the innovation you can’t ship. The speed you can’t match. The engineers who spend cycles managing technical debt instead of building competitive advantage. The customization layer that’s grown so complex that nobody wants to touch it anymore. Understanding that full cost is the first step, because once you see it clearly, the calculus around risk starts to look very different.
What Does “Technical Debt” Actually Cost a Retailer?
IBM Sterling is a powerful system. Nobody disputes that. But power without agility has a price, and in retail, agility is the game.
Think about your current environment for a moment. How many integrations are held together by logic that lives in one person’s head? How often does a platform upgrade feel less like progress and more like a risk event? When a new channel or fulfillment model emerges — same day delivery, 30 minute pickup, new marketplaces, social commerce, AI-powered buying — how long does it take your team to respond? The answers to those questions are where the real cost lives.
The cost of staying put isn’t a one-time charge. It compounds. Every year your platform makes change harder, your competitors who don’t have that constraint pull further ahead. That’s the cost that rarely makes it into the business case — not what Sterling costs to run, but what it costs you to stand still. And once you start measuring it that way, the migration risk conversation changes completely.
The Migration Risk That’s Keeping You There. Is It as Real as It Feels?
Here’s something worth examining: the fear of migration often outweighs the actual risk of migration.
That’s not a criticism. Complex, deeply integrated systems with years of business logic built up are genuinely daunting to move. A “big bang” cutover that bets the business on a single go-live date is a legitimate concern, and one that’s shaped how a lot of organizations think about OMS migration in general. But the way migration is engineered has changed.
What if AI could read your existing Sterling environment, map your actual requirements, and accelerate the build of every integration you need? What if each integration that used to take one to two development sprints now took two to three days. Fully tested, fully bespoke, built to support your custom attributes and unique requirements? What if you could go live in phases, market by market, banner by banner, so you’re never exposing your entire operation to a single point of failure? The risk profile of that migration looks nothing like the one you’ve been picturing.
In enterprise software, failed implementations aren’t the exception, they can be common. So what does it mean that every project Fluent has ever started has gone live? That’s not a hypothetical. It’s the record Fluent Order Management has built across their customer base. That record doesn’t happen by accident, it’s because of the way the platform is built. How does modern OMS architecture support go-live success?
What Modern OMS Architecture Actually Looks Like
Most order management systems are built around a fixed set of workflows. You can configure what’s there, but you can’t fundamentally change the shape of it. IBM Sterling is a good example. The workflow exits are predetermined, which means your fulfillment logic has to bend around the platform rather than the other way around. Fluent is built differently.
Every workflow is made up of individual fulfillment logic rules, and those rules are completely modular. You can create new ones, place them anywhere in a workflow, and the platform doesn’t constrain where they can go. There are no predetermined exits, no locked sequences. If your fulfillment logic is unique (and in retail, it almost always is) you can build exactly that, without workarounds.
The same principle applies to the UI. Every component is independent. You can take an existing component, deploy it in a new context, reuse it across multiple screens, or build a net-new one from scratch and place it wherever it’s needed. Fluent provides a library of pre-built rules and UI components to start from, so you’re not beginning with a blank page. But that library is a starting point, not a ceiling.
What that means in practice is a platform that can model the way your business actually operates, not a version of your business that’s been adapted to fit the platform. And once that foundation is in place, what you can build on top of it changes the conversation entirely.
There’s a version of “modern” that’s really just old architecture with an AI layer bolted on top. Vendors will tell you they support AI agents. What they often mean is they’ve added a wrapper around a workflow engine that was never designed for it, and that distinction matters the moment you try to do something genuinely new.
Real modern architecture is event-driven and API-first from the ground up. When your fulfillment workflows are built on those foundations, an AI agent can step into any point in a fulfillment flow, take action, and hand back to the deterministic process, without custom plumbing, without breaking things downstream. It’s the difference between an architecture that enables AI and one that merely tolerates it.
It also means that when something like the Universal Commerce Protocol (UCP) emerges, where a customer asks an AI assistant to find and buy, and the order routes directly to your fulfillment system, you can support it in hours. Even bypass your commerce platform entirely (and skip the related transaction fees). How long would it take your current architecture to respond to a shift like that? The answer to that question is a good proxy for the broader conversation about integration speed, which is where OMS programs have always lived or died.
The Integration Question
In any order management implementation, integrations are where time, budget, and risk tend to accumulate. A complex project can involve 30 or more. At one to two development sprints each, the math adds up fast, in cost, in calendar time, and in the surface area for things to go wrong. It’s often the integration burden, more than anything else, that makes a migration feel too heavy to take on.
What would it mean for your next program if that integration risk effectively disappeared?
Using AI-powered integration development, bespoke connectors, perfectly matched to your specific requirements (not generic adapters that break when they hit your custom attributes) can be built and fully tested in two to three days. That’s more than an 80% reduction in integration time. Not a small efficiency gain, but a fundamental change to the risk profile of the entire project. And it opens up a different question: if the integration burden is solved, what else becomes possible?
Multi-Banner, Multi-Market, One Platform
For retailers and brands running more than one banner, or operating across multiple markets, there’s another dimension worth thinking about. What does it cost, operationally and technically, to maintain separate infrastructure for each brand? And what would it mean to consolidate onto a single platform instance where every brand keeps its own fulfillment DNA (its own sourcing logic, its own workflows, its own customer experience) while sharing common infrastructure?
What would it mean to onboard a new brand in four to five weeks instead of months?
If you operate globally, how much of your current complexity exists simply because your platform wasn’t designed for phased, market-by-market rollouts? Some markets in Europe can be combined because fulfillment logic is similar. Others, particularly in Asia, need to be handled separately. That’s operational knowledge that takes years to learn… unless you’re working with a platform and a team that has already built that playbook across customers in over 70 countries. Which brings up the question of who else has already made this move.
You Wouldn’t Be the First
Sometimes the most useful signal is who else has already made the call.
Kingfisher (B&Q, Screwfix, and Castorama) moved from IBM Sterling to Fluent. So did ALDO, MediaWorld, and Freedom Furniture. These are complex, high-volume retail operations that looked at the cost of staying put and decided it was greater than the risk of moving. And every single one of them went live.
JD Sports, Breitling, L’Oreal, Puma, Primark, Sephora, the Prada Group. All live. No implementations dragged out for years. No projects quietly shelved. Just go-lives. In enterprise software, that’s rarer than it should be. And it’s the kind of track record that reframes what’s actually possible when you’re ready to have the conversation.
The Question Underneath the Question
The build-vs-buy debate used to be the first conversation in any OMS evaluation. AI has changed that. The question now is: does your architecture support the way software is actually being built today?
Can your team use Claude Code with a skills file to build a new UI component or a fulfillment logic module in five minutes instead of a week? Can a developer use your enterprise AI tools to create a bespoke integration and have it hardened and tested in days instead of a sprint? If your answer is “not really”, or “it depends on a lot of custom work to get there”, that gap is going to widen every year, not narrow.
Is the Risk of Moving Really Greater Than the Risk of Staying?
That’s the question worth sitting with. Not as a vendor pitch, but as a genuine strategic question for your organization.
The customization debt. The upgrade risk. The innovation backlog. The integrations held together by institutional knowledge. The features you can’t ship. The speed you can’t match. At what point does the cost of staying put exceed the risk of making a move that’s been carefully, specifically engineered to succeed?
That conversation is worth having. And if you’re a CIO or solution architect who’s been carrying this question for a while, it might be time to have it with someone who can show you (concretely, technically, with a track record to back it up) what the path forward actually looks like.
Fluent Order Management is a cloud-native, API-first OMS used by retailers and brands in over 70 countries. Every implementation that has ever started has gone live. Want to learn more? For a free legacy migration assessment, contact us today.
