
Midsize specialty retailer (12 warehouses, $45M annual revenue) migrated from Magento 2 + Luma to Hyvä over 6 months. Results: 62% faster feature delivery, 71% reduction in inventory API latency (12 min to 90 sec), 280ms page load improvement, 8.2% conversion rate lift. Cost: $520K upfront, recovered in 18 months through engineering efficiency gains.
The Company & The Problem
Company: Specialty apparel retailer (fictional composite, representing typical Bemeir enterprise clients)
Business context:
- Founded 2012, headquartered Brooklyn, NY
- 12 fulfillment centers across US (East, Central, West regions)
- 8,400 SKUs across seasonal collections
- $45M annual revenue, 600K monthly customers
- 8-person engineering team
- 4-person fulfillment operations team
Technology stack (before migration):
- Magento 2.4.2 (stuck on version—no upgrades in 2 years)
- Luma theme with 47 custom layout XML overrides
- 23 custom extensions (payment, fulfillment, loyalty, etc.)
- Custom inventory management (sync with WMS every 15 minutes)
- Monolithic architecture, single deployment pipeline
The pain points:
"A simple product filter change took 8 weeks. Marketing wanted to test dynamic pricing by region. Our backend was coupled so tightly that changing checkout logic risked breaking inventory sync. We were shipping features 10x slower than we should." — CTO
Business impact:
- Feature requests queued 6+ months
- Inventory visibility lag (15-minute old data on storefronts)
- Seasonal traffic spikes caused framework cascades (vertical scaling only)
- Team morale: developers leaving because they wanted modern tech stacks
Decision point: Either modernize the platform or accept 18-24 month feature backlogs forever.
Why They Chose Hyvä (Not PWA Studio, Not Staying on Luma)
The company evaluated three options:
Option 1: Stay on Luma, Upgrade Magento Core
- Cost: $150K–$200K (upgrade + retesting)
- Timeline: 8–10 weeks
- Benefit: Stability
- Downside: Solves nothing. Still monolithic, still slow feature cycles
Verdict: Buying time, not solving problems.
Option 2: Migrate to PWA Studio (Headless)
- Cost: $600K–$800K
- Timeline: 24–28 weeks
- Infrastructure: Separate Node.js deployment, double the DevOps
- Benefit: Omnichannel (mobile app, kiosk, marketplace all possible)
- Downside: Overkill for single-storefront retailer. Extra operational complexity.
Verdict: Too much complexity for their current needs. Future-proof, but expensive.
Option 3: Migrate to Hyvä
- Cost: $420K–$520K
- Timeline: 14–16 weeks
- Infrastructure: Minimal (stays on Magento 2, lighter frontend)
- Benefit: 4–6x faster feature delivery, decoupled front-end/back-end
- Downside: Newer platform (though they did their homework and found 200+ enterprise deployments)
Winner: Hyvä. The right balance of modernization, timeline, and cost.
They hired Bemeir to lead implementation.
Pre-Implementation: The Audit
Week 1-2: Technical assessment
The Bemeir team spent two weeks understanding the legacy system:
-
Codebase audit: 47 custom layout overrides, 23 extensions. About 30% was duplicate functionality that Hyvä provides natively. 40% was technical debt that should be deleted. 30% was genuine business logic worth migrating.
-
Performance baseline:
- Product page LCP: 2.4s
- Category page LCP: 2.1s
- Checkout page LCP: 3.1s
- Inventory API calls/min: 18,000 (causing backend strain)
- Inventory freshness: 12 minutes (cached)
- Error rate: 0.8% (mostly timeouts during inventory checks)
-
Warehouse operations audit:
- 12 fulfillment centers, zone-based shipping
- Real-time inventory sync required (current: 15-minute cron job)
- Custom fulfillment rules: zone-based, carrier-based, SKU-based
- WMS: Shopify Fulfillment (standard API)
- 3PL integration: One drop-shipper (custom webhook)
-
Integration inventory:
- Payment: Stripe + PayPal
- Tax: Avalara
- Shipping rates: EasyPost
- Email: Klaviyo
- Analytics: GA4
- Search: Elasticsearch
Key finding: The warehouse system was the sticking point. Their current Luma setup queried inventory on every page load, creating unnecessary backend load. Hyvä's decoupled API approach would solve this.
Timeline & budget presented:
- 14-16 weeks (vs. 24-28 for PWA Studio)
- $420K–$520K (vs. $600K–$800K)
- Expected outcome: 60%+ faster features, <90-second inventory latency, 1.5s+ LCP improvement
Stakeholder alignment: CTO signed off. Executive team approved budget. Go-ahead: green light.
Implementation Timeline: Week-by-Week Summary
Phase 1: Audit & Planning (Weeks 1-2)
Complete. Checklist items: 23/23.
Phase 2: Environment Setup (Weeks 3-5)
Week 3:
- Provisioned production infrastructure (separate from legacy Luma)
- Set up staging environment (exact replica of production DB)
- Hyvä installation via Composer
- Initial theme configuration
Week 4:
- Core Magento 2 configuration (GraphQL, REST API, inventory sources)
- Created 12 warehouse "sources" in Magento Inventory system
- Set up Redis for caching
- Tailwind CSS build pipeline configured
Week 5:
- CI/CD pipeline (Git + automated testing)
- Local development environment (Docker)
- Staging database sync (anonymized production data)
Blocker identified: Production database was 340GB. Syncing to staging took longer than expected. Moved to selective data copy (customers + last 6 months of orders). Resolved: +2 days.
Phase 3: Development (Weeks 6-10)
Week 6-7: Storefront templates
- Home page (hero, carousels, trust signals)
- Product detail page (with warehouse inventory display)
- Category listing pages
- Cart and mini-cart
Week 8-9: Checkout flow
- Multi-step checkout (address → shipping → payment)
- Warehouse selection logic (which warehouse ships this order?)
- Payment integration (Stripe, PayPal)
- Order confirmation
Week 10: Warehouse-specific features
- Real-time inventory display per warehouse
- Warehouse location picker (show nearest to customer)
- Fulfillment sync with Shopify Fulfillment
- Real-time stock updates (via WebSocket from WMS)
Custom code written:
This single component eliminated the need for their legacy polling mechanism, reducing API calls from 18,000/min to 8,400/min.
Development completed week 10: Bemeir had built the core storefront. Handed off to client's team for feedback and iteration.
Phase 4: Integration & Testing (Weeks 11-13)
Week 11: Functional testing
- Happy path: Browse → Add to cart → Checkout → Pay → Confirm (tested 50+ times)
- Edge cases: Empty cart, out-of-stock items, split shipments, backorders
- Error handling: Payment failure, inventory race conditions, WMS offline
Week 12: Performance testing
- Load test: 1000 concurrent users
- Result: System handled with LCP avg 1.3s (target: <1.5s ✓)
- API latency: Inventory queries now 180ms P95 (vs. 420ms baseline)
- Error rate: 0.02% (vs. 0.8% baseline)
Week 13: Integration validation
- Shopify Fulfillment webhook testing (order sync successful)
- Stripe payment processor testing (captures, refunds, disputes)
- Avalara tax calculation (order totals accurate)
- EasyPost shipping rates (correct carriers shown per warehouse)
- Klaviyo email sync (new customers added to list)
Discovered issue: Fulfillment webhook sometimes arrived out-of-order. If "shipped" came before "picked," order status got confused. Solution: Added idempotency keys to webhook handler. Issue resolved: +3 days.
Go-Live: Cutover Plan & Execution
Cutover window: Friday 2am–9am Eastern (low-traffic period)
Week 14: Friday cutover
| Time | Action | Owner |
|---|---|---|
| 1:45 am | Final backup (production + legacy) | DevOps |
| 2:00 am | Begin cutover window; announce maintenance | PM |
| 2:15 am | Final data sync check (orders, customers) | DBA |
| 2:30 am | DNS switch (traffic routed to Hyvä) | DevOps |
| 2:45 am | Smoke test: homepage, add to cart, checkout | QA |
| 3:00 am | 5% traffic to Hyvä, 95% to legacy (fallback ready) | DevOps |
| 3:30 am | Monitor error logs, support tickets (none yet) | Team |
| 4:00 am | Increase to 25% traffic to Hyvä | DevOps |
| 4:30 am | Increase to 50% traffic to Hyvä | DevOps |
| 5:00 am | Increase to 100% traffic to Hyvä | DevOps |
| 5:30 am | Announce "back to normal" (status page) | PM |
| 6:00 am | Begin monitoring 24/7 for 72 hours | Team |
What actually happened:
The cutover went smoothly. Minor hiccup at 3:30am: customer noticed inventory display was 5 minutes stale (WebSocket subscription hadn't updated in a while). Bemeir's on-call engineer fixed it in 12 minutes (WebSocket timeout issue—increased timeout threshold). By 4am, it was running perfectly.
Final go-live time: 3 hours 45 minutes total downtime. (They aimed for 6-7 hours; finished early.)
Post-Go-Live: Weeks 15-16 & Beyond
Week 15: Stabilization & Knowledge Transfer
Weeks 15-16 was Bemeir embedding 2 senior engineers on-site for knowledge transfer.
The company's team learned:
- Codebase structure and Hyvä architecture
- Local development setup (Docker)
- How to deploy changes (CI/CD pipeline)
- How to debug issues (error logs, Sentry, New Relic)
- How to build new features (first 10 features done with Bemeir mentoring)
Day 60: Legacy System Decommissioned
After running Hyvä at 100% for 60 days with zero data issues, legacy Luma system was archived (kept in read-only mode for another 30 days, then decommissioned).
Results: 6 Months Later (Months 4-6)
Performance Improvements
| Metric | Before (Luma) | After (Hyvä) | Improvement |
|---|---|---|---|
| Product page LCP | 2.4s | 1.1s | 54% faster |
| Category page LCP | 2.1s | 0.95s | 55% faster |
| Checkout page LCP | 3.1s | 1.2s | 61% faster |
| CLS (Cumulative Layout Shift) | 0.14 | 0.06 | 57% improvement |
| Inventory API calls/min | 18,000 | 8,400 | 53% reduction |
| Inventory freshness | 12 minutes (cache) | <90 seconds (WebSocket) | 96% improvement |
| Error rate | 0.8% | 0.02% | 97% reduction |
| API server CPU utilization | 78% | 42% | 46% reduction |
Real customer impact:
- Page load speed was noticeably faster (33% of visitors noted improvement in surveys)
- Checkout felt snappier (fewer layout shifts, faster interactions)
- Mobile experience improved (lighter JavaScript, faster rendering)
Business Metrics
| Metric | Before | After | Change |
|---|---|---|---|
| Conversion rate | 2.1% | 2.28% | +8.2% |
| Cart abandonment | 68% | 64% | -4% |
| Mobile conversion | 1.5% | 1.68% | +12% |
| Session duration | 3m 42s | 4m 15s | +13% |
| Pages per session | 3.8 | 4.2 | +10% |
| Customer satisfaction (NPS) | 42 | 51 | +9 points |
The performance improvements translated to real business value: $380K additional annual revenue attributable to higher conversion + lower abandonment.
Engineering Velocity
| Metric | Before | After | Improvement |
|---|---|---|---|
| Features shipped/week | 0.5 | 1.3 | 2.6x faster |
| Average feature cycle time | 8 weeks | 2 weeks | 4x faster |
| Code review to deploy time | 5 days | <1 day | 5x faster |
| Emergency fixes (post-deploy) | 2–3 per month | 0.2 per month | 90% reduction |
| Developer satisfaction | 6/10 | 8.5/10 | +2.5 points |
Quotes from the team:
"Before Hyvä, a product filter change took 8 weeks. Now it takes 2 days. We can actually iterate based on customer feedback instead of planning 6 months in advance." — Frontend Lead
"Debugging is easier because the frontend and backend are separated. I'm not trying to understand Luma's template layer anymore. Just clean APIs." — Backend Developer
"We actually enjoy the work now. Modern tech stack, reasonable deadlines. Three of our engineers who were considering leaving are staying." — CTO
Warehouse Operations
Fulfillment team impact:
- Order processing time: 4.2 minutes → 2.8 minutes (33% faster)
- Split shipment handling: Improved from 40% of orders to 8% (system now optimizes warehouse selection)
- Backorder management: Manual process → automated (inventory replenishment logic built into system)
"Real-time inventory visibility changed everything. We used to guess which warehouse had stock. Now we know immediately. Our fulfillment accuracy went from 96% to 99.8%." — Fulfillment Manager
Cost Analysis: ROI Timeline
Implementation cost: $520K (exactly at budget)
- Personnel: $280K (Bemeir team + client engineers)
- Infrastructure: $120K (staging, production setup, CDN)
- Tools & licenses: $50K (monitoring, security, testing tools)
- Contingency: $70K (unused, but good to have)
Annual operational savings:
- Engineering efficiency: $400K–$500K/year (able to ship 2.6x more features with same team)
- Infrastructure cost reduction: $80K/year (lighter frontend, reduced API calls, lower hosting costs)
- Customer lifetime value increase: $380K/year (attributed to conversion rate lift + reduced abandonment)
Year 1 ROI:
- Costs: $520K (implementation) + $250K (operations, post-cutover) = $770K
- Benefits: $880K (efficiency + infra savings + revenue lift)
- Net: +$110K profit (15% positive ROI year 1)
Year 2+ ROI:
- Costs: $250K (operations)
- Benefits: $880K (efficiency + infra savings + revenue lift, compounding)
- Net: +$630K profit (252% ROI year 2)
Payback period: 18 months
Key insight: The migration pays for itself in feature delivery velocity alone, before accounting for customer-facing improvements.
Challenges Faced & Lessons Learned
Challenge 1: Team Ramp-up on Alpine.js
Issue: Developers coming from Luma/knockout.js background needed time to learn Alpine.js.
Timeline impact: +2 weeks
Solution: Embedded Bemeir senior engineer for 30 days post-go-live. Pair programming on first 15 features. After that, team owned it.
Lesson: Invest in knowledge transfer. It's worth the cost.
Challenge 2: Fulfillment Webhook Ordering
Issue: Webhooks from Shopify Fulfillment sometimes arrived out-of-order, confusing order status.
Timeline impact: +3 days
Solution: Implemented idempotency keys (UUID tracking per webhook). If duplicate received, ignored. If out-of-order, stored and processed in correct sequence.
Lesson: Assume APIs will fail in weird ways. Build defensively.
Challenge 3: Database Size & Migration
Issue: 340GB production database took 18 hours to sync to staging (vs. expected 6 hours).
Timeline impact: +2 days
Solution: Created targeted data sync (customers + recent orders only). Archived older transaction data. Syncs now run in 45 minutes.
Lesson: Plan for data scale from the start. Test migrations with realistic data volumes.
Challenge 4: Legacy Code Debt
Issue: 40% of legacy custom code was technical debt that didn't port cleanly. Team wanted to keep it "just in case."
Timeline impact: Would have added 4+ weeks
Solution: Had honest conversation: "We're deleting this code. It's not working. We're building better." Deleted it. Shipped simpler system. No regrets.
Lesson: Migration is your chance to kill technical debt. Don't bring legacy baggage forward.
Competitive Advantage: 6 Months Later
By month 6 post-cutover, what had they built?
New features shipped:
- Dynamic regional pricing (2 weeks to ship)
- Personalized homepage (3 weeks)
- Warehouse location map (1 week)
- Mobile app integration (4 weeks)
- Subscription product type (2 weeks)
- Advanced loyalty program (3 weeks)
Before Hyvä: They had a 6-month backlog. This would have taken 20+ weeks.
On Hyvä: These shipped in 15 weeks (which overlapped with other work).
The velocity gain was real and compounding. Each month, they shipped more, iterated faster, captured more market opportunity.
Unexpected Wins
1. Developer Recruitment
With modern tech stack (Alpine.js, Tailwind, GraphQL), they could suddenly recruit senior developers. Hired 2 new engineers in month 3 who were excited about the stack. They'd never have joined for Luma.
2. Open Source Contributions
One developer started contributing to Hyvä open-source project. Company became known in ecosystem. Led to consulting opportunities (potential new revenue stream).
3. Operational Simplification
Monolithic Luma required separate deployment pipelines (core + theme). Hyvä decoupled them. Now front-end deploys in 5 minutes, back-end in 8 minutes, independent. Risk of coupled deployments gone.
What Would They Do Differently?
CTO reflection, month 6:
"In hindsight, we should have migrated 12 months earlier. The 18-month payback is great, but the real value is the velocity. Competitors are moving slower. We're shipping features before they even think of them. The cost isn't the constraint—time is. We should have prioritized that."
One thing they'd change:
- Better data migration planning upfront. The database sync delays added 2 days of real timeline impact. Would have mitigated with earlier testing.
What went right:
- Budget contingency. Used it for unexpected integration issues. Prevented timeline pressure.
- Embedded engineers. Knowledge transfer was smooth. Team was productive immediately post-cutover.
- Phased cutover (5% → 25% → 50% → 100%). Caught the WebSocket issue at 5% traffic, not 100%.





