Mainframe-to-Cloud Journey: Enterprise Commerce (2026)

For many people, the term “mainframe” evokes images of rooms dwarfed by giant computers and teams of engineers in lab coats wielding punch cards and pens. The technology sounds like it’s from yesteryear, but more mainframes exist than you might anticipate. 

According to Ars Technica, there are as many as 10,000 mainframes in use today. They’re almost all used by the largest companies in the world, including seven of the top 10 global retailers. The truth is, as companies grow and tech debt deepens, migrating from old technologies and platforms is easier said than done. 

With more and more businesses migrating to the cloud, enterprise retailers who still use mainframes may face a tough choice. Migration may seem necessary, but when the mainframes in question run key commerce functions like order management, pricing engines, inventory allocation, and B2B billing, any major issues or downtime caused by the migration process could be severe and costly. 

This guide walks through the five phases of the mainframe-to-cloud journey and how to build a business case your CFO will sign off on.

Why enterprise commerce teams are accelerating the mainframe-to-cloud journey now

The first thing to recognize is that mainframe technology hasn’t actually stopped working. What's changed is the cost of everything around it: the maintenance, integrations, and market opportunities that often pass by while a change request sits in a queue. 

Five pressures show up again and again in commerce organizations that decide this is the year to migrate:

• Rising cost of ownership: Hardware, licensing, and specialist labor all land on the same budget line, and that line often grows with transaction volume.
• Talent scarcity: Kyndryl's 2025 survey found that 70% of organizations struggle to find the skills required by their modernization efforts. 
• Velocity gap: Mainframes often don’t operate fast enough or flexibly enough to accommodate new technologies and trends, and can cause friction that slows down the desired innovation velocity. 
• Regulatory and security pressure: All requirements in PCI DSS v4.x became mandatory on March 31, 2025, and retrofitting controls like automated log review into decades-old codebases costs more than inheriting them from a platform that already has them.
• AI- and data-readiness: Models need data, and commerce data locked behind batch extracts and nightly jobs won't feed real-time personalization or the agentic shopping surfaces now routing traffic.

None of these forces a full exit. Kyndryl found that 98% of organizations are moving some applications off the mainframe, but the average share dropped from 36% to 28% year over year, and only one respondent out of 500 planned to move everything. Teams are getting choosier about which workloads are worth the effort.

What mainframe-to-cloud means for commerce workloads

For a commerce organization, migration means moving the systems that sit between a shopper's intent and a fulfilled order, as well as the ones that feed them.

In practice, that means:

• Order capture and orchestration
• Pricing and promotions
• Inventory and allocation
• Customer master records
• Loyalty balances
• Accounts receivable logic behind B2B terms

Each system has a different tolerance for downtime and a different set of downstream dependencies. Treating them as one workload is how many migrations slip.

The typical destination isn't always a single cloud vendor, either. Many commerce teams end up with a hybrid solution, such as infrastructure from a hyperscaler, a software-as-as-service (SaaS) commerce platform running the transactional layer, and an integration tier connecting whatever stays put. Cloud migration decisions get easier once you stop looking for one destination and start assigning workloads to the right ones.

There is also a distinction between migration and modernization. Migration moves a workload to different infrastructure. Modernization changes how the workload is built to use what the new infrastructure offers. You can migrate without modernizing, and many teams do, which is why some cloud programs report lower agility a year after cutover.

Can a mainframe be in the cloud? 

A mainframe workload can run in the cloud, either via emulation on cloud infrastructure or via managed services that host an equivalent runtime off-premises. That arrangement changes where the hardware lives without changing the application, so it solves data center costs and hardware refresh cycles while leaving the underlying constraints, including the skills dependency, exactly where they were.

The five phases of the mainframe-to-cloud journey

Smart planning can be what separates programs that finish from programs that stall in year two. An enterprise retailer can use the five phases below as a framework for their mainframe-to-cloud journey, and each one produces an artifact that can be used to support the next phase. 

