IT Modernization Roadmap: Practical Retail Guide (2026)

As enterprise commerce stacks evolve, new systems are often joined to existing infrastructure while legacy technology remains in place. That infrastructure can span ecommerce, point-of-sale (POS), enterprise resource planning (ERP), customer and product data, payments, and other parts of the business. IT modernization starts with prioritizing which of those systems should change, which should remain, and how to sequence those changes. 

An estimated 90% of organizations are undergoing some form of digital transformation, including systems modernization, according to McKinsey. For commerce and IT leaders, that can mean managing multiple modernization projects across an interconnected commerce stack.

This IT modernization roadmap explains how to assess a commerce technology stack, choose among modernization approaches, sequence the work into five phases, and evaluate build-versus-buy decisions.

What is an IT modernization roadmap in commerce?

In commerce, an IT modernization roadmap is a sequenced plan for changing or upgrading the technology, applications, and infrastructure that support commerce operations. It defines what will change, what will remain, and the order in which modernization efforts will be implemented.

Modernization projects can vary in scope and include:

• Migrating to a new ecommerce platform
• Unifying channels, such as ecommerce and POS, on a single back end
• Modernizing or changing an ERP system
• Moving to a headless architecture
• Changing individual applications while retaining other parts of the technology stack

An IT modernization roadmap defines the scope and sequence of these changes by answering five digital transformation questions:

1. What are we changing?
2. What is staying the same?
3. In what order will the changes happen?
4. What milestones need to be achieved, and by when?
5. How will we measure success in the short and long term?

IT modernization vs. application modernization

IT modernization and application modernization differ primarily in scope. IT modernization is the broader program and can cover enterprise architecture, infrastructure, platforms, integrations, data flows, and operating processes. Application modernization focuses on an individual software system or application within that broader program.

For example, replatforming an entire commerce platform to unify channels is an IT modernization initiative because the program spans multiple parts of the commerce stack. Moving a specific function, such as a loyalty program, from a point solution to a commerce platform add-on is an application modernization project.

Multiple application modernization initiatives can sit within a larger IT modernization roadmap.

The table below lists some more examples of each category.

IT modernization strategy vs. roadmap

An IT modernization strategy establishes what a business wants its future commerce architecture to do, along with project constraints such as cost, budget, and scope. An IT modernization roadmap turns that strategy into sequenced work, defining when systems and applications will change and how the work will progress. In other words, the strategy sets the direction, but the roadmap organizes the work to get there.

When forming an IT modernization strategy, define the architectural decisions that will shape the roadmap:

• Whether the business will consolidate commerce functions or channels
• Whether to migrate or upgrade to a composable architecture
• Which systems will remain systems of record
• Which custom capabilities, if any, the business will retain
• Which integrations will change or require updates
• How the modernization will address technical debt

Consider a retailer that plans to retain its ERP as the system of record while replacing a legacy ecommerce platform and reducing custom storefront infrastructure. Those decisions form the strategy. The roadmap then sequences the platform migration, ERP integration work, storefront transition, testing, and rollout.

How Sanjo modernized commerce while retaining their ERP

Sanjo, a heritage footwear brand, faced constraints as their business expanded. Their existing commerce platform struggled to integrate with their ERP, while the business wanted to support international growth.

“The old platform was a major challenge. We wanted to expand internationally and needed an intuitive solution. Managing the store was complex, adding new features was a nightmare, and technical support was lacking,” said Sofia Camarinha, head of marketing and ecommerce at Sanjo.

Sanjo modernized their commerce platform by migrating to Shopify in five months and integrating the new platform with their existing ERP. That choice shows how a modernization strategy can preserve some systems while changing others, with the roadmap sequencing the platform migration, integration work, and operational changes.

Using Shopify Markets, Sanjo eliminated the need for multiple stores while tailoring their shopping experience by country and language, including localized content, pricing, and taxes. They used Shopify Flow to automate internal processes, while improved ERP integration enabled real-time inventory synchronization between online and physical stores. Sanjo reported a 50% reduction in logistics time.

“With Shopify… we created an exclusive catalog for customers, set differentiated pricing, and applied automatic discounts for our partners. Plus, ERP integration optimized order processing, making our B2B channel much more efficient,” said Sofia.

Sanjo reported an initial 10% growth in their B2B channel following the modernization.

The Five Rs of IT modernization in commerce

The Five Rs provide a framework for deciding how to treat individual systems and applications within an IT modernization roadmap. They adapt the Five Rs of application modernization to a commerce technology stack: rehost, refactor, replatform, replace, or retire.

