Replacing a product configurator platform is a transfer of product decisions, not a front-end redesign. The old system may contain years of rules, exceptions, identifiers, 3D assets, price logic, saved configurations and integration behavior that nobody has documented in one place. A new interface can look finished while those operating contracts are still missing.
The safer sequence is discovery, ownership, extraction, target contracts, parallel proof, phased cutover and only then retirement. Keep the old and new paths reversible until the replacement can reproduce the decisions the business depends on. The broader 3D web configurator architecture guide explains browser, state, rule, backend and deployment responsibilities. This guide focuses on the migration between an existing implementation and its replacement.
Decide whether to troubleshoot, stabilize or migrate
Do not choose a replacement platform from a feature grid before classifying the failure. A slow viewer, an unreliable pricing call and inaccessible rule data are different problems. They may share a screen, but they do not share a remedy.
Use this decision tree during an authorized discovery:
- Can the team inspect and change the current system? If source code, configuration exports, asset masters, vendor terms, credentials or a safe test environment are unavailable, stop at discovery. The first workstream is access and ownership, not target implementation.
- Is the failure local and bounded? A specific oversized asset, browser regression, cache defect or broken endpoint may be repairable without changing the platform. Isolate and test that fault first.
- Are the core data and rule contracts usable? If stable product IDs, extractable rules and documented integration boundaries exist, but releases and monitoring are weak, stabilization may buy time at lower migration risk.
- Does the platform block a required business capability? Replacement becomes credible when material requirements cannot be met through a bounded repair: rule expression is trapped or opaque, data cannot be exported safely, integrations cannot be versioned, the runtime cannot meet acceptance criteria, or the operating model has become untenable.
- Can the team name a reversible first slice? If every product, market and integration must switch at once, discovery is incomplete. Find a product family, region, channel or capability with clear boundaries and a route back.
The companion guide to fixing, stabilizing or rebuilding a slow product configurator owns fault classification and the stabilize-versus-rebuild choice. Once that decision points to replacement, map scope and uncertainty before requesting sensitive diagnostics.
Build the dependency map before choosing the target
Start with what the existing configurator decides and touches. Platform names belong in the inventory, but they are not the inventory. The useful unit is a dependency with an owner, an interface, a source of truth, a failure effect and acceptance evidence.
The table below is an original Double Edged replatform dependency map. Replace each prompt with project-specific findings. A blank owner or evidence cell is a migration risk, even when the corresponding feature works today.
| Dependency | Discover in the current system | Ownership decision | Target contract and acceptance evidence |
|---|---|---|---|
| Product identity | Product, variant, component and market IDs; aliases; retired values | System that creates each durable ID | Mapping table with no unexplained collision; known retired IDs handled explicitly |
| Configuration rules | Allowed combinations, exclusions, defaults, dependencies and exception order | Named business rule owner and technical rule store | Versioned rule representation plus valid, invalid and boundary test cases |
| Price and quote logic | Inputs, currency, tax, discount, rounding, approval and timeout behavior | Authoritative price service and fallback owner | Versioned request and response contract; reconciled test basket results |
| 3D and 2D assets | Masters, derivatives, material IDs, cameras, hotspots, fallbacks and usage rights | Asset master, derivative pipeline and approval owner | Asset manifest tied to product IDs; visual review at named states and devices |
| Saved configurations | Public IDs, account binding, expiry, share links and schema versions | Record system and retention owner | Compatibility policy for old links plus migration and rejection evidence |
| Commerce integrations | Cart, quote, CRM, ERP, PIM, DAM, identity, inventory and webhooks | Owner for each endpoint and credential | Contract tests, idempotency behavior and a rollback route for every side effect |
| Analytics and consent | Event names, payload meanings, attribution, consent state and reporting consumers | Data controller, event producer and report owner | Event dictionary and side-by-side validation without duplicating restricted data |
| Release operations | Environments, feature flags, DNS, cache, alerts, support and incident paths | Release approver and incident commander | Rehearsed runbook, observable gates and time-bounded rollback authority |
The map should include hidden consumers. A nightly export, dealer portal, quoting spreadsheet or analytics model can depend on behavior that the storefront team never sees. Trace reads and writes, inspect scheduled jobs and interview the people who resolve exceptions. A list copied from vendor documentation cannot prove which paths this implementation uses.
Turn each dependency into a migration object: current source, target source, transformation, validation method, owner, cutover wave and rollback treatment. That creates a work breakdown tied to evidence rather than a backlog of screens.
Capture an executable baseline
A baseline should let another team reproduce a decision without guessing how the old interface reached it. Store representative input and output pairs for rule evaluation, pricing, asset resolution, save and share, cart or quote submission and error handling. Include the application version, catalog revision, market, user role and time of capture. A screenshot is useful context, but it cannot carry a request payload, hidden state or downstream side effect.
Separate observed behavior from approved behavior. The old system may permit an invalid combination, apply a stale default or emit an event with a misleading name. Record what happened, then ask the product owner whether the target should preserve, correct or retire it. That choice belongs in an acceptance case with an approver, not in an undocumented developer assumption.
Keep a discovery evidence index. For each item, record its location, owner, sensitivity, retrieval method, checksum or version and the migration object it supports. Redact or synthesize restricted values for test fixtures while preserving the structure and decision boundary being tested. This makes gaps visible early: a claimed export without a schema, an asset folder without rights and revision data, or a pricing endpoint without failure examples is not yet a transferable contract.
Make data ownership explicit before moving data
For every product entity, declare one authoritative writer at each migration phase. Other systems may cache, index, transform or display the data, but they should not silently become competing masters. This matters most for identifiers, rules, price inputs, saved configurations and asset-to-product mappings.
Google Cloud's database migration guidance defines a consistent migration as complete, duplicate-free and ordered. It also warns that active-active writes need conflict-resolution rules, and that two client-side writes are separate transactions that can leave systems inconsistent when one succeeds and the other fails.[3] A configurator migration is broader than a database move, but the same failure shape applies when the old and new systems both accept edits.
Use a source-of-truth register with these fields:
- entity and durable identifier;
- current and target writer;
- read replicas and downstream consumers;
- export format and schema version;
- transformation and rejected-record policy;
- reconciliation query or checksum;
- retention, deletion and access owner;
- license or usage boundary for product imagery, fonts, models and other assets.
A successful export is not acceptance. Count records by entity and status, reconcile identifiers, sample transformed values and prove that a known source revision produces the expected target state. Keep raw exports immutable, store transformation code under version control and record rejected rows rather than dropping them. For saved configurations, decide whether old links will be translated, opened through a compatibility path, frozen as read-only records or retired with an explicit user-facing response.
Create target contracts and coexistence seams
The replacement needs a stable boundary before it needs a complete interface. Define versioned contracts for catalog input, rule evaluation, pricing, asset resolution, save and share, cart or quote output, analytics and operational health. Include timeouts, error shapes, idempotency and ownership, not only happy-path fields.
Parallel change provides a useful model for incompatible interfaces: expand to support old and new forms, migrate consumers, then contract by removing the old form. The pattern lowers risk by letting clients move incrementally, but it also warns that failing to finish the contract phase can leave the system worse than it started.[2] Give every temporary endpoint, adapter and field an owner and removal condition when it is introduced.
A staged replacement can route a bounded capability to the new system while the rest stays on the old one. AWS describes this as incremental replacement through a proxy, with an adapter or anti-corruption layer translating old calls to a new interface. Its guidance also notes that the routing layer can become a bottleneck or single point of failure, and that synchronized stores may introduce redundancy and eventual consistency.[1]
Apply that pattern to the configurator without assuming it must become microservices. A seam might route one product family, rule domain, asset resolver or save function. Keep translation at the boundary so target concepts do not leak back into every legacy caller. Measure the seam itself, test failure behavior and remove it after all consumers have moved.
Prove behavior in parallel, not by visual resemblance
Build a golden configuration corpus from real product logic without copying restricted customer data into an unsafe environment. Include common selections, boundary cases, known invalid combinations, retired components, localization, price-sensitive cases, saved links and integration failures. Give every case a stable ID and expected decision.
Run the old and new evaluators against the same controlled inputs where authorization and architecture permit it. Compare observable outputs rather than implementation details:
| Test surface | Compare | Do not accept as proof |
|---|---|---|
| Rule result | Available choices, defaults, exclusions and reason codes | The same final screenshot from one path |
| Commercial result | Product ID, components, quantity, price or quote payload and currency | A total with no trace to its inputs |
| Visual result | Asset revision, material assignment, camera, fallback and critical geometry | Pixel identity across different renderers |
| Persistence | Saved ID, schema version, account binding, expiry and reopened state | A successful save that was never reopened |
| Integration | Request, response, side effect, retry and idempotency behavior | A 200 response with the wrong downstream state |
| Operation | Latency distribution, errors, logs, alerts and support handoff | A quiet dashboard with missing instrumentation |
Database-level equivalence does not replace client-level testing. Google's migration guidance says clients must be tested for business behavior because query and transaction semantics can differ even when data appears similar.[4] For a configurator, acceptance therefore belongs to a product decision: the same permitted state, the right commercial output, the intended asset and a recoverable side effect.
Treat differences deliberately. Classify each as a defect, an approved behavior change, an expected renderer variance or an unresolved exception. Record approver, evidence and release wave. Do not train the new system to reproduce an old defect merely to make a comparison report green.
Keep a cutover-risk register with executable responses
A risk register is useful only when it changes a release decision. Each row needs a leading signal, a preventive control, a stop or rollback condition, an owner and a link to evidence. The conditions should be written before the cutover window. Project thresholds belong in the release brief; this table does not invent universal numbers.
| Risk | Leading signal | Preventive control | Stop or rollback condition |
|---|---|---|---|
| Rule coverage gap | Golden cases lack an owner or expected result | Freeze the wave scope and complete rule approval | Any blocking case has no agreed target decision |
| Identity collision | One legacy ID maps to multiple active target entities | Validate mappings and quarantine ambiguity | An in-scope product resolves to the wrong sellable entity |
| Price or quote divergence | Reconciliation shows unexplained differences | Trace inputs, rounding and service version | A material unexplained commercial result reaches the release path |
| Asset mismatch | Product state resolves to an unapproved derivative | Lock asset manifest revisions to product IDs | Critical geometry, material or fallback is wrong in an in-scope state |
| Saved-link breakage | Historic links fail the compatibility corpus | Route by schema version or publish a retirement policy | An in-scope saved record cannot reopen as approved |
| Duplicate side effect | Retry creates two carts, quotes or CRM records | Require idempotency keys and replay tests | Duplicate or missing downstream action cannot be reconciled safely |
| Data divergence | Source and target counts or checksums drift | Keep one writer and run scheduled reconciliation | Drift exceeds the project's declared tolerance or its cause is unknown |
| Blind operation | Events, logs or alerts disappear during the wave | Validate observability before traffic moves | The team cannot see the release's agreed health and business signals |
| Unusable rollback | Legacy route, data or credentials have changed | Rehearse rollback with exact artifacts and owners | The known-good path cannot be restored inside the approved window |
Migration guidance from Google calls for an inventory, risk and mitigation list, functional and non-functional test plan, rollback steps and named governance in the runbook.[5] Keep this register beside the live cutover plan, not in a slide deck that operators cannot update.
Run a phased cutover with a maintained rollback state
Choose waves that limit coupling: one product family, region, channel or capability at a time. Before each wave, freeze its scope, snapshot code and data revisions, capture configuration checksums, verify credentials, warm the target path and confirm who can stop the release.
Move a controlled cohort, then read the agreed technical and business signals. Increase exposure only after the wave's acceptance evidence is complete. A traffic percentage alone is not a phase: name the products, integrations, data writer and support route it represents. Keep out-of-scope paths on the legacy system.
Rollback must restore more than the browser route. Google's execution guidance says to retest after rollback and reverse external changes such as upstream and downstream configuration as well.[5] Record DNS, cache, webhook, cart, quote, identity and job changes in exact reverse order.
If the target accepts writes, a simple route switch may no longer be enough. Google's database guidance explains that fallback after switchover can require migrating target changes back to the source, and that this reverse path must be designed and tested in advance.[4] Define the last safe rollback point, the reconciliation procedure after it and the authority to choose forward repair instead.
Finish the migration by removing transitional risk
Do not decommission the old platform when the first wave looks healthy. Wait until all in-scope consumers have moved, retained data is accounted for, saved-configuration policy is operating, support has a tested runbook and the rollback window has closed by an explicit decision. Archive required evidence, revoke obsolete credentials and remove temporary adapters, dual schemas and routes.
The next operating contract is covered in custom configurator maintenance: rule, asset, integration, browser, analytics and release checks after launch. If discovery confirms that the work needs an accountable implementation team rather than another platform comparison, the custom 3D product configurator service is the direct project route.
A replacement is complete when the business can explain where each decision now lives, prove the migrated behavior, operate it and recover from failure. A new skin on undocumented rules is only a second legacy system.
