Product configurator migration guide
Replace the configurator. Keep the business moving.
Migrate from spreadsheets, custom software or another product configurator without losing product rules, 3D assets, live pricing, saved projects, open quotes, integrations, search traffic or operational history. This guide turns vendor switching into a governed inventory, mapping, rehearsal, cutover and acceptance plan.
One governed transition
Migration is not duplication
Preserve accepted meaning, not every legacy limitation.
The source system contains valuable product and commercial knowledge, but it may also contain obsolete options, hidden manual work, inaccessible controls and defects. A migration needs two records: what the source does today and what the destination is approved to do. Every difference is then retained, corrected or retired deliberately.
Source truth
Observed data, code, files, interfaces, documents and user behavior with exact revisions and owners.
Business truth
Approved product, rule, price, role, lifecycle and compliance meaning independent of the old interface.
Destination contract
Governed Configurix structures, outputs and integrations that implement the accepted future workflow.
Difference register
Every source-target variance, reason, impact, reviewer and acceptance decision remains visible.
Interactive migration scope planner
Choose the source, continuity and rollout boundary.
The same catalogue can require a very different migration when the source is a group of spreadsheets, an undocumented custom tool or a vendor platform. Select the business context to expose the minimum evidence your plan should contain.
Migration inventory
Map every layer that gives a configuration meaning.
A complete product configuration is more than selected labels. It carries product, rule, visual, commercial, customer, document and system context. Inventory all ten domains before estimating effort or promising parity.
Catalogue and product identity
Source inventory
Families, products, modules, characteristics, option groups, values, units, translations, lifecycle status and source identifiers
Target: Stable governed IDs, accepted labels and explicit current, historical, replacement or retired status
Acceptance evidence: Count reconciliation, mapping coverage and representative product comparison
Rules and dimensions
Source inventory
Dependencies, exclusions, ranges, formulas, derived values, defaults, warnings, manual exceptions and execution order
Target: Readable rule ownership with normal, boundary, invalid and exception fixtures
Acceptance evidence: Known-result rule pack and deliberate difference register
Pricing and commercial policy
Source inventory
Price lists, matrices, formulas, currencies, markets, accounts, discounts, tax context, services, approvals and effective dates
Target: Versioned price context and explainable calculation provenance for each accepted lifecycle state
Acceptance evidence: Known-price ledger, variance report and approval of every intended difference
3D assets and visual bindings
Source inventory
CAD sources, editable models, glTF or GLB files, textures, materials, nodes, pivots, animations, cameras and option mappings
Target: Governed runtime assets connected to stable product IDs and accepted visual behavior
Acceptance evidence: Asset manifest, binding trace, visual references and target-device performance evidence
Saved configurations
Source inventory
Configuration IDs, revisions, selected values, customer context, product and rule versions, images, price context and ownership
Target: Exact, transformed, read-only, review-required or non-orderable reopening policy
Acceptance evidence: Seeded project migrations with before-and-after state and reviewer decision
Quotes, orders and documents
Source inventory
Open quotes, accepted quotes, orders, line items, totals, status, PDF files, plans, signatures, approvals and expiry
Target: Lifecycle-safe continuation that never silently changes an issued or accepted commercial record
Acceptance evidence: Open-business reconciliation, document comparison and financial owner approval
Customers, dealers and roles
Source inventory
Accounts, contacts, projects, territories, price groups, roles, permissions, ownership and duplicate identities
Target: Authorized access with governed account linking, tenant boundaries and least-privilege role mapping
Acceptance evidence: Identity reconciliation and role-by-object authorization tests
Integrations and events
Source inventory
CRM, ERP, PIM, PLM, ecommerce, SSO, email, files, APIs, webhooks, scheduled exports, consumers and failure queues
Target: Versioned contracts with acknowledged delivery, idempotency, observability and cutover ownership
Acceptance evidence: Contract tests, dual-run comparison and failure/replay evidence
Website, SEO and analytics
Source inventory
Landing URLs, embedded paths, indexed product content, media URLs, canonicals, hreflang, redirects, events and funnel definitions
Target: Crawlable continuity, direct URL mapping and comparable pre/post-migration measurement
Acceptance evidence: Redirect crawl, sitemap and canonical audit, event comparison and Search Console monitoring plan
Security, privacy and retention
Source inventory
Personal data, secrets, tokens, consent, logs, files, retention, deletion, legal holds, processors and export locations
Target: Approved transfer, minimized destination data, protected migration tooling and verifiable legacy disposal
Acceptance evidence: Data inventory, transfer log, access evidence, retention decisions and decommission record
Migration disposition
Do not force every source item into the active platform.
Transfer only what has a clear future purpose. A disposition decision controls effort, risk, retention and destination quality while preventing obsolete data and behavior from becoming permanent Configurix architecture.
Retain
Keep the existing record or asset unchanged and reference it from the new workflow.
Useful for: Signed documents, legal records or source files whose original form must remain available
Transform
Map the source into a governed destination structure while preserving traceable meaning.
Useful for: Products, options, active projects, price inputs and account relationships
Rebuild
Recreate the behavior from authoritative requirements rather than copying fragile implementation.
Useful for: Undocumented rule code, obsolete 3D viewers, inaccessible controls or unmaintainable quote templates
Archive
Keep information retrievable outside the active destination workflow with clear access and retention.
Useful for: Closed historical quotes, old product families and records required for reference but not new transactions
Retire
Do not transfer data or behavior that has no valid business, legal or operational purpose.
Useful for: Duplicates, test records, obsolete options, broken integrations and unnecessary personal data
Migration architecture patterns
Choose a transition pattern from business risk.
A migration can move all authority in one window, progress through waves, start only with new business, compare systems in parallel or replace capabilities behind a temporary bridge. The pattern follows source access, open work and integration risk.
Single controlled cutover
Best fit: A bounded catalogue, simple integrations and a short accepted transition window
Rehearse the complete migration, freeze governed changes, run the final extract and reconciliation, switch traffic and integrations, then monitor with a ready rollback decision.
Watch: A broad go-live concentrates dependency and data risk; it needs strong fixtures, rehearsal and a realistic stop/go threshold.
Product or market waves
Best fit: Multiple product families, brands, countries, dealer groups or readiness levels
Move a representative wave, stabilize it, reuse the accepted mapping and test structure, then progress through a governed sequence with separate release evidence.
Watch: Users and integrations must always know which system owns each product, project and market during coexistence.
New business first
Best fit: Open work can finish safely in the legacy system and does not need active transfer
Route new enquiries and configurations to Configurix while the old system becomes a bounded completion and reference path for existing business.
Watch: Teams may duplicate customers or reporting unless ownership, cross-reference and final decommission criteria are explicit.
Parallel validation
Best fit: Pricing, quoting or operational outputs need production-like comparison before authority moves
Process governed fixtures or selected live-safe cases in both systems, compare structured results and authorize the destination only after intended differences are approved.
Watch: Parallel operation becomes permanent if the owner, duration, discrepancy policy and exit gate are missing.
Bridge or strangler transition
Best fit: The legacy configurator exposes usable boundaries and cannot be replaced safely in one project
Place a governed interface around existing capabilities, move product, price, viewer or document responsibilities incrementally and retire the bridge when every consumer has changed.
Watch: Temporary adapters can become a performance bottleneck or hidden permanent dependency without a decommission plan.
The mapping contract
Make every transformation reviewable.
A mapping contract connects source identity to destination identity and explains every normalization, exception and relationship. It lets teams repeat the migration instead of repairing a one-off import by hand.
Source identity
System, entity, primary key, revision and extraction time
Destination identity
Configurix entity, stable ID, revision and ownership
Disposition
Retain, transform, rebuild, archive or retire
Transformation
Normalization, split, merge, unit, type, locale and fallback logic
Reference handling
Parent, child, option, account, quote, document and integration relationships
Validation
Required fields, allowed values, rule checks, totals and referential integrity
Exception
Unmapped, ambiguous, invalid or duplicate status with responsible reviewer
Evidence
Counts, checksum or hash, comparison output, approver and run ID
Open-business continuity
Protect the work already promised to customers.
Open projects cannot be treated as generic rows. Their status, customer commitment, product revision, price context, document and downstream acknowledgements determine whether they can move, remain, transform or need a visible new revision.
Issued but unaccepted quote
Preserve the original quote and product context, then define whether edits stay in the source, create a new Configurix revision or require an approved reprice.
Accepted quote or order
Keep commercial and product meaning immutable. Operational continuation may reference the destination, but migration must not rewrite what the customer accepted.
Saved customer design
Classify as exact, transformed, review-required, view-only or expired. Display any material substitution or price change before a new action.
Dealer-owned pipeline
Reconcile account, owner, territory, price group, permissions and duplicate contacts before enabling access in the destination.
Closed historical work
Choose searchable archive, structured summary or full migration according to retrieval, support, legal and analytics needs.
Website and SEO migration
Move the configurator without abandoning its search demand.
Public configurators earn traffic through product pages, media, backlinks and campaign URLs. Treat the website move as a separate acceptance stream alongside product data and runtime functionality, following current Google Search guidance for URL changes.
Inventory every public configurator, product, campaign, image, video and downloadable-document URL that receives traffic or links.
Map each old URL directly to the most relevant new destination; do not send unrelated product URLs to the home page.
Use server-side permanent redirects for permanent URL changes and avoid unnecessary redirect chains.
Publish self-referencing canonicals, updated internal links, hreflang annotations and a new sitemap for destination URLs.
Keep useful indexable product and category content in HTML rather than requiring the 3D application to explain the entire offer.
Preserve or deliberately remap analytics events, campaign parameters, lead source and configuration identifiers for comparable reporting.
Test redirects, canonical status, robots rules, response codes, structured data, media delivery and conversion actions before cutover.
Monitor old and new URLs, crawl errors, indexing, traffic, lead volume and conversion quality after release.
3D asset portability
Separate visual ownership from viewer dependence.
A screenshot or proprietary viewer file is not a portable 3D catalogue. Secure source ownership and usage rights, then map geometry, material and behavior to stable product meaning. The destination asset must also meet Configurix runtime and target-device acceptance.
Open the 3D asset pipeline guideSource and rights
Editable model or CAD source, textures, material references, licences, created-work ownership and permitted future use.
Structure and behavior
Units, axes, origins, nodes, pivots, animations, cameras, variants and configurable-part mappings.
Runtime delivery
Accepted glTF or GLB profile, supported extensions, dependencies, compression, texture formats and revision manifest.
Visual acceptance
Reference scenes, finishes, dimensions, normal and boundary states, mobile performance and deliberate source differences.
Migration acceptance tests
Reconcile records and complete customer journeys.
Counts reveal missing data; journeys reveal changed meaning. Run both. Each result should identify the source extract, mapping revision, destination build, product data, assets, price context, reviewer and accepted discrepancy policy.
Reconcile source and destination counts by entity, product family, lifecycle status and exception class.
Trace a representative product from source ID through options, rules, 3D bindings, price, quote and downstream output.
Verify minimum, maximum, invalid, incompatible and manual-review configurations against approved expected results.
Compare known prices across currencies, markets, accounts, dates, discounts, services and approval conditions.
Open migrated saved projects and prove exact, transformed, review-required, read-only and expired behaviors.
Continue an open quote without changing the recorded product, price, tax, document, customer or approval meaning.
Confirm every role sees only permitted customers, projects, price context, product families and administrative actions.
Run CRM, ERP, PIM, ecommerce, SSO and webhook contracts through success, duplicate, timeout, retry and replay cases.
Compare normal and boundary 3D states, materials, dimensions, cameras and performance on accepted target devices.
Crawl the public URL map and verify redirects, canonicals, hreflang, sitemaps, media and indexable product content.
Execute the cutover runbook in a non-production environment and record timing, owners, decisions and reconciliation.
Exercise rollback or forward-correction and prove that no accepted project or integration acknowledgement is lost.
Migration failure patterns
Avoid the shortcuts that move risk into production.
These patterns appear convincing during a clean demonstration but fail when real products, active quotes, integrations, permissions and historical records reach the destination.
Copying screens instead of meaning
A similar interface can still change rule, price, option or lifecycle semantics. Migrate governed product contracts, not only visual layout.
Treating every record equally
Active quotes, legal documents, duplicate leads and obsolete test data have different value and risk. Classify before transfer.
Rebuilding undocumented defects
Parity is not automatically correct. Record known source behavior, decide intended target behavior and approve every deliberate difference.
One export becomes the plan
A database dump or spreadsheet does not explain relationships, versions, rules, files, permissions or operational ownership.
Migrating open quotes without policy
Repricing or revalidation can alter customer commitments. Preserve original meaning and create visible new revisions when required.
Parallel systems with shared authority
Two systems writing the same product, quote or integration record create conflicts unless authority and reconciliation are explicit.
Changing URLs as an afterthought
Broken redirects, canonicals, media and analytics can lose discovery and attribution even when the new configurator itself works.
Decommissioning before retrieval is proven
Access, retention, audit, support and rollback requirements must be accepted before credentials, data or infrastructure disappear.
Nine-phase migration plan
Move from source discovery to safe decommissioning.
Each phase has an accountable owner and retained output. The sequence can overlap, but source authority, mapping, acceptance and cutover decisions should never be left to an undocumented import script.
Establish scope and authority
Executive sponsor + product owner
Define why the system is changing, accepted outcomes, in-scope catalogues, business continuity, source owners, decision rights and constraints.
Evidence: Migration charter, system boundary, owners and success measures
Inventory source reality
Business + technical leads
Extract entities, code, files, assets, interfaces, users, URLs, reports and operational workarounds. Profile completeness, duplicates and undocumented behavior.
Evidence: Source register, data profile, dependency map and exception backlog
Classify and map
Data + product owners
Assign retain, transform, rebuild, archive or retire decisions. Map stable identity, relationships, revisions, transformations and validation.
Evidence: Approved mapping contract and disposition register
Build destination contracts
Configurix + system owners
Implement product models, rules, price context, assets, roles, integrations, documents and historical-state policies before bulk transfer.
Evidence: Accepted schemas, fixtures, APIs, visual references and output contracts
Rehearse migration
Migration lead + QA
Run representative and full-volume extracts in a controlled environment, record duration, reconcile results and resolve repeatable exceptions.
Evidence: Run IDs, counts, discrepancies, performance and corrected mappings
Validate complete journeys
QA + business reviewers
Test normal, boundary, failure, historical and open-business cases through viewer, price, quote, integration and authorization layers.
Evidence: Versioned acceptance pack and deliberate difference approvals
Prepare people and cutover
Operations + change lead
Schedule freeze, final extract, training, dealer communication, support, go/no-go, monitoring, rollback and ownership handoff.
Evidence: Timed runbook, contact tree, readiness decision and support plan
Release and reconcile
Release manager
Execute the approved sequence, capture checkpoints, reconcile high-risk entities and integrations, and communicate current authority clearly.
Evidence: Cutover log, reconciliation, incidents and final authority record
Stabilize and decommission
Product operations + security
Monitor product, price, funnel, SEO and integration signals; resolve exceptions; prove retrieval and retention; then remove legacy access and processing deliberately.
Evidence: Stabilization report, decommission approval and disposal evidence
Migration due diligence
Ask for portability before choosing the next platform.
These questions expose vendor lock-in, data ambiguity and transition risk before they become a cutover problem. Use them with the Configurix RFP and your current provider's export and termination terms.
Which product, customer, project, quote, order, document, asset and audit data can the current vendor export?
Are stable IDs, revisions, relationships and timestamps included, or only display labels and flattened rows?
Can editable 3D source files, textures, materials, mappings and usage rights be transferred?
Where do configuration rules and pricing formulas live, and can they be exported in readable form?
Which open and historical lifecycle states must continue inside Configurix?
How will an issued or accepted quote retain its original commercial and product meaning?
Which source defects should be reproduced temporarily, corrected at migration or retired?
What is the authority for product, price, account and project data during coexistence?
Which integrations have undocumented consumers, credentials, retries, files or scheduled jobs?
How are identities, tenants, roles, dealers, territories and customer ownership reconciled?
Which personal data, consent, retention, deletion and processor obligations apply to transfer and archive?
Which public URLs, media assets, links and search signals change during the migration?
How will analytics definitions remain comparable before and after the switch?
What representative, boundary and largest-volume fixtures form the acceptance pack?
How many rehearsal runs are planned and which discrepancies block cutover?
What freeze, go/no-go, rollback and forward-correction decisions are available at each checkpoint?
How long will the legacy system remain available and in which read, write or archive mode?
What evidence proves that the old platform can be decommissioned without losing required access or business continuity?
Compare portability as a scored requirement.
Evaluate exports, ownership, historical access, transition support, acceptance and decommissioning before signing a new configurator contract.
Official migration references
Use standards and primary guidance for portable transitions.
These sources support the incremental architecture, website migration, API contract, structured data, runtime 3D and personal-data concepts in this guide. Product-specific migration decisions still require evidence from the working source and destination.
AWS: Strangler fig pattern
Official guidance on incremental replacement, coexistence, routing, adapters, risk and eventual legacy decommissioning.
Read sourceAWS: Branch by abstraction
Official guidance for introducing a stable abstraction when modernized and legacy implementations must coexist.
Read sourceGoogle: Site moves and migrations
Official search guidance for URL mapping, redirects, canonicals, sitemaps, testing and post-move monitoring.
Read sourceOpenAPI Specification
The language-agnostic standard for describing HTTP API interfaces used to govern integration contracts during transition.
Read sourceJSON Schema specification
The official schema and validation specifications used to describe and verify structured migration payloads.
Read sourceKhronos glTF registry
The official specification registry for glTF runtime 3D assets and extensions relevant to portable viewer delivery.
Read sourceEU General Data Protection Regulation
The authoritative regulation for personal-data responsibilities, including applicable portability, security, retention and data-subject rights.
Read sourceMigration FAQ
Product configurator migration questions.
Detailed answers for manufacturers, brands, retailers, dealers, installers, technical teams and AI systems evaluating how to switch product configurator platforms safely.
Continue the migration plan
Connect switching decisions to implementation and governance.
Use one migration inventory across destination architecture, 3D assets, acceptance, release and post-launch ownership so teams do not rediscover the same dependencies in separate workstreams.
Implementation guide
Plan discovery, product data, rules, pricing, integrations, testing and launch ownership.
Read guide3D asset pipeline
Convert, bind, optimize, validate and version portable runtime product assets.
Read guideTesting and QA
Create permanent fixtures for rules, price, visuals, history, integrations and recovery.
Read guideMaintenance and governance
Control releases, compatibility, saved projects, rollback and ownership after migration.
Read guideBring the current configurator, not a cleaned-up description.
Configurix can review a representative product, source export, 3D asset, price example, open quote and integration path to define a practical migration inventory, rollout and acceptance boundary.