These approaches help teams decide what should move, change, be replaced, or be removed as they build the roadmap.

Rehost

Rehosting moves an application or workload to a new infrastructure environment with minimal changes to the application itself. The primary change is where the application runs, not what it does.

For example, a retailer might move its existing ERP from on-premises infrastructure to a hosted environment while retaining the same ERP, business logic, and core functionality. 

Refactor

Refactoring changes an application's code or architecture while preserving its core function.

For example, a retailer might refactor a custom integration between its commerce platform and ERP, changing how the systems exchange data without replacing either system.

Replatform

Replatforming moves commerce operations or capabilities from one platform to another.

During an ecommerce platform migration, for example, a retailer might move commerce operations from a legacy ecommerce platform to Shopify while continuing to connect the new platform to an existing ERP, product information management system (PIM), or other system that is being retained.

That means replatforming can change one major part of the ecommerce architecture while other connected systems remain in place.

Replace

Replacement retires an existing application and introduces another product, service, or platform to perform its function.

For example, a legacy commerce platform might rely on custom-written applications for specific functionality. During platform migration, the retailer could replace one of those custom applications with functionality provided by the new commerce platform, a third-party app, or another application in the new technology stack.

Retire

Retiring removes a system or application without replacing it with another application that serves the same purpose.

For example, consolidating commerce operations into a single platform might eliminate the need for an application previously used to transfer or reconcile information between separate systems. The IT modernization roadmap can identify that application for retirement after the systems and processes that depend on it have changed.

The expanded Seven Rs of IT modernization

Expanded modernization frameworks add additional treatments for applications and systems beyond moving, modifying, replacing, or retiring them.

For a commerce technology stack, the expanded seven-R framework adds two options to the five outlined above: rebuild or retain.

Rebuild

Rebuilding means recreating a capability for the new architecture rather than incrementally changing the existing solution. For example, a business moving to headless commerce might fully rebuild a custom storefront for the new architecture while using a commerce platform for back-end functionality.

Retain

Retaining means leaving an application in its existing environment without changing it during the current modernization period. For example, a retailer might retain its ERP as its system of record while migrating its ecommerce platform and updating the integration between the two systems.

Retaining a system doesn't take modernization off the table entirely. Retention can be temporary while changes elsewhere in the technology stack are prioritized.

Together, the seven approaches provide different options for systems and capabilities within the modernization roadmap:

An IT modernization roadmap doesn't need to apply one approach to the entire commerce stack. Different approaches can apply to an individual platform, application, integration, or piece of custom code within a larger modernization roadmap. 

A business might replatform its ecommerce operations while retaining its ERP, refactoring integrations, replacing custom applications, and retiring systems the target architecture no longer requires.

How Groupe Marcelle's modernization shows a commerce roadmap in practice

Groupe Marcelle operates four cosmetics brands that previously ran across separate commerce environments. Their modernization provides an example of how decisions about different parts of a technology stack can combine into a broader roadmap.

The business consolidated four storefronts into a single Shopify instance while developing a new integration with their ERP. ERP data synchronized inventory and sales in real time, while Groupe Marcelle brought shipping management into the new commerce environment with Machool.

Viewed through the modernization framework, the program combined multiple approaches rather than applying one treatment across the stack. Groupe Marcelle replatformed their storefronts, refactored their ERP integration, and added capabilities through Shopify's ecosystem, including:

• Klaviyo for targeted marketing automation
• Recharge for product subscriptions
• Rebuy for personalized recommendations
• Yotpo for reviews and user-generated content

The Shopify migration was followed by 32% sales growth and a 26% increase in order volume during November and December compared with the previous year. Conversion rates improved by 6%.

“The new platform is a fundamental pillar of our growth in Canada and the United States,” said Philippe Proulx, principal director of operational excellence at Groupe Marcelle.

How to build an IT modernization roadmap: A phased approach for commerce

Once the modernization strategy and new architecture are defined, the roadmap is used to turn those decisions into sequenced work. It identifies what changes first, what depends on those changes, what the business will deliver at each stage, and how it will measure progress.

The following five phases provide a structure for moving from the current-state assessment through implementation and post-launch optimization. Together, they move the roadmap from planning to implementation: each phase creates outputs that are used as inputs for the next.

Phase 1: Assess the current architecture

Start by documenting the current commerce architecture. Inventory the systems, applications, and infrastructure within the scope of modernization, including:

