Ebook | 16 minute read
Written in collaboration with Warren McNeel, founder of enterprise technology research and advisory firm Entechra, and former senior vice president at T-Mobile.
Every enterprise leader considering a digital transformation feels the same tension. There is real pressure to modernize quickly, catch up to customer expectations, and unlock the kind of velocity that competitors are already demonstrating. But moving too fast carries its own risk, and enterprises that treat transformation as a single, sweeping event tend to discover that risk the hard way.
Successful transformation is a sustained capability. The goal is to build a strategy that can survive leadership changes, market shifts, and technology cycles you can’t yet anticipate. That distinction, between transformation as an event and transformation as a capability, is the foundation of everything in this guide.
What follows is a practical framework drawn from decades of leading large-scale technical transformation across some of the most demanding, highest-traffic environments in commerce and technology. The framework applies broadly, but it is written with a specific lens: B2B commerce transformation, where the stakes are especially high. Legacy systems, multi-channel complexity, and long-standing vendor relationships make commerce one of the hardest (and highest-value) places to get transformation right.
This guide will walk through:
It closes with a case for why the architecture decisions made today determine whether an enterprise is ready to take advantage of what comes next.
Key TakeawaysBreak large transformation programs into smaller phases instead of one coordinated rip-and-replaceSeparate UX planning from architecture planning early, and staff bothInterview long-tenured employees now and document what they know before a transformation startsEvaluate vendors on architectural fit for your business, not just brand recognitionFlag any platform decision that would force you to design around it rather than with it
Before looking at what works, it is worth understanding the patterns behind what does not. Across large enterprises, the same handful of mistakes tend to repeat themselves.
The most common failure is what I call the Big Bang approach, or attempting to replace an entire technology stack at once. It is an understandable instinct. A legacy system is causing pain across the business, and the temptation is to rip it out and start fresh in one coordinated push. In practice, this approach carries an outsized amount of risk. New information may come up mid-program that you did not account for in the original plan, and by the nature of how enterprises operate, that new information often causes significant rework. A large, monolithic plan does not have much room to flex once you begin to execute it, and if you commit to this approach, you usually pay for it in delays, budget overruns, or outright program failure.
Many transformations are framed narrowly as user experience problems. Leadership knows what they want the customer-facing experience to look like, so that becomes the entire focus. However, the user experience is only the visible layer. The architecture underneath is the hard part, including how to manage compute, data flow, and system integration.
These underlying “pipes” help the user experience to function the way the business wants it to. If you treat transformation as a user interface project without addressing the architecture beneath it, you tend to build something that looks right in a demo, but does not work in production.
In most large enterprises, a meaningful amount of critical systems knowledge lives with a small number of long-tenured employees and was never formally documented. This knowledge gap becomes a serious liability during a transformation, when teams need to understand exactly how existing systems behave in order to safely change them. Finding the people who hold that institutional knowledge, and building a process to capture and document it as the transformation proceeds, is one of the most underrated parts of a successful program.
There is a well-worn pattern in enterprise technology where organizations default to the most established, best-known vendor because it feels like the lower-risk decision. Everyone knows the platform, and choosing it feels defensible in a boardroom. The hidden cost of that logic is long-term inflexibility. A platform built for broad, generic use across thousands of customers is often optimized for simplicity and standardization, not for adapting to the specific architecture, workflows, and complexity of a given enterprise. What looks like the safer choice in the short term can become the more limiting choice as your business evolves.
This connects to a broader point about platform selection. The right platform should be an enabler that lets the business adapt and grow. It should not become a constraint the business has to design around. When a company is forced to compensate elsewhere in its architecture because a platform only operates one specific way, the platform has become a limitation rather than an asset, regardless of how simple it initially looks to implement.
Key TakeawaysStart every transformation conversation with a compute audit (on-prem, cloud, or hybrid)Use the Strangler Pattern: build new microservices alongside legacy systems rather than replacing them outrightStand up a cross-functional steering group with technology and business stakeholders from day oneMaintain two planning horizons: a high-certainty 90-day plan and a directional 6–12 month planPair experience metrics (transaction time, funnel drop-off) with business metrics (support volume, conversion) in the same dashboardUse blue-green or canary deployments to test changes on a small user set before full rolloutPrioritize vendors willing to build a working proof of concept over those who only present capabilitiesUse AI-generated prototypes to skip lengthy requirements-gathering cyclesTie infrastructure investment to incremental, visible wins rather than one large upfront business caseStress-test systems for traffic well beyond projected peak before major launches or campaigns
None of the issues described in the failures section above are inevitable. They are avoidable with the right approach. The following framework reflects what has consistently worked across large, complex transformation programs I’ve been a part of.
Every transformation conversation should start with compute. Is the business running on premises, in the cloud, or in some hybrid combination? For most enterprises, it is rarely one or the other. From there, the natural progression is to build a modern architecture using microservices and APIs, since individual components break down complexity and open up functionality that ultimately drives the customer experience.
Layering a strategy around APIs also means you are not rebuilding the same capability multiple times across different channels. All of this builds velocity, so that by the time you are ready to focus on the experience layer (and eventually on capabilities like AI) the underlying stack can support the speed the business wants.
For large enterprises running packaged software integrated across many parts of the business, I favor what is known as the Strangler Pattern. Rather than replacing a legacy platform outright, you build new capabilities alongside it. Over time, you reduce reliance on the old platform. The business keeps running on the existing system while you pull individual pieces of functionality into microservices, one at a time, like building blocks. This approach lets you make changes far more quickly than you can with a full-stack rip-and-replace, and it dramatically reduces the business risk that comes with attempting a large-scale platform migration in one motion.
For B2B commerce specifically, this matters more than anything else. Legacy ERP and order management systems rarely get replaced overnight, and they should not need to if you want to modernize the buying experience. An incremental, API-first approach lets you layer modern commerce capability on top of (and gradually independent from) the systems it already depends on.
A good example of an API-first commerce transformation is the case study for Johnstone Supply, the largest HVAC/R wholesale distributor in the U.S. The company’s cooperative history had left the business running on more than 100 independently operated ERP systems and 120-plus fragmented catalogs. Rather than forcing every store onto one system at once, Johnstone used an API-first commerce layer to unify the customer-facing experience across all of it, while leaving individual store ERPs in place. The company is now consolidating those systems gradually, over a multi-year timeline, without interrupting service. In the meantime, the unified layer already supports over a million SKUs and has driven a $300 higher average order value online than at the counter.
One of the biggest determinants of whether a transformation succeeds is whether business and technology teams are brought into decision-making from the start, rather than being told about a change after the fact.
I have consistently built cross-functional steering groups that bring together a technology lead with any business unit that will have a material effect on what we’re building, from sales to finance to operations. The level of involvement can vary. Some groups need to be part of daily conversations, others just need to stay informed. What matters is that no group is surprised three months later by a change that affects their work. Bringing people into the room to work through difficult tradeoffs in real time consistently accelerates programs rather than slowing them down.
Transformation planning works best when it operates on two timelines at once. The near-term window, typically the next 90 days, should carry the highest fidelity and the most certainty. The longer window, 6-12 months out, is more directional and should be expected to shift as you get new information. Regular, predictable updates to business stakeholders build trust and give teams the clarity they need for their own planning. This approach lets your business users prioritize what gets built, and ties the technology roadmap to what matters for the business.
Every transformation program should track experience metrics, such as how long it takes a user to complete a transaction or where they drop off in a funnel, alongside business metrics like support call volume or conversion. Deployment strategies like blue-green or canary releases make this possible without unnecessary risk. You put a change in front of a small set of users first, measure it, and expand it only once it is working as expected. Having that telemetry in place means a program can adjust in near real time when a KPI is not tracking the way you expect it, rather than discovering the problem months later.
Highly declarative, out-of-the-box platforms can be fast to implement, but that speed often comes at the cost of flexibility as the business grows. The evaluation that matters most is architectural fit: does a vendor's approach to building software match how your organization wants to operate? Are they willing to build alongside you, or are you expected to work around a fixed set of capabilities? Do they build the implementation themselves, or hand it to a system integrator? The vendors worth partnering with are the ones willing to demonstrate a working proof of concept instead of simply describing what their platform can do.
AI is dramatically shortening the distance between an idea and a working prototype, particularly on the experience side. Business users no longer need to wait for a fully scoped requirements document before testing an idea. When you build a rough, imperfect prototype, you can move a project forward faster than weeks of upfront specification. This does require an organizational shift: less time spent in traditional requirements-gathering, and more time spent identifying components and the relationships between them, since that is where transformation programs run into the most friction.
Incremental business-case building lets a company demonstrate value continuously — whether that is cost reduction, performance improvement, or sales lift from a simplified process — instead of betting an entire investment on a single upfront pitch. Infrastructure becomes far easier to justify internally when it is tied to visible, incremental wins.
Commerce plays a critical role in architecture and in the end user experience. In my past roles, we put a significant focus on performance of the user experience; everything had to render in two seconds or less. Having a platform that can respond quickly, regardless of complex product assortments, was key to achieving that goal. The results were more cart completions and simplified flows that allowed channel-shifting and offered a true digital experience. When that happens, the business thinks differently about how to create stronger connections with customers and open new business opportunities.
High-traffic moments like product launches, major campaigns or live events are where architecture decisions get tested in the real world, often with no room for error. Resilience, performance, and operational visibility are business continuity requirements. The difference between a system that holds up under pressure and one that does not is often the difference between a defining customer moment and a damaging one.
For example, in the wireless space, the launch of the iPhone is a major event that creates significant system pressure over a short period of time. Architecting a solution that can easily and cost effectively scale is the difference between providing an amazing customer experience or leaving users frustrated and dissatisfied. When the platform is used in one of the most visible moments in the category, you need to have confidence it will perform. Testing commerce to volumes far exceeding volume targets is critical, and allows teams to become much more proactive in their approach to key events.
Key TakeawaysBuild core commerce capability once and expose it via API across every channel, rather than duplicating logic per channelModernize B2B-specific complexity (pricing, contracts, catalog structure) incrementally, one component at a timePilot a minimum viable version in a single market, segment, or region before scaling globallyConsolidate fragmented platforms into a single headless commerce layer while leaving legacy backend systems in placeInvest in clean, structured, API-accessible catalog data now to prepare for AI discovery
B2B commerce is a natural home for the incremental approach described above. Historically, the channels a B2B enterprise serves (e.g. retail, digital, and direct B2B ordering) were often built independently of one another, each with its own logic and its own limitations. An API-first architecture makes it possible to build core commerce capability once and expose it across every channel a business needs to serve, rather than duplicating that work channel by channel.
B2B commerce also carries a layer of complexity companies often underestimate. Complexity might include catalog structures, customer-specific pricing, contract terms, and order management workflows that simply do not exist in most B2C environments. An incremental, API-first approach matters so much in this context. It allows you to modernize one component, whether that is pricing logic, catalog data, or the checkout experience, without having to re-architect the entire stack at once.
One case study that illustrates a gradual transformation is IMI, a global manufacturer of precision engineering products selling into industries from industrial automation to healthcare technology. The company spent years delaying a full commerce replatform because the team feared the disruption would mean pausing business growth. Instead of a single rip-and-replace, IMI proved the model with a small pilot: a minimum viable commerce site launched for Ireland alone, while the rest of the business kept running on its existing system. That low-risk proof point gave the team the internal case to expand, market by market, to dozens of countries and currencies. The result has been a 100% increase in gross merchandise value and a platform now supporting more than £2 billion in annual transactions, without a single disruptive reset.
And T-Mobile's transformation is a clear example of what resilience at scale actually requires. The business had been running commerce across eight disconnected platforms, a fragmentation that made consistent customer journeys difficult and turned high-traffic moments like an annual device launch into high-stress, war-room events. As described in the T-Mobile transformation case study, digital commerce accounted for just 0.4% of total transactions despite T-Mobile's scale, a sign that the infrastructure itself was the limiting factor. Rather than a full rip-and-replace, the team built a cloud-native, headless commerce layer that consolidated all eight platforms into one system, powering product catalogs, pricing, promotions, and checkout across web, mobile app, and thousands of retail locations. An active/active, multi-region architecture with blue-green and canary deployments meant the system could absorb 10x traffic spikes without degrading the experience, and digital's share of commerce grew from a fraction of a percent to nearly 100%.
This is also where the conversation about commerce infrastructure connects to a broader industry shift toward AI-ready catalog data. A catalog that is clean, structured, and accessible through well-defined APIs is the foundation that allows you to layer AI on top of commerce experiences in the first place, a theme this guide returns to in its conclusion.
Architecture and process only go so far without the right culture behind them. Some of the most effective transformation work follows a simple philosophy: set the objective, build the strategy, train the team, celebrate the wins, build excitement, and spread the word. Momentum in a transformation program is as much a cultural outcome as a technical one.
Creating the conditions for engineering teams to take on hard problems requires psychological safety to prototype and to fail fast, paired with leadership that sets a clear vision without over-prescribing exactly how teams get there.
In my current role at Entechra, and while working with several clients, I have found a common thread. Moving from on-prem to the cloud, replacing monolithic systems with microservices, leveraging APIs, and integrating AI into experience and process all require new skills for teams and a willingness to take manageable risks. When done right, I have seen enterprises move from once-a-month, highly coordinated change processes to teams moving to independent daily deployments.
That means velocity for the business and lower risk to operations — both are meaningful outcomes. Having said that, if teams don't feel safe to evolve, it will be a short-lived journey. When issues are treated as opportunities to learn and improve, and people feel that support, they will embrace the change and become accelerators to evolving technology.
The throughline of everything in this guide is simple to state and hard to execute. Transformation succeeds when it is incremental, cross-functional, and architecturally sound. It fails when it chases a single big move. Building this strategy allows you to withstand leadership changes, market shifts, and technology you can’t yet predict. That lets you turn transformation from a disruptive event into a sustained advantage.
That same principle is what determines your readiness for what comes next. You’ll be best-positioned to take advantage of AI if you’ve already built an API-first, adaptable architecture, the same architecture this guide has described as the foundation for every other kind of transformation. An API-first commerce foundation provides flexibility today, while laying the foundation for what AI makes possible tomorrow.