Phase 1: Assess

Start with a workload inventory that goes deeper than the application catalog. You’ll want to list every mainframe-resident process, upstream and downstream dependencies, and what breaks when it becomes unavailable. Dependency-mapping tools help with the documented half. But you can surface other work in interviews with teams, because static analysis doesn’t always find them.

Commerce introduces other constraints to keep in mind: Which processes touch cardholder data? Which ones have to be completed before the store opening? What's the code freeze window around peak trading, and how many weeks of the year does that leave you?

Then set baselines, because you can't prove value later without a starting point for comparison. Capture metrics order throughput at peak, order-to-fulfillment latency, deployment frequency, cost per transaction, and incident volume by severity. The output of this phase is a ranked workload inventory with a risk score and a measured starting point for each candidate.

Phase 2: Plan

Assign a migration strategy per workload tier rather than picking one for the whole estate. A pricing service with clean interfaces, for example, might be a candidate for replacement. On the other hand, something more complicated, like a batch settlement job with 200 undocumented dependencies, would probably start as a rehost while the team buys time to understand it.

How you sequence the migration of your various workloads follows dependency direction and risk appetite. Move systems that others read from before you move the systems that read them, keep revenue-critical paths for later in the program, and build in at least one full peak season on the new platform before you decommission the old one.

This is also where the business case is written, and governance is set: who signs off on a cutover, who owns rollback, and what threshold triggers one. 

Phase 3: Pilot

Pick a workload that's low-risk but high-learning to migrate first. A regional storefront, a single brand in a multi-brand portfolio, or a B2B customer segment with a defined account list will all teach you more than a peripheral reporting job.

Run this workload in parallel before any production cutover. Dual-write, compare outputs, and let the discrepancies tell you where your understanding of the old system is wrong. For example, home furnishings brand Lulu and Georgia took this approach when they moved more than 40,000 SKUs off their previous platform. 

"Our strategy involved rolling out our system in phases, starting with the basics to gradually introduce traffic, and observing how our entire setup, including middleware and back office, handled incoming orders," says Anis Tayebali, vice president of engineering at Lulu and Georgia.

Measure the pilot against the Phase 1 baselines, not against expectations. Then rewrite the playbook with what you learned, because the first migration always reveals assumptions that were wrong for reasons nobody could have predicted from a dependency map.

Phase 4: Migrate

Execute in the sequence you defined, and resist the pressure to reorder it if a stakeholder wants their system moved first, unless they have a reason that makes sense for the entire business. The cutover window itself deserves more planning than the migration code. Decide how long you can run dual systems, how you'll reconcile orders during migration, and what the customer sees during the transition.

Data integrity is where commerce migrations can get expensive. Order history, loyalty balances, saved payment tokens, and B2B pricing agreements must all arrive intact and reconcilable. Run reconciliation as a gate, not as a post-launch task. 

Customer service, store operations, finance, and the sales team all need to know what's changing and when, and they need it early enough to update their own scripts and processes.

Phase 5: Optimize

Cloud architectures don't remain stable without maintenance. Costs can drift, services get overprovisioned during migration, and the integration tier can accumulate workarounds. Appoint a governance group with a mandate to steer the mainframe-to-cloud journey and continue to look out for these common pitfalls post migration.

Use the benefits the new architecture gives you. Real-time inventory visibility, event streams, and observability data all enable commerce changes that weren't possible before, like accurate delivery promises and faster experimentation on the storefront. Kyndryl found that 80% of organizations changed their modernization strategy over the previous year, with project costs falling as returns rose. 

Optimization is where that kind of course correction gets made.

Report against the business case from Phase 2 on a fixed cadence. Executives who funded the program will ask to see such evidence, and a scorecard that already exists is easier to defend than one assembled under pressure.