• Ecommerce platform
• Storefronts
• POS
• ERP
• Order management
• Product information management (PIM)
• Payments
• Fulfillment systems
• Custom applications
• APIs
• Middleware
• Integrations

Map the major connections and dependencies between these systems. Identify which systems own product, inventory, order, customer, pricing, and other data used across commerce operations.

Document known constraints for each system, including existing vendor contracts, custom functionality, integration requirements, regulatory or security requirements, and business processes that depend on it. Where relevant, capture baseline measures tied to the modernization goals so you can track progress over time.

Output: Current-state architecture documentation, a system and integration inventory, a dependency map, documented modernization requirements, and relevant baseline measures

Phase 2: Define the target state and prioritize work

Use the assessment to define the desired state of each system within the modernization scope. Assign a modernization treatment to each in-scope platform, application, integration, or piece of custom functionality, and identify which systems will remain or become systems of record.

When multiple systems require modernization, prioritize and sequence projects according to factors such as:

• Business requirements
• Expected time to value or impact
• Technical dependencies
• Migration complexity
• Cost and resource constraints

For example, a retailer with both a legacy ERP and legacy commerce platform could choose to migrate the commerce platform while retaining the ERP as its system of record. The roadmap would then account for the platform migration and the integration work required to connect the retained ERP to the new commerce environment.

Darche, an outdoor equipment supplier with a B2B business, provides an example of this type of modernization sequence. Their legacy online store required external developers to make changes, while limited integration between their commerce platform and ERP affected inventory visibility and stock management.

Darche migrated their commerce operations to Shopify and connected the existing ERP with a new integration, providing real-time inventory visibility across online and offline channels. B2B customers could see available stock before ordering and use self-service capabilities including company profiles, custom catalogs, and personalized pricing. Following the migration, Darche reported a threefold increase in B2B sales and a 59% increase in annual web traffic.

During this phase, brands should identify the internal and external resources involved in implementation and involve them in defining the target state. For businesses using Shopify, this can include Shopify Professional Services or Shopify Plus Partners as part of the migration and implementation plan. Their responsibilities, dependencies, timelines, and deliverables can then be incorporated into the roadmap.

Output: Target-state architecture, prioritized modernization projects, project sequence, resource requirements, and criteria for evaluating the next phase

Phase 3: Testing and validation

Before full implementation, a roadmap can include a proof of concept, pilot, or minimum viable product (MVP) to test a specific part of the target architecture. The appropriate method depends on what the business needs to validate before proceeding.

For example, a retailer could build and test one storefront on a new commerce platform to validate its core commerce functions and required integrations before a broader rollout. The validation scope should correspond to the requirements and risks identified during assessment rather than reproduce every modernization workstream.

Define the criteria the proof of concept (POC), pilot, or MVP must meet before testing begins so the results can inform the next phase of the roadmap. These might include whether required integrations work as expected, data is accurate, and the tested experience meets the business requirements defined earlier.

Output: Implemented validation scope, test results, integration assessment, identified migration issues, and a decision about changes required before broader implementation

Phase 4: Implement and roll out

After validating the approach, carry out the migration and modernization workstreams defined in the roadmap. For a commerce platform migration, implementation can include:

• Platform configuration
• Integrations
• Data migration
• Storefront development
• Add-on and third-party app configuration
• Testing and validation
• Operational readiness
• Change management and training
• Rollout and cutover activities

The roadmap should assign milestones, dependencies, responsibilities, and rollout requirements to these workstreams. When external implementation resources are involved, including Shopify Professional Services or Shopify Plus Partners where relevant, their deliverables and dependencies should be included in the same plan.

Output: Completed migration workstreams, tested integrations, validated data, launch-readiness documentation, and rollout or cutover plans

Phase 5: Measure and optimize

After launch, compare modernization outcomes against objectives and key performance indicators (KPIs) defined earlier in the roadmap. Use those results to identify the next modernization priorities.

Measures can include:

• Conversion rate
• Average order value (AOV)
• Customer retention and satisfaction
• Reorder frequency
• Revenue growth
• Platform and storefront performance
• Order-processing time or inventory accuracy
• Deployment or release frequency
• Technology operating costs or total cost of ownership (TCO)

Which measures are most relevant depends on your modernization goals. A roadmap focused on commerce growth may emphasize conversion, revenue, and customer measures, while one focused on reducing technology complexity may track operating costs, release cycles, integrations, and platform performance.

