Modernizing commerce: How to reduce risk and speed up time to value

Modernization is back on the agenda. But so is the skepticism.

IT modernization has climbed back to the top of the CIO and CTO agenda, and AI is the reason why. Generative and agentic AI can now read code, write new code and test systems at a pace that wasn’t possible a few years ago. BCG’s 2026 research on AI-driven IT modernization found that organizations applying the right AI to the right task, in the right context, can cut modernization costs by 25% to 35% and reach implementation 30% to 40% faster.

While AI has indeed made inroads into the technology modernization arena, with immense potential to reduce both costs and project timeframes, many CIOs and CTOs have heard similar promises before and have been disappointed with the results. 

For well over a decade, the success rate of digital transformation and replatforming projects has stubbornly underperformed, which is exactly why so many leaders remain cautious about signing up for another one, AI or not.

But modernizing commerce has become increasingly crucial as enterprises feel the pressure to leverage agentic shopping. Working with legacy infrastructure is now a real liability. So, what can be done to reduce the time-to-value gap and minimize risks, enabling enterprises to modernize without the prohibitive costs and efforts of a long-term project? 

We’re already seeing the impact with our customers. A modernization project that once took a year to complete now takes an average of eight months, with a clear and sharp downward trend. For example, enterprises Coflex, a plumbing manufacturer, and HelloPrint, a global online printing and merchandise platform, have modernized commerce in 90 and 67 days, respectively. What was once an exception is now becoming the rule. 

This article pinpoints the main issues enterprises face when considering a modernization project, and provides an overview of how commercetools tackles each of these risks, helping our customers see the value of modern commerce faster than ever before. 

6 modernization risks to watch for

Even well-planned modernization efforts can face risks that increase costs, delay delivery or limit value. Understanding them in detail is what separates programs that stay on track from those that quietly become multi-year, over-budget projects everyone dreads.

1. Product data slows everything down 

Years of inconsistent product data, regional variations and custom attributes can make product modeling one of the longest and most complex parts of a modernization project. 

Every business that has operated for more than a few years is sitting on product catalogs shaped by mergers, regional teams working independently, one-off customer requests, and legacy systems that forced awkward workarounds into the data itself. Untangling that into a clean, scalable model traditionally means months of workshops, spreadsheets and manual reconciliation. 

Because the product data model underpins search, personalization, pricing and every downstream integration, mistakes made here ripple through every other workstream, often surfacing only after teams have already built on a flawed foundation.

2. Big-bang migrations create unnecessary risk 

Replacing every capability at once — checkout, catalog, pricing, promotions, order management — in a single cutover dramatically increases project complexity. 

Every capability added to the scope multiplies the number of interactions to be tested, the number of teams to coordinate and the number of things that can go wrong on go-live day. It also means the business sees zero return until the entire program is finished, sometimes years after it started, which is precisely the dynamic behind the ballooning budgets and stretched timelines that make these programs so risky in the first place.

3. Integrations become the real project 

Enterprises rarely fail to implement a commerce platform; they get stuck reconciling it with everything already in production. ERP, OMS, PIM, CRM, tax, payments and fulfillment systems each define product, price, order and customer differently, and connecting a new commerce layer to all of them, without breaking any of them, is often where the majority of a project’s time and budget actually goes. 

Worse, many of the real integration requirements don’t surface until deep into the build, because they live inside business processes and organizational silos rather than in the original project scope or RFP.

4. Every change depends on developers 

When marketers, merchandisers and digital teams can’t launch a campaign, update a storefront or test a new customer journey without opening a developer ticket, the business is throttled by engineering capacity rather than by strategy or market opportunity. 

This dependency compounds during and after modernization: Developer backlogs grow, business teams lose the ability to move at the speed the market demands, and the very engineers a company needs for high-value work end up absorbed by routine changes instead.

5. Innovation stops during modernization 

Many organizations quietly pause feature releases during a migration, treating modernization and innovation as mutually exclusive. 

That pause can last for months or years, depending on the program’s scope, and it has a real cost: Competitors keep shipping, customer expectations keep moving, and the business postpones the very ROI that was supposed to justify the modernization investment in the first place. By the time the new platform finally launches, the roadmap that justified it may already be out of date.

6. Total cost of ownership keeps climbing after go-live 

Modernization risk doesn’t end at launch. Composable and headless architectures give enterprises flexibility, but they also push a lot of integration and orchestration work onto each individual frontend or project team. 

In practice, this means every new market, brand, or storefront often ends up rebuilding the same connective plumbing to wire the commerce platform to search, tax, promotions and other vendors. That’s work that must be maintained, patched and retested indefinitely. 

What looks like a one-time integration cost at go-live can quietly turn into a permanent middleware function that the business now owns, staffs and pays to keep running.

How commercetools helps enterprises modernize with less risk and faster time to value

With commercetools, enterprises can reduce complexity, modernize incrementally and continue delivering business value throughout their transformation.

Product data: From blank schema to structured foundation in minutes

The Smart Data Modeler addresses risk #1 directly. Instead of starting product data modeling from a blank schema and thousands of inconsistent SKUs, teams upload representative product data and the tool analyzes it for patterns that are hard to see manually (inconsistent naming conventions, attribute sprawl, legacy workarounds, category drift), and proposes a normalized product model, along with suggested product types and attributes, in minutes. 

