Legacy commerce migration to composable – Problem Solution

Legacy eCommerce platforms trap you in slow feature cycles. Composable commerce—swapping out front-end, payment, search, and fulfillment independently—cuts time-to-feature from 12 weeks to 2-3 weeks. Migration typically spans 6-9 months with a phased approach: audit legacy debt, parallel build on modern stack, sync data incrementally, then cut over. Cost: $400K–$800K for enterprise retailers.

The Monolith Problem Nobody Wants to Admit

You're running on something like IBM Commerce, Magento 1, custom JSP templates, or even older SAP Commerce. Here's what's happening:

• A merchandiser wants to change product display logic? Engineering ticket. 4-week sprint.
• Mobile app team needs API changes? That's a middleware layer custom-built by someone who left the company two years ago.
• Inventory real-time sync? You've jury-rigged webhooks into legacy code that was never designed for event streaming.
• Seasonal traffic spike? You pray your monolithic deployment can handle it.

Every business decision becomes a technical project. Every technical project competes for engineering resources that should be building customer value instead.

You're bleeding 20-30% of your engineering capacity just maintaining the status quo.

Why Legacy Platforms Get Stuck

Your monolithic platform has gravity. It pulls resources, decisions, and risk tolerance downward.

Path dependency: You built everything assuming the system would stay monolithic. Custom checkout extensions rely on core payment processing. Search is coupled to product data model. Fulfillment is embedded in the order management system. You can't change one without touching three others.

Technical debt compounds: Five years of feature patches, emergency hotfixes, and "we'll refactor this next quarter" decisions add up. Code that was written for 100K daily users is now handling 500K. The database schema has 47 columns nobody uses. Your API response times have crept from 200ms to 800ms.

Organizational lock-in: Your team has deep domain knowledge of this specific platform. Hiring new developers means 6+ month ramp-up just to understand custom architecture. Retention is hard because developers want modern tech stacks.

Vendor risk: If you're on a proprietary platform (SAP, IBM Commerce, older Magento), vendor pricing escalates predictably. You can't easily switch because migration cost is perceived as "too high."

The math says it's cheaper to stay. The business reality is you're systematically slower than competitors.

Composable Commerce: The Actual Solution

Composable commerce means choosing best-of-breed tools for each layer and connecting them via APIs.

Instead of:

• Monolith that does everything okay

You get:

• Storefront: Hyvä, Next.js, Vue, or Svelte
• Commerce engine: Magento 2, Shopware, BigCommerce, Adobe Commerce
• Search: Elasticsearch, Algolia, or Klevu
• Payment processing: Stripe, Adyen, or Braintree
• Fulfillment: ShipStation, Flexport, or custom WMS
• Content management: Contentful, Sanity, or headless CMS
• Personalization: Segment, mParticle, or marketing platform APIs

Each component:

• Scales independently
• Updates independently
• Uses the best tool for that job
• Replaces easily if better tool emerges

The tradeoff: Your stack is more complex operationally. You manage more integrations. But you gain velocity.

Real Impact: Legacy vs. Composable

We migrated a specialty retailer from legacy Magento 1.14 to Shopware + Hyvä + Algolia. Here's what changed:

Over 12 months, the composable stack was shipping features 4-6x faster.

The Migration Blueprint: Phased Approach

This is how you migrate without blowing up the business.

Phase 1: Audit & Architecture (Weeks 1–4)

What you're doing: Mapping the monster you currently have.

• Document current data models, API contracts, integration points
• Inventory all custom code (How much is truly proprietary vs. reinvented-the-wheel?)
• Calculate technical debt: lines of code per developer, code coverage, deployment frequency
• List all integrations: payment processors, fulfillment systems, tax services, accounting software

Bemeir's question: "If you froze development today and did nothing but technical debt reduction, how long until this system is maintainable again?" If the answer is >6 months, composable migration is justified.