Review integration behavior, platform performance, operational issues, customizations, and systems retained for later modernization. Those findings can inform the backlog and the next set of modernization priorities, keeping the roadmap current as needs and results change.

Output: Post-launch performance review, prioritized backlog, KPI reporting plan, and next modernization work

Build-versus-buy decisions in an IT modernization roadmap

An IT modernization roadmap can include decisions about which capabilities to build through custom development and which to buy through platforms, applications, middleware, or other vendor-provided technology. In commerce, build versus buy is an architecture decision that can be made for each function or capability rather than across the entire technology stack.

Each decision should account for what the business will own and maintain after implementation.

When to consider building

Building gives a business direct control over implementation and lets its teams develop functionality around requirements that available platforms or products don't meet.

That control also comes with ongoing responsibilities, including application development, hosting or infrastructure where applicable, testing, security, observability, upgrades, and the engineering resources required to operate and maintain the capability.

A custom integration with a highly configured ERP is one example. A business might retain the ERP during modernization but build an integration between it and the new commerce platform when its requirements aren't met by available integrations.

A headless storefront is another example. Headless commerce separates the front end from the commerce back end, allowing the storefront to be developed and deployed separately. Shopify supports this architecture through Hydrogen, its React-based headless commerce stack, and Oxygen, its hosting environment for Hydrogen storefronts.

With headless, brands can adopt a build-and-buy combination. The business can build one or more storefronts while using a commerce platform for back-end commerce capabilities.

When to consider buying

Buying means adopting a platform or software product for capabilities the business has decided not to build and operate internally.

Evaluate whether the product meets business and technical requirements, how it integrates with retained systems, what can be customized, which responsibilities remain with the vendor, and what constraints, if any, it adds.

The cost comparison should also account for the responsibilities associated with each option. For a custom commerce back end, those inputs can include development, infrastructure, security, maintenance, testing, upgrades, and internal engineering resources. A platform can take on some of those responsibilities, alongside licensing and other platform costs.

Evaluate build versus buy capability by capability

Build versus buy doesn't need to be a stack-wide decision. A business can evaluate an individual platform, application, integration, storefront component, or other capability separately.

For each capability, document:

• Business requirements
• Technical requirements for each option
• Existing internal capabilities and costs
• Development and maintenance responsibilities
• Integrations and system dependencies
• Implementation requirements
• Ongoing ownership responsibilities
• Available total cost inputs

Document the selected approach and its rationale in the IT modernization roadmap. A business can also retain a custom capability during one modernization phase and revisit its build-versus-buy decision in a later phase.

Build and buy within a commerce platform

A business can use a commerce platform for core commerce infrastructure while retaining custom applications, integrations, or storefront components where its requirements call for them.

With Shopify, for example, a business can use platform capabilities and APIs while integrating retained systems and custom technology. For headless implementations, businesses can also build a custom storefront while using Shopify for the commerce back end. Shopify's modular enterprise capabilities also let businesses adopt specific components, such as checkout, storefront, or Shop Pay, without requiring a full platform migration.

An internal build comparison should account for the security, compliance, availability, infrastructure, and operational responsibilities that the business would otherwise need to address. Shopify provides platform capabilities that include:

• Level 1 PCI DSS compliance
• SOC 2 Type II and SOC 3 
• 99.9% uptime
• Global infrastructure

These responsibilities and platform capabilities can become inputs in the build-versus-buy analysis rather than being treated separately from the architecture decision.

How Ruggable combined build and buy in their modernization roadmap

Ruggable, known for washable rugs, adopted Shopify as their headless ecommerce platform as the business expanded into eight international markets. Their implementation shows how both build and buy decisions can coexist within a broader modernization program.

Ruggable built a custom headless storefront while using Shopify as their centralized commerce back end. This gave their team control over the storefront experience while Shopify handled other commerce capabilities.

“There’s a big difference between build versus buy,” said Daniel Graupensperger, director of product management at Ruggable. “If you’re building it all yourselves, that’s going to slow things down. You’re limited by the resources that you have. We’ve been able to partner with Shopify, and they’ve been able to do a lot of the building for us.”

Viewed through an IT modernization roadmap, Ruggable's architecture combines both sides of the build-versus-buy decision: custom development where the business retained control over their storefront experience, and platform capabilities for parts of the commerce stack it chose not to build independently.

Common IT modernization priorities for commerce

