Why Organisations Are Moving
Platform migrations are painful, expensive, and risky. Nobody undertakes one for fun. When an enterprise decides to re-platform, it is because the cost of staying has exceeded the cost of moving.
The reasons we hear most often fall into three categories.
Total cost of ownership has become unsustainable. Licence fees, mandatory upgrades, premium support tiers, and the specialised (and expensive) development talent required to maintain certain platforms have pushed annual costs to a point where the business case for change becomes obvious. This is particularly common with SAP Commerce (formerly Hybris) and Salesforce Commerce Cloud, where ongoing costs can escalate significantly after the initial implementation.
The platform cannot keep pace with the business. Organisations evolve faster than monolithic platforms. New sales channels, new pricing models, new geographies, new integration requirements – each one becomes a multi-month development effort on a rigid platform. At some point, the platform stops enabling growth and starts constraining it.
Performance and developer experience have deteriorated. Legacy implementations accumulate technical debt. Page load times creep upward. Deployments become risky multi-hour events. Developer productivity drops as the codebase becomes harder to work with. The site that was state-of-the-art five years ago is now a liability.
What Makes Intershop Different
Intershop’s architecture is fundamentally different from the platforms most organisations are migrating from.
Composable by design. Intershop was rebuilt around a composable, API-first architecture. The commerce engine exposes its capabilities through well-documented REST APIs, allowing the frontend, integrations, and business logic to be developed and deployed independently. This is not a bolt-on headless capability – it is how the platform was designed to work.
True B2B capabilities. Most commerce platforms were built for B2C and later added B2B features. Intershop was built for B2B from the ground up. Complex pricing (contract pricing, tiered pricing, customer-specific pricing), approval workflows, punchout catalogues, multi-organisation hierarchies, and self-service portals are native capabilities, not plugins or workarounds.
Operational independence. Intershop can be deployed on-premise, in a private cloud, or as a managed service. You are not locked into a vendor’s cloud infrastructure or forced into a specific hosting arrangement. This matters for organisations with data residency requirements or existing infrastructure investments.
The Migration Process: Honest Expectations
Every migration is different, but the process follows a consistent structure. Here is what to expect.
Phase 1: Discovery and Gap Analysis (3-4 weeks)
Before writing a line of code, we map the current platform’s functionality against Intershop’s capabilities. This is not a checkbox exercise. We document every integration, every customisation, every business rule, and every workflow that the current platform supports.
The output is a gap analysis that identifies three categories:
- Direct equivalents. Functionality that maps cleanly to Intershop’s native capabilities. This is typically 60-70% of the feature set.
- Architecture changes. Functionality that exists in Intershop but works differently. This requires design decisions, not custom development.
- Custom development. Functionality that must be built. This is where honest scoping matters most.
Phase 2: Architecture and Design (2-3 weeks)
Based on the gap analysis, we design the target architecture. This includes the frontend approach (headless PWA vs. server-rendered), the integration architecture (which systems connect, how data flows, what the API contracts look like), and the data migration strategy.
A critical decision at this stage is the frontend architecture. Our recommendation – and our area of deepest expertise – is a headless PWA built on modern JavaScript frameworks, connected to Intershop’s commerce APIs. This approach delivers the best performance, the most flexibility for future changes, and the cleanest separation of concerns.
Phase 3: Implementation (8-16 weeks)
With our E3 accelerator (Exascale Ecommerce Engine), the core commerce functionality – product catalogue, search, cart, checkout, account management, order history – is operational within weeks rather than months. E3 provides a production-ready Intershop PWA that serves as the foundation for the implementation.
The remaining time is spent on:
- Custom frontend development for brand-specific design and UX requirements
- Integration development for ERP, PIM, OMS, and other backend systems
- Data migration (product catalogues, customer accounts, order history)
- Business rule implementation (pricing, promotions, approval workflows)
- Performance testing and optimisation
Phase 4: Testing and Launch (2-4 weeks)
Before go-live, we run comprehensive testing across functional requirements, integration points, performance benchmarks, and SEO preservation. SEO migration is a particular focus – poorly executed URL migrations can cause 30-40% traffic loss. We implement proper redirect strategies and verify that search rankings are preserved.
Total Timeline
A typical enterprise migration runs 16 to 24 weeks from kickoff to go-live. This is faster than most organisations expect, and significantly faster than the 9-18 month timelines that are common with other platform migrations. The difference is our E3 accelerator and our focused Intershop expertise – we are not learning the platform on your project.
What to Watch Out For
Based on dozens of migrations, here are the areas where projects most commonly run into trouble.
Underestimating integration complexity. The commerce platform is rarely the hardest part of a migration. The integrations – ERP, PIM, OMS, payment gateways, tax engines, shipping providers – are where complexity lives. Every integration must be mapped, designed, developed, and tested. Budget time and resources accordingly.
Trying to replicate the old platform exactly. The most expensive migration is one that rebuilds every feature and customisation from the previous platform without questioning whether they are still needed. A platform migration is an opportunity to simplify. Take it.
Neglecting SEO migration. URL structures, metadata, canonical tags, sitemaps, and redirect chains must be planned before development begins, not retrofitted after launch. We have seen organisations lose months of organic traffic because SEO migration was treated as an afterthought.
Insufficient data cleanup. Product data, customer data, and order history from legacy platforms are rarely clean. Migrating dirty data into a new platform creates problems that are harder to fix after launch. Invest in data cleanup before migration, not after.
Is Intershop Right for Your Migration?
Intershop is the right destination if your organisation has:
- Complex B2B commerce requirements (contract pricing, approval workflows, multi-org hierarchies)
- The need for a composable, API-first architecture that supports headless frontends
- Requirements for on-premise or private cloud deployment
- A product catalogue and business model that will grow and evolve
If your requirements are straightforward B2C with simple pricing and standard checkout flows, a lighter platform may be a better fit. We will tell you that upfront.
If Intershop is the right fit, get in touch. We will review your current platform, scope the migration, and give you an honest assessment of timeline and investment.