Deliverable: Detailed technical assessment + 5-year ROI model comparing "stay monolithic" vs. "migrate to composable"

Cost: $20K–$40K

Phase 2: Parallel Architecture Build (Weeks 5–16)

What you're doing: Building the new stack in parallel while keeping the old system running.

Pick your commerce engine:

• Shopware: Best for European retailers, excellent developer experience, strong agency ecosystem
• Magento 2/Adobe Commerce: Largest ecosystem, strongest enterprise support, most legacy integrations exist
• BigCommerce: Fast to deploy, good for fast-fashion and specialty retail, hosted solution simplifies ops
• Composable solutions (boilerplates like Medusa, Commerce Layer): Fast to move but requires more custom integration

For most enterprise-scale retailers, we recommend Magento 2 or Shopware because ecosystem maturity means you inherit 70% of integrations you need.

Build storefront independently: While the legacy system keeps humming, build your new storefront (Hyvä, Next.js, or Vue) against temporary mock APIs. This lets frontend and backend teams move in parallel.

Example: One Brooklyn-based apparel company started with the API layer. Their backend team built new Magento 2 REST endpoints that mirrored legacy system data while the front-end team built Hyvä against those endpoints. Zero competition for resources. Zero risk to production.

Cost: $150K–$300K depending on storefront complexity

Phase 3: Data Migration Framework (Weeks 12–20)

What you're doing: Building the ETL pipeline that will move data.

• Customer data: Historic transactions, loyalty data, preferences
• Product data: SKUs, attributes, images, pricing, inventory
• Order history: For analytics, chargebacks, warranty/return claims
• Content: Product descriptions, category hierarchies, SEO metadata

You don't migrate everything at once. Run a pilot:

1. Choose a category with low order volume (new experimental products, seasonal items)
2. Full migration: all customer, product, order data for that category
3. Validate: audit data quality, test order flows, verify inventory sync
4. Iterate: fix mapping issues, optimize transformation logic

Pro move: Keep the legacy system as the master of truth during migration. Your ETL is one-way (legacy → new). If something breaks, you roll back. After 90 days of parallel operation, you're confident enough to cut over.

Cost: $80K–$150K depending on data complexity

Phase 4: API Sync & Testing (Weeks 18–28)

What you're doing: Running both systems simultaneously, one as primary.

Legacy system gets all real traffic. New system shadows that traffic—processes the same orders, syncs the same inventory, handles the same customers—but nobody's using the output yet.

This is where you catch integration bugs:

• Does inventory sync work in real time?
• Do payment processors integrate correctly?
• Is order status flowing to fulfillment correctly?
• Are loyalty/rewards calculations identical?

Run this for 4–6 weeks. Fix issues as they surface. Your team gets comfortable with the new system without risk.

Cost: Included in implementation, mainly engineering time

Phase 5: Traffic Cutover & Monitoring (Weeks 28–32)

Now comes the moment. You switch 5% of traffic to the new system.

• Week 1: 5% of traffic → new system. Monitor like a hawk. Are checkout abandonment rates identical? Is page load speed better or worse? Are there data sync issues?
• Week 2: 25% of traffic
• Week 3: 50% of traffic
• Week 4: 100% of traffic

If catastrophic bugs emerge, you have a kill switch. Traffic goes back to legacy system.

During this window, maintain the legacy system. Keep it patched. Don't decommission it yet.

Cost: Primarily monitoring and incident response, ~$40K

Phase 6: Legacy System Decommission (Weeks 32+)

Only after 60 days of 100% traffic on the new system—and only after you've confirmed all data is syncing correctly—do you kill the old system.

Usually happens 3–4 months post-cutover. Some companies keep the legacy system in archive mode (read-only) for 6+ months for compliance or dispute resolution.

Cost: ~$10K to archive and document

Real Timeline & Budget

Total duration: 6–9 months
Total cost: $400K–$800K for enterprise retailer (50+ SKUs, multi-location, complex integrations)