That draft gives developers and architects a validated starting point to refine, rather than a blank page to fill, which turns a process that used to take months of workshops into one that takes days or weeks. 

Because mis-modeling data and discovering it late is one of the largest hidden risks in any migration off a monolith like SAP, Adobe or Salesforce, catching structural issues at this early stage protects timelines further downstream. 

The tool also maps existing catalogs to the attribute requirements of specific AI shopping channels, flagging missing mandatory fields before launch, which matters more as commerce increasingly shifts toward agentic and AI-driven discovery.

Modernizing in phases instead of all at once

Risk #2 — the big-bang migration — is addressed architecturally rather than procedurally. commercetools offers standalone modules, including Core Commerce (cart, order and checkout) and Product Catalog, that enterprises can adopt independently rather than replacing an entire platform in one project. 

This means a business can modernize its checkout experience this quarter, its product catalog next quarter, and its order management after that, with each phase delivering measurable value and de-risking the next one, instead of betting years of budget on a single go-live that either succeeds completely or fails expensively.

The very nature of modular, API-first infrastructure also means companies can use the strangler pattern, a migration method that enables the migration of small, bite-sized components from the legacy platform to the new one. 

Making integration the platform’s job, not every team’s job

Risks #3 and #6 — integration complexity and its long-term cost — are where the upcoming commercetools Integration Layer is most directly aimed. 

Composable architecture gives merchants freedom, but historically it has pushed integration complexity onto every individual frontend: commercetools sees this pattern across its own customer base, where typical time to go live runs around eight months, in part because each of its 30+ systems integrator partners ends up building custom orchestration logic from scratch on every project.

The Integration Layer is a commercetools-hosted service that exposes a single GraphQL API combining commercetools APIs with partner vendor connectors for search, CMS, promotions, tax and more. Storefronts, apps and AI agents consume one unified endpoint instead of stitching together many systems themselves, and because the layer is headless, multi-tenant and frontend-agnostic, a single deployed instance can serve multiple commercetools projects and multiple frontends at once. 

Centralizing that logic into reusable, commercetools-hosted connectors means teams no longer have to rebuild the same plumbing on every project. And because commercetools hosts and maintains the layer, merchants avoid the ongoing costs of owning and running their own middleware, directly lowering their total cost of ownership (TCO). 

In addition, it changes when value gets delivered: Rather than integration work paying off only once, at launch, new commerce features are built directly into the layer as commercetools releases them, so merchants stay current with far less effort required to adopt each update.

Building with AI: Freeing business teams — and developers — from the ticket queue

Risk #4, the developer bottleneck, is where commercetools for Builders does the most work, and it's the clearest example of what “building with AI” actually means for a modernization program, rather than just a faster way to spin up a storefront. It’s a growing library of AI skills that plugs directly into the tools engineering teams already use, like Cursor and Claude Code, turning plain-language intent into production-ready commerce functionality, all built on the same Sphere platform, APIs and certifications enterprises already depend on.

What makes this relevant to modernization specifically is the scope it’s grown into. commercetools for Builders started with enabling business users to create digital storefronts without coding anything, and now it’s evolving into: 

• Skills for the foundational work of a project, such as checkout, storefront and functional commerce modeling. 
• Skills for integrations covering the connections a modernization effort has to get right, regardless of team size (payments, tax, order management, PIM, CRM, promotions, email, gift cards, search, analytics and marketplace) following the same arc as a real implementation rather than stopping at the storefront layer. 

That progression matters because it’s being extended to the integration and migration work, which is usually the slowest and most specialized part of modernizing a legacy platform.

It’s worth noting that the effect isn’t that AI replaces engineers. It’s that standard, repetitive commerce functionality — much of which is identical across implementations regardless of industry — that gets built in a fraction of the time it used to take, so marketers, product managers and less technical builders can make changes that once required a developer ticket, and engineers can validate results from multiple angles instead of writing every line themselves. 

That frees engineering capacity for the parts of a modernization program that genuinely differentiate the business, rather than the parts every commerce implementation needs anyway. This is exactly the kind of shift that turns “building with AI” from a developer productivity trick into a lever for de-risking and accelerating modernization at the program level.

Shipping value continuously instead of waiting for one go-live

Finally, risk #5 — innovation stalling during modernization — is a direct consequence of the big-bang mindset, and it’s solved by the same modular architecture that addresses risk #2. 

Because commercetools lets enterprises modernize one capability at a time, teams aren’t forced to freeze the roadmap until a single monolithic project finishes. New capabilities, campaigns and storefront experiences can keep shipping throughout the transformation, so the business starts realizing ROI in months rather than waiting years for a one-big-bang launch to prove itself.

A different way to modernize

None of this makes modernization risk-free. Large-scale technology change is still hard, and the failure statistics that have held for over a decade are a reason to take it seriously. But the risks that most often derail these programs are specific and well understood, and each one has a corresponding architectural answer rather than just a mitigation plan. 

By combining a modular platform with AI-assisted product modeling, AI-assisted building and a hosted integration layer, commercetools gives enterprises a way to modernize incrementally, contain the risk of each step and keep delivering business value throughout the journey, instead of waiting years for a single, high-stakes go-live.

Contact our team to find out the best way to reduce time-to-value when modernizing your commerce with commercetools.