eTron Understands the Platform From Its Riversand Roots
Syndigo acquired Riversand in 2021, and most consulting partners approach the resulting platform purely as "Syndigo" — treating Riversand as a legacy name to migrate away from as quickly as possible. eTron Digital's leadership held founding, product, and executive roles at both Riversand and Syndigo before starting this firm. That means eTron doesn't just know the destination platform — eTron knows it from the inside: exactly where the architecture, data model, and platform assumptions came from, and why certain migration decisions matter more than they first appear.
This guide covers what a Riversand-to-Syndigo migration actually involves, end to end.
Architecture Differences
Riversand's original architecture was built around a flexible, entity-relationship-driven data model with a strong emphasis on multi-domain MDM — customer, product, supplier, and location domains all governed through the same core engine. Syndigo's own heritage is on the syndication and digital-shelf side: getting validated product content out to retailers and marketplaces at scale.
Post-acquisition, Syndigo has worked to unify these into a single platform, but the underlying architectural DNA still shows up in how the platform handles things like entity modeling flexibility, workflow engines, and extension points. A migration plan that treats this as "just an upgrade" rather than a genuine architectural transition tends to under-scope the effort significantly.
The v7 → v8 Migration
Internally, eTron refers to the major platform-generation shift as the v7-to-v8 migration — the move from the earlier Riversand-era technical stack to the current Syndigo-integrated generation. This isn't a simple in-place version bump. Key differences that affect migration planning:
Underlying data storage — the persistence layer and indexing approach changed materially between generations, which affects how large reference datasets and digital assets need to be re-platformed rather than simply copied.Asset handling pipeline — for organizations with large digital asset libraries, the practical migration path eTron has used runs assets through a SQL Server staging layer into Azure Blob Storage, rather than a direct lift-and-shift, to preserve metadata integrity and avoid broken asset links post-cutover.Configuration portability — some v7 configuration (custom entity types, certain extension patterns) does not translate 1:1 and needs to be redesigned against v8's model, not just re-imported.Treat this stage as a re-platforming project with a migration component, not a migration project with a version number attached.
Data Model Migration
The core data model — entity types, attributes, and the relationships between them — rarely maps cleanly from one platform generation to the next. The practical approach:
Inventory every entity type and attribute actually in active use (not just what's defined) before mapping anything.Identify attributes that exist only because of old platform limitations — these are prime candidates to consolidate or retire, not migrate as-is.Map relationships (Link Types) explicitly; implicit relationships that Riversand handled through configuration conventions sometimes need to become explicit structures in the target model.Taxonomy Migration
Taxonomy is where migrations most commonly go wrong, because it's tempting to migrate the taxonomy tree as a flat export/import. A cleaner approach:
Establish a single primary taxonomy architecture in the target platform before importing anything — don't let multiple legacy classification trees migrate in parallel and become permanent.Reconcile category-level attribute inheritance rules explicitly; these often behave differently between platform generations.Validate that channel-specific taxonomy views (retailer-specific categorization, for example) still resolve correctly against the new primary taxonomy.Reference Data Migration
Controlled Value Lists (CVLs) and other reference data need the same rigor as the core data model:
Deduplicate reference values before migration — legacy systems accumulate near-duplicate CVL entries over time, and migrating them as-is just moves the mess.Identify CVLs that are also used as mapping tables in integrations; these need coordinated migration with the integration layer, not independent migration.Establish ownership for each reference dataset going forward, so post-migration drift doesn't recreate the same problem in the new platform.Digital Asset Migration
Assets are frequently the largest and most operationally risky part of a Riversand-to-Syndigo migration, simply due to volume. Beyond the storage pipeline described above:
Validate asset-to-entity linkages after migration, not just asset file integrity — a common failure mode is assets that migrate successfully but lose their association to the correct product records.Reconcile asset metadata schemas between platforms; metadata fields don't always have a 1:1 equivalent.Plan for a phased cutover on very large asset libraries rather than a single big-bang transfer, to keep validation manageable.Workflow Migration
Workflows encode business process, not just system configuration, so they deserve business review, not just technical migration:
Document what each existing workflow actually enforces today (including undocumented exceptions) before rebuilding it.Rebuild workflows in the target platform's native workflow model rather than trying to replicate legacy workflow logic exactly — platform generations often have materially different workflow engines.Re-validate approval chains and role assignments; these are easy to silently break during migration.Integration Migration
Upstream and downstream integrations are where migration risk compounds, because integration failures often aren't visible until data actually flows through them in production:
Inventory every integration — including the informal ones nobody remembers building — before planning the cutover sequence.Distinguish integrations that just move data from integrations that also make decisions (transformation logic, business rules embedded in middleware); the latter need the same governance scrutiny as core platform configuration.Sequence integration cutover carefully; upstream ingestion and downstream syndication often need to switch over at different points in the migration timeline, not simultaneously.API Migration
API-level changes between platform generations are often underestimated because they're "just technical":
Audit every API consumer, internal and external, before assuming an API migration is backward-compatible.Version APIs explicitly during the transition window rather than cutting over all consumers simultaneously.Validate authentication and rate-limiting behavior separately from functional correctness — these are common sources of production issues that don't show up in initial testing.Business Rules Migration
Business rules — completeness criteria, validation logic, publish-readiness gates — are exactly the kind of decisions that should route through a data governance function, not get migrated as pure technical configuration:
Document the business intent behind each rule, not just its technical implementation, before migrating it.Consolidate rules that have drifted into near-duplicates across categories or brands.Assign clear business ownership for each migrated rule set going forward.Security Migration
Security and access model migration deserves a dedicated review pass, not a default "migrate roles as-is":
Re-map roles and permissions against the target platform's access model rather than assuming a direct equivalent exists for every legacy role.Audit for over-permissioned service accounts and integration credentials that accumulated in the legacy system — migrations are a natural opportunity to clean these up.Validate segmentation (who can see and edit what) against actual current business structure, not the structure that existed when the original roles were configured.Migration Validation
Validation needs to happen at multiple levels, not just "did the data arrive":
Record-level validation — counts, checksums, and spot-checks against source data.Relationship validation — confirming that migrated relationships (entity links, asset associations, taxonomy placements) resolve correctly, not just that the records themselves exist.Business validation — having actual business data owners review a representative sample of migrated content for correctness, not just technical completeness.Regression Testing
Regression testing for a platform migration needs to cover more than the migrated data itself:
Test downstream syndication outputs against retailer/marketplace specifications, not just internal data correctness.Test integration behavior under realistic data volumes, not just functional test cases — performance regressions are common when moving between platform generations.Include workflow and approval-chain testing as a first-class regression category, not an afterthought to data testing.Cutover Planning
Cutover is where technical readiness meets business risk tolerance:
Define a clear rollback plan before cutover begins, not as a reaction if something goes wrong.Sequence cutover by business risk, not just technical dependency — lower-risk product categories or brands first, where feasible, to validate the process before the highest-stakes data moves.Communicate cutover windows clearly to every team whose daily work touches the platform, not just the technical stakeholders.Post-Migration Optimization
Migration doesn't end at cutover. The highest-value work often happens in the weeks after:
Run a data model health audit against the new platform's actual usage patterns, not just the pre-migration plan — real usage reveals gaps that planning doesn't.Retire the legacy platform access deliberately and on a defined timeline, rather than leaving it running "just in case" indefinitely.Use the migration as the natural moment to stand up (or formalize) an ongoing data governance function — the same discipline that keeps any PIM program healthy long after go-live.The Bottom Line
A Riversand-to-Syndigo migration is a genuine platform transition, not a version upgrade — the architecture, data model, and operational assumptions all shifted meaningfully with the acquisition. Treating it with that level of rigor, across all fifteen areas above, is what separates migrations that hold up from ones that quietly accumulate the same problems in a new platform.