Breakdown:

• Architecture & assessment: $20K–$40K
• New platform setup & integration: $150K–$300K
• Data migration framework: $80K–$150K
• Testing & cutover: $100K–$200K
• Monitoring & stabilization: $40K–$80K
• Contingency: 15% (~$80K–$150K)

If you have 2–3 critical integrations (payment, fulfillment, accounting), add $50K–$100K per integration for custom adapter development.

The Bemeir team typically sees costs skew high when:

• Legacy system has undocumented custom code (add 4–8 weeks)
• Multiple fulfillment integrations exist (add 2–3 weeks per integration)
• Custom payment processing (add 6–10 weeks)
• Your data model is heavily denormalized (add 3–4 weeks for ETL)

Avoiding the Migration Trap: What Actually Kills Projects

Trap 1: "We'll migrate and clean up the data afterward"

No. You won't. Data quality issues compound. Migrate clean data first, validate it, then flip the switch. We've seen projects add 8 weeks because bad data made it into production and nobody caught it until order fulfillment started breaking.

Trap 2: "Let's use this as an opportunity to rebuild everything"

Resist this. You're not redesigning the business. You're modernizing the technical foundation. Big Bang rewrites during migration are how projects die. Build 80% of functionality parallel, then move. Leave the last 20% for post-cutover iteration.

Trap 3: "We can decommission the legacy system immediately"

Keep it around for 60–90 days minimum. You will find bugs. You will need to retrieve data. You will have questions about old transactions. A live legacy system as reference is worth its weight in gold.

Trap 4: "The new system is fast enough, performance optimization can wait"

Performance is 10x harder to fix post-launch than pre-launch. Solve it during Phase 4 (API sync & testing) when traffic is shadowed. Don't discover your new storefront does 1.8s LCP under real load after cutover.

Trap 5: "Our team can handle this + ongoing business"

You can't. Allocate a dedicated migration team (4–6 engineers) separate from feature development. Running the business and migrating the business requires two teams.

Why We Recommend Magento 2 or Shopware for Enterprise

Magento 2:

• Largest ecosystem (300+ agencies, 1000s of extensions)
• Strong for multi-location, B2B, and complex fulfillment
• Adobe Commerce (SaaS version) removes infrastructure concerns
• Existing integration libraries for most ERP/WMS systems

Shopware:

• Cleaner codebase than Magento 2 (younger, learned from M2's mistakes)
• Exceptional developer experience (TypeScript, modern PHP)
• Growing ecosystem, particularly strong in Europe
• Lower operational overhead than Adobe Commerce

Don't choose: BigCommerce if you have complex integrations (their API is good but ecosystem is smaller). Homegrown solutions if you don't have a dedicated 10-person platform team (you're buying technical debt, not solving it).

Typical Blockers & How to Overcome Them

Blocker: "Our legacy system has custom logic that's hardcoded and undocumented"

Solution: Build an adapter layer. Your new system doesn't need to replicate weird legacy logic. Build a translation layer that maps legacy business rules to new system logic. This is often faster than trying to reverse-engineer spaghetti code.

Blocker: "We have 10+ integrations (payment, fulfillment, tax, accounting, loyalty)"

Solution: Prioritize. Migrate the 3 most critical integrations in Phase 2. Others can be built post-cutover if needed. You're not required to have every system connected on day one—just the ones that block orders.

Blocker: "Our team doesn't know modern tech stacks"

Solution: Hire externally, train internally. We typically embed 1–2 senior engineers for 60 days post-cutover to mentor your team. Budget $40K–$80K for this. It's the best money you'll spend because it accelerates your team's ability to own the new system.

Blocker: "CEO is terrified of downtime"

Solution: Run parallel systems for 60 days. New system gets shadowed traffic (processes orders without customers seeing output). After 60 days of zero issues, traffic cutover is low-risk. Downtime becomes optional.