IT modernization can apply to technology across the business, but a commerce roadmap needs to account for the systems that support selling and the connections between them. Four commerce architecture changes illustrate how the roadmap framework can apply.

Replatforming legacy ecommerce

Replatforming changes the core commerce platform while potentially retaining other systems around it. During the migration, functionality can also move from custom applications or other systems to capabilities provided by the new platform or its app ecosystem.

The roadmap should account for storefronts, commerce data, integrations, checkout and payments, order flows, SEO requirements, and the systems that will remain in place after migration. For businesses moving to Shopify, the migration plan can also include support from Shopify Professional Services or specialized migration partners where needed.

Unifying POS and ecommerce

When POS and ecommerce operate on separate technology, modernization can include moving both channels onto a shared commerce platform.

The roadmap should identify where products, inventory, customers, orders, and other shared commerce data will live and how store and ecommerce workflows will interact. With Shopify, for example, retailers can run POS and ecommerce from the same commerce back end, so product, inventory, customer, and order data can be shared across channels.

Improving ERP integration

Modernizing commerce doesn't necessarily require replacing the ERP. A roadmap can instead retain the ERP while changing the commerce platform and the integration between them.

The roadmap should define how the new commerce platform will exchange product, inventory, order, fulfillment, customer, pricing, and other required data with the retained ERP. Document which system is authoritative for each data domain, how and when data moves between systems, and what should happen if synchronization fails.

Transitioning to headless commerce

In a 2024 survey of more than 1,000 business and IT leaders, WP Engine found that 73% of respondents had adopted headless architecture. Headless commerce separates the storefront from the commerce back end, with the two communicating through APIs.

A transition to headless changes both the storefront architecture and the responsibilities associated with building and operating it. The roadmap should identify ownership of storefront development, deployment, integrations, testing, and ongoing development alongside any changes to the commerce platform itself.

The roadmap should also identify which back-end systems and capabilities will remain in place and how the new storefront will connect to them.

IT modernization mistakes to avoid

An IT modernization roadmap should account for more than the technology being changed. It also needs to address workflows between systems, ownership, operational changes, and how the business will measure success. Below are some potential pitfalls to look out for.

Skipping assessment and strategy

Without a documented view of the existing commerce stack, planning can begin without a complete picture of integrations, data flows, custom functionality, or the business processes that rely on each system. Teams can also move forward without connecting the modernization work to the business goals it should support.

That can lead to target-state decisions being made without a clear view of dependencies, priorities, or what the modernization is meant to achieve.

Treating modernization as a one-time project

Not every system needs to change during the same roadmap period. Some applications may be deliberately retained and reconsidered later, while newly deployed technology will still require ownership, measurement, and ongoing attention after launch.

Include post-launch ownership, measurement, and a backlog for retained systems and future modernization work in the roadmap. Use the results from post-launch measurement to help prioritize what comes next.

Underestimating integration complexity

Commerce platforms can exchange data with ERP, POS, order management, PIM, fulfillment, payments, customer relationship management (CRM), and other applications. Changes in the commerce platform can affect many systems and interfaces beyond the storefront itself.

That makes it important to identify dependencies early and account for how changes to one system could affect others throughout the roadmap.

Neglecting change management

Commerce modernization can change workflows across ecommerce, retail, customer support, merchandising, operations, and technical teams. Change management activities account for how those technology changes affect the people and processes that use them. Teams may need to learn new processes, responsibilities, and systems before launch. 

Document affected workflows and their owners, along with required documentation, training, operational readiness, and launch activities. Build this work into implementation rather than treating change management as a separate workstream.

Measuring the wrong outcomes

Modernization KPIs should trace back to the reasons for the project and the business outcomes it is intended to support. A program addressing reliability should measure reliability, while one intended to change development and deployment processes should measure those processes.

For a commerce replatforming, define and baseline measures that reflect the project's stated objectives before migration.

The roadmap should establish these measures before implementation so the business can compare pre- and post-launch performance against the goals established during assessment.

Put your IT modernization roadmap into action

Before moving from planning to implementation, confirm that the IT modernization roadmap defines:

• Current-state architecture
• Target architecture
• Modernization treatment for each in-scope system
• Integration and system dependencies
• Phased migration sequence
• Ownership for each workstream
• Measures tied to the program's objectives

For businesses considering a commerce replatform as part of their roadmap, Shopify provides migration resources for planning the transition from an existing platform and evaluating the requirements for moving to Shopify.

If Shopify is part of your target architecture, talk to a Shopify expert about your migration requirements and path forward.