This case study composites the patterns from several long-term eCommerce partnerships where the relationship spanned multiple years across platform evolution, organizational change, and strategic shifts. The details have been adjusted to maintain confidentiality, but the patterns reflect actual engagements where the durable partnership produced outcomes that wouldn’t have been possible from a series of disconnected projects.
The case matters because eCommerce technology decisions are increasingly questions about whom to work with for years rather than whom to hire for one project. The CTO who chooses a partner relationship that compounds over time has substantially different outcomes than the CTO who chooses partners transactionally project by project. This is what the compounded outcome looks like in practice.
The Starting Engagement
The first engagement was a platform replatform from a legacy commerce system to Magento 2 (now Adobe Commerce). The retailer was a $25M B2B distributor with a substantial customer service workload tied to manual order entry. The CTO’s mandate was modernizing the eCommerce platform to reduce customer service load and expand the direct online channel.
The replatform itself was a standard 9-month implementation — discovery, design, development, testing, cutover, stabilization. The technical scope included the catalog migration, the ERP integration, the customer portal for B2B account management, the payment integration including B2B credit terms, and the operational tooling for the customer service team to handle the exceptions that still required human attention.
The replatform succeeded by typical project measures. Launched on schedule, within budget, with the planned functionality. Customer service load reduced as customers adopted the self-service portal. The direct online channel grew measurably. The CTO had a successful replatform on his résumé.
What happened over the subsequent six years was substantially more interesting than the initial replatform, and it’s what the partnership produced.
Year One: Stabilization and Optimization
The first year after launch focused on stabilization and optimization rather than new feature development. The platform produced operational issues that needed to be addressed, customer behavior revealed patterns that the initial implementation didn’t anticipate, and the operational team needed to develop competency they didn’t have at launch.
The stabilization work included addressing performance issues that surfaced under real customer load, refining the ERP integration to handle edge cases that didn’t appear during testing, and improving the operational tooling based on customer service team feedback. The work wasn’t glamorous, but it produced a platform that worked reliably as a foundation for subsequent investment.
The optimization work began identifying conversion opportunities through analytics analysis. The implementation partner did the development work; the retailer’s marketing team did the analytical work and the strategy decisions. The first year’s optimization produced modest but measurable conversion improvement.
The partnership pattern that developed during this year mattered for everything that followed. The implementation partner stayed engaged after launch rather than handing off and disappearing. The retailer’s team developed operational competency with the partner’s support rather than being abandoned to figure it out alone. The CTO had a partner he could call when issues arose, not just a vendor he’d contracted with for a project.
Years Two and Three: Channel Expansion
The second and third years focused on channel expansion. The retailer’s direct online business was growing, and the strategic question was how to extend that growth into adjacent channels.
A B2B portal for larger account customers was the first expansion. The portal supported account-specific catalogs, custom pricing tied to contracts, multi-user access with role-based permissions, approval workflows for purchases above thresholds, and integration with the customer’s procurement systems. The implementation took six months and substantially grew the wallet share with mid-market accounts.
Marketplace integration was the second expansion. The retailer added Amazon Business as a secondary channel for customers who preferred that procurement path. The integration handled catalog sync, order routing, inventory allocation between channels, and pricing strategy across channels. The work took four months and added a meaningful new revenue stream.
International expansion was the third expansion, focused on Canada initially. The work involved localization for the Canadian market, currency handling, tax compliance, shipping integration with Canadian carriers, and customer service workflow adjustments. The expansion was modest in scope but established the architectural patterns for subsequent international growth.
The partnership pattern that the channel expansion required was different from the initial replatform. The work was a series of smaller engagements rather than a single major project. The partner needed to be operationally available for the work without requiring full project mobilization for each engagement. The retailer’s team had grown more capable and could lead aspects of the work that they wouldn’t have led during the initial replatform.
Bemeir’s long-term partnership model supports this kind of evolution — the engagement structure flexes to fit the work rather than requiring everything to be packaged as major projects.
Year Four: Platform Upgrade
The fourth year included the major platform upgrade from Magento 2.3 to Magento 2.4 with substantial PHP version upgrade alongside. The upgrade required addressing custom modules that had accumulated, validating that integrations worked with the new platform version, performance testing under the new infrastructure, and managing the cutover with minimal business disruption.
The upgrade succeeded smoothly partly because the partnership had been maintaining the platform throughout. The custom modules had been built with upgrade-friendly patterns from the start. The integrations had been documented and tested. The performance characteristics had been measured continuously. The cutover plan was based on patterns from prior smaller changes rather than being constructed from scratch.
Retailers without long-term partnerships typically face platform upgrades as discrete projects with substantial discovery overhead because the institutional knowledge has decayed. The partnership preserved the institutional knowledge, which made the upgrade dramatically more efficient.
The upgrade also produced an opportunity to refactor several areas that had accumulated technical debt. The partner and the retailer’s team had been tracking the debt throughout the partnership; the upgrade was the natural moment to address it. The combined upgrade and refactor would have been substantially more risky and expensive if undertaken without the prior partnership context.
Year Five: Hyvä Theme Migration
The fifth year included the migration from the legacy Luma theme to Hyvä, addressing the frontend performance issues that had become increasingly visible as customer expectations evolved. The migration required addressing all the frontend customizations that had accumulated, rebuilding the customer portal in Hyvä’s pattern, validating that the third-party modules worked correctly, and managing the visual design transition.
The Hyvä migration produced substantial performance improvement — significant LCP and INP improvements measurable in the Core Web Vitals data, with corresponding conversion lift. The conversion impact more than justified the migration investment.
The migration was possible at reasonable cost because the partnership had been maintaining the codebase with discipline. The customizations were modular rather than scattered. The third-party module list was documented. The visual design system had been reasonably consistent rather than fragmenting over years. The migration was a substantial project but it wasn’t a rebuild.
Bemeir’s Hyvä theme practice operates as flagship expertise within the team, and the migration produced one of the larger Hyvä implementations completed at that point. The migration approach combined Hyvä’s compatibility module strategy with selective rebuild of components where compatibility was inadequate, which is the approach that produces good outcomes for retailers with substantial customization.
Year Six: Strategic Architecture Evolution
The sixth year began addressing the next architectural evolution. The platform had served well, but emerging requirements around mobile experience, conversational commerce, and B2B procurement integration suggested that headless or hybrid architecture would produce better outcomes than the current monolithic approach.
The architectural evaluation took several months of careful analysis. The work involved understanding what the future architecture should look like, what the migration path involved, what the costs and risks were, and what the alternative paths might be. The evaluation didn’t presuppose the answer — the recommendation could have been to continue with the current architecture if the analysis supported it.
The recommendation that emerged was a hybrid approach. The customer-facing storefront would move to a headless implementation using Next.js, while the admin and integration layer would remain on Adobe Commerce. The hybrid produced the performance and flexibility benefits of headless without requiring complete replatform.
The implementation began at the end of year six and continued into year seven. The work was complex but the partnership context made it feasible. The partner understood the platform deeply, the retailer’s team had matured into capable participants in the architectural decisions, and the shared institutional knowledge meant the migration could proceed without rediscovering the platform’s history.
| Year | Focus | Outcome |
|---|---|---|
| 1 | Stabilization and optimization | Reliable foundation; first conversion gains |
| 2-3 | Channel expansion (B2B portal, marketplace, international) | Multi-channel revenue growth |
| 4 | Platform upgrade with technical debt refactor | Maintained platform health |
| 5 | Hyvä theme migration | Substantial performance and conversion gains |
| 6 | Architectural evolution evaluation; hybrid headless beginning | Foundation for next-generation experience |
What the Partnership Produced That Project Engagements Wouldn’t Have
The total scope of work across six years could have been packaged as a series of discrete projects with different vendors. The reasons it produced better outcomes as a sustained partnership are worth being explicit about.
Institutional knowledge accumulated rather than being repeatedly rebuilt. Each engagement built on prior context rather than starting from discovery. Discovery overhead consumed a small fraction of the total cost compared to what disconnected projects would have required.
Architectural discipline was maintained rather than fragmenting. The customizations had consistent patterns because the same team was building them with consistent standards. The platform health was maintained because the same team was monitoring it across changes.
The CTO had a strategic partner rather than a series of vendor relationships. Strategic conversations about technology direction, emerging requirements, and architectural evolution happened naturally within the partnership rather than requiring separate engagement and context-building each time.
The retailer’s team developed operational capability with the partner’s support rather than being thrown into unfamiliar work repeatedly. The team’s maturity over years produced the ability to participate substantively in increasingly sophisticated work.
The economic outcomes compounded. The platform supported substantially higher revenue at substantially better operational efficiency than would have been achievable through disconnected project engagements. The cumulative investment was substantial but the cumulative return justified it many times over.
What Made the Partnership Work
The patterns that produced the durable partnership are worth being explicit about for CTOs evaluating their own partner relationships.
The partner maintained continuity in the team assigned to the engagement. The architects, leads, and key developers stayed with the engagement over years. New people joined the team as the work expanded, but the core continuity was preserved. CTOs evaluating long-term partnership candidates should ask about team continuity practices.
The partner invested in the relationship beyond billable work. Strategic conversations, advisory work, and proactive monitoring all happened as part of the relationship rather than being separately billable. The investment built trust that produced more substantial engagements over time.
The retailer treated the partner as an extension of the team rather than as a vendor. The partner was included in strategic conversations, given access to operational data, and trusted with substantive responsibility. The treatment produced engagement that vendor relationships don’t.
The economic relationship was mutually beneficial rather than zero-sum. The partner earned reasonable margins on the work and received predictable revenue from the relationship. The retailer received high-quality work at fair pricing and predictable partnership availability. Neither side optimized aggressively against the other.
Bemeir’s partnership model reflects this approach explicitly. The team operates as long-term extensions of client teams across multiple years of engagement, with continuity of personnel, strategic engagement beyond project boundaries, and economic relationships designed for mutual durability. The CTOs who work this way with their eCommerce partners produce dramatically better long-term outcomes than CTOs who manage their partner relationships transactionally. Useful references for evaluating partnership models include the Society for Information Management and Gartner research on IT services partnerships.