For commerce workloads specifically, the destination platform matters as much as the migration approach. Commerce Components by Shopify, for example, packages Shopify's infrastructure, APIs, services, and support in modular form, so a team can move checkout, catalog, or order management independently rather than committing to a full-platform cutover. That maps directly onto the phased sequencing described above.

The four migration strategies: How to choose the right approach

Four approaches for a mainframe-to-cloud migration cover most commerce workloads, and the choice comes down to how much you understand the existing system and how much you want to keep. Cost and timeline vary so widely by estate size that published averages are nearly meaningless, so the table below describes the shape of each approach rather than putting numbers on it.

Replacement is often a particularly viable strategy for commerce brands. Checkout, catalog management, promotions, and storefront rendering present complex challenges that few retailers are likely to overcome by building in-house, and a SaaS platform replaces the entire application rather than relocating it. That's why replacement tends to deliver value fastest for commerce-specific capabilities, while refactor makes more sense for the handful of processes that differentiate the business. 

When Lulu and Georgia migrated to Shopify, for example, they found migration made them even faster and more easily differentiated. 

“Rolling out new programs like promotions or gift card capabilities has become simple and resource-efficient, compared to the traditional approach of building them ourselves,” they said in an interview with us.

Commerce-specific risks that mainframe migration plans often miss

The questions that keep a retailer’s VP of engineering awake aren't about new features and the ability to hop on trends; they're about what happens to orders, peak weekends, customer records, and the integrations that hold the operation together.

Checkout and order continuity during cutover

Orders made during a cutover are the highest-risk objects in the entire program. A shopper who completed payment against the old system and whose order lands in a reconciliation gap becomes a support ticket, and sometimes even a chargeback.

Plan for it explicitly. Define a quiet period when new order capture pauses briefly while in-flight orders drain, or run dual-write with a reconciliation job that reports every mismatch. Decide in advance which system is authoritative for order status during the overlap, and make sure customer service can see both. Then rehearse the rollback and plan ahead.

Peak-traffic readiness on the new platform

A platform that handles your average Tuesday tells you nothing about your Black Friday. Ask any vendor for peak numbers with dates attached, and ask what the service-level agreement (SLA) pays out when they miss.

Shopify, for example, maintains a 99.9% uptime SLA, even during peak periods like Black Friday and Cyber Monday 2025, when Shopify's edge infrastructure peaked at 489 million requests per minute. Treat figures like these as benchmarks any vendor should be able to meet. No matter which platform you're evaluating, the useful comparison is peak throughput on a named date against a contractual uptime commitment.

Customer data integrity and compliance

Data in transit during a migration is still regulated data. GDPR, CCPA, and PCI DSS obligations apply to the copies, staging environments, and temporary systems you spin up along the way. 

PCI DSS matters most for cutover planning. The PCI Security Standards Council published v4.0.1 as the active version of the standard, and its requirements cover any environment that stores, processes, or transmits cardholder data, including the ones you stand up for six weeks and tear down. Scope your migration environments into your assessment from the start. Retrofitting evidence after the fact is where audits get painful.

Customer records deserve the same rigor. Loyalty balances, saved addresses, consent flags, and B2B credit terms all need field-level mapping and a reconciliation report.

Integration continuity with storefronts and third-party systems

Most retailers have accumulated an integration layer nobody fully owns: file drops to a third-party logistics provider (3PL), a nightly sync to an enterprise resource planning platform (ERP), a tax service, a fraud tool, and a handful of point-to-point connections written by people who've left, etc. Cutting over the mainframe without accounting for each of these is how a migration can succeed technically but fail operationally.

Incremental replacement lowers that risk. Commerce Components by Shopify, for example, is built for this situation, letting a team connect modular APIs and services to an existing integration layer one capability at a time and retire legacy components as each replacement proves out.

