Enterprise Commerce Platform Migration: BigCommerce + Akeneo + Celigo
End-to-end ownership of a complex three-platform migration — BigCommerce storefront, Akeneo PIM, and Celigo iPaaS — from discovery through delivery at Amsive.
The Scope
Enterprise ecommerce migrations fail most often at the seams — where the storefront meets the PIM meets the integration layer. This engagement was three simultaneous platform decisions with interdependent data models, integration contracts, and go-live dependencies.
The platforms:
- BigCommerce replacing a legacy Magento 1 storefront
- Akeneo as the new product information management layer, replacing spreadsheet-driven catalog management
- Celigo as the iPaaS orchestration layer connecting ERP, PIM, and commerce
My role: end-to-end SA ownership from discovery through delivery, working across the client’s internal team, the BigCommerce implementation team, and the integration developers.
Discovery Phase
Three platforms meant three separate discovery tracks running in parallel. Most of the complexity was in the data model — product catalog attributes that Akeneo would own, that BigCommerce needed to render correctly, that Celigo needed to sync from the ERP without losing fidelity.
The standard approach of mapping platform-by-platform doesn’t work here. You need a unified data contract that all three platforms agree to before anyone writes a line of code. I built that contract, got sign-off from all three technical teams, and used it as the single source of truth through the rest of the engagement.
What Made This Complex
Catalog scope creep. Akeneo migrations almost always surface product data debt that nobody knew existed — attributes with inconsistent values, missing required fields, products that were “live” on the old site through tribal knowledge rather than clean data. We found this mid-discovery and restructured the timeline before it became a delivery problem.
ERP integration constraints. The Celigo layer was dependent on the ERP’s available API surface, which was smaller than the initial scoping assumed. This required a hybrid approach: real-time sync for inventory and pricing, batched sync for catalog attributes.
BigCommerce limits. BC has well-documented limits on variant counts and custom field depth. Several product lines exceeded those limits and required restructuring before migration could proceed.
Delivery
Phased go-live: Akeneo first (catalog stabilized), then BigCommerce launch, then Celigo real-time sync cut-over. Each phase had defined rollback criteria and a human sign-off gate before the next phase unlocked.
The phased approach added calendar time but eliminated the risk of a simultaneous three-platform cutover, which would have been unrecoverable if anything went wrong.
What I’d Do Differently
Start the Akeneo data audit earlier. The catalog debt discovery should be a separate, time-boxed phase before the main engagement begins — not something that surfaces mid-discovery. It’s almost always there on migrations this size.