French menswear brand Serge Blanco did a version of this over a period of five months when they moved off their previous platforms, swapping fragile file-based integrations for API connections to their ERP and order management system (OMS). "Stock levels are now far more reliable," says traffic manager Matthieu De Vaulx. "We still have returns, of course. But mass cancellations are no longer an issue."

Building the business case for the mainframe-to-cloud journey

The financial argument that gets funded almost always involves total cost of ownership (TCO), because it's the one a CFO can most effectively model. Build it from four inputs: 

1. Infrastructure and licensing 
2. Specialist labor 
3. Maintenance share of your engineering capacity
4. The cost of incidents and contingencies 

Note that it’s not uncommon for organizations to undercount the third and ignore the fourth.

The commerce layer provides clearer evidence than the rest of the estate because a platform migration produces a before-and-after for the same business. Apparel brand NYDJ, for example, reduced their total cost of ownership by 65% after moving from their previous platform to Shopify Plus. Serge Blanco similarly reported a 75% to 80% reduction, along with a 5% conversion rate, during peak season. 

Research from a leading independent consulting firm found this result to be broadly true: Shopify's TCO is 33% lower on average than competitors. 

"The platform costs significantly less than our previous solution, while providing many more native capabilities," says Julien Fournier, director of ecommerce at Serge Blanco. 

Three other arguments sit alongside TCO. The first is revenue protection: what you stop losing to downtime, failed checkouts, and oversells during peak. Time to market comes next, and a commerce leader can often size it faster than anyone in IT, because they already know what a delayed promotion costs. Then there's risk, which is where the audit findings, the key-person dependency, and the hardware end-of-life date on someone's calendar all sit.

For payback expectations, Kyndryl's survey remains a useful public benchmark, with reported returns of 288% for modernizing the mainframe and 362% for moving workloads to other platforms. 

Will AI replace the mainframe? What enterprise teams should know

AI won't replace the mainframe, and enterprise teams should plan for mainframe technology to outlast the current hype cycle. What AI does is change the economics on both sides of the decision.

Staying put gets more expensive, because the capability gap widens. Competitors with reachable, real-time commerce data can run personalization and agentic checkout experiences that batch-oriented systems can't feed.

Migrating, however, gets faster, because AI can now handle a meaningful share of the work. McKinsey, for example, found that more than 90% of software teams surveyed use AI for refactoring, modernization, and testing, saving an average of six hours per week. Code comprehension and documentation generation are where it helps most in legacy estates, since the slowest part of any mainframe program is often determining what the code does.

Some mainframes are also absorbing AI rather than being displaced by it. Kyndryl found nearly 90% of organizations have deployed or plan to deploy generative AI on the mainframe itself. Neither trend removes the need for a structured journey with real baselines and a rollback plan.

How to get started: First steps for enterprise teams

The first 90 days set the ceiling on everything that follows. These five steps produce the artifacts that later phases depend on:

1. Convene a cross-functional steering group. Engineering, commerce, finance, security, and store or sales operations all need a role, because each of them owns constraints the others can't see.
2. Commission a workload inventory and dependency map. Include batch schedules, file transfers, and the integrations that weren’t documented during the last replatform.
3. Define success metrics before selecting a strategy. Agree on what you're measuring and what today's number is, so the strategy conversation stays anchored in outcomes rather than architectural preferences.
4. Identify your pilot workload. Look for something contained enough to fail safely and connected enough to teach you about the integration layer.
5. Evaluate platform partners against commerce requirements. Peak throughput, uptime commitments, checkout conversion, B2B capability, and integration depth tell you more than generic infrastructure benchmarks.

On that last step: Shopify offers migration planning, technical account management, and access to an accredited partner network through Shopify Professional Services. Teams that prefer to lead the work internally can find specialists in the partner directory. Either way, the workload inventory from step two is the document that makes those conversations productive.

Teams that aren't ready for a full-platform migration still have options. Commerce Components lets you connect individual capabilities to your existing stack and prove the pattern on one workload before committing to a broader sequence.