Before choosing an ecommerce migration partner, request seven artifacts: a dependency map, a matrix of order-state ownership, checkout behavior contracts, a reconciliation report, a cutover plan, a recovery runbook, and release acceptance criteria. Together, they should show how the proposed team will protect purchasing and order processing while the platform changes. At the selection stage, a redacted example and a credible plan for adapting it may be appropriate. Before production cutover, the retailer needs completed, reviewed evidence specific to its own operation.
This distinction matters in procurement. A polished architecture presentation can describe the destination without explaining what happens to an order placed during the move. A successful demonstration can show a purchase reaching a confirmation page without establishing that the warehouse received it. The seven artifacts connect the partner's proposal to decisions that engineering, finance, and operations will eventually have to make.
Start With the Transactions the Business Cannot Lose
Define continuity in terms the business can inspect. For a retailer, that may mean accepting an eligible purchase, associating it with the correct payment, handing it to fulfillment, and preserving the ability to cancel or refund it under the applicable business rules. A storefront can remain reachable while one of those steps is failing. Availability alone therefore makes an incomplete acceptance condition.
Build the evaluation around a small set of representative journeys. Include a routine purchase and at least one purchase with a complication that matters to your operation: a split shipment, an approval requirement, an expired reservation, or a payment response that arrives late. Use your actual policies to define the expected outcome. The purpose is to expose decisions that a generic demonstration can avoid.
For each journey, identify who could confirm completion. Customer support may verify what the shopper sees, but finance must interpret the payment record and fulfillment must confirm acceptance downstream. Bring those people into the review. Their involvement turns an abstract promise to preserve operations into a set of observable business conditions.
Ask for a Dependency Map and a State-Ownership Matrix
1. A dependency map that includes failure behavior
The first artifact should show the systems involved in the selected journeys and the connections between them. Include the storefront, payment provider, order management system, enterprise resource planning system, inventory services, and any other component that can block acceptance or fulfillment. Record what crosses each connection, how acknowledgment works, and which team owns it.
A useful map also identifies delayed work: scheduled imports, queued messages, partner callbacks, and manual approvals. During the vendor review, choose one connection and ask the team to trace a failed handoff. The map should make it possible to identify the affected business process, the evidence available to diagnose it, and the person who can authorize recovery. Assign someone to keep the map current as discovery reveals missing dependencies.
Where a dependency belongs to a third-party provider, record the support route and any limits on access or testing. Otherwise, the migration schedule may assume that an external team will change a configuration or investigate an incident without an agreed commitment.
2. A matrix of authority over order states
A system diagram does not explain who has permission to change an order. The second artifact should assign authority to specific transitions, such as accepting an order, confirming payment capture, releasing fulfillment, and recording a refund. It should distinguish the system requesting an action from the system confirming that the action occurred.
Test the matrix with a hypothetical conflict: a shopper requests cancellation while the warehouse is accepting the order. Which system determines whether cancellation is still possible? What does the other system display while the outcome is unresolved? A credible answer needs an agreed rule and an exception owner. Naming a database as the source of truth does not settle that operational question.
Request Checkout Contracts and a Reconciliation Report
3. Checkout contracts expressed as observable behavior
Here, a contract means an agreed description of what checkout must do under defined conditions. It should specify the starting state, the customer's action, the expected system response, and the business records that must result. Cover rejected payments, unavailable inventory, repeated submissions, and an interrupted response where relevant. Each condition needs evidence beyond a screenshot.
For a delayed payment response, for example, require the team to explain how it distinguishes a confirmed rejection from an unknown outcome. The test should show what the customer sees, where the unresolved transaction is recorded, and how the team establishes the eventual result. Avoid acceptance language that simply says retries work. The contract must identify which operation is being retried and what duplicate effect the design must prevent.
4. A reconciliation report that exposes exceptions
Reconciliation means comparing relevant records and explaining differences. Request a sample report containing stable order identifiers, amounts, currencies, payment states, and evidence of downstream acceptance. Historical data and orders created during cutover may require different checks. Make the boundaries of each comparison visible so reviewers know what a clean result actually covers.
Matching record counts should be one check among several. Two datasets can contain the same number of rows while including a duplicate and a missing order. A useful report identifies unresolved mismatches, their age, assigned owners, and the evidence required to close them. During evaluation, the partner should be able to explain an intentionally introduced discrepancy and demonstrate that the report detects it.
Review the Cutover Plan, Recovery Runbook, and Release Gates
5. A cutover plan with decision points
The cutover plan describes how responsibility moves from the old environment to the new one. It should cover traffic routing, active customer sessions, continuing data changes, third-party integrations, and the order in which dependencies are switched. Every major step needs a prerequisite, an owner, and a check that confirms completion.
Look for explicit decisions to continue, hold, or stop. A timeline alone is inadequate when a prerequisite fails. The retailer should be able to see what remains live during a hold, who handles existing orders, and how the next decision is made. Any proposed low-traffic window must still account for customers and systems that continue operating during it.
6. A recovery runbook that preserves accepted business
The recovery runbook should separate returning an application to a previous version from resolving orders, payments, and fulfillment actions already accepted. Require a list of actions that the team can reverse directly, actions that require an authorized compensating operation, and outcomes that need investigation before further processing.
Give the vendor a rehearsal scenario involving an order placed after the new release went live. Its recovery explanation must preserve that order's identity and account for external actions already taken. The runbook should also name the person who communicates with customer support. Restoring a technical component is only part of restoring a business process that people must explain to customers.
7. Release gates with named approvers
Release gates translate the previous six artifacts into an approval decision. They should identify required tests, reconciliation status, unresolved risks, monitoring coverage, and operational readiness. Each condition needs an owner and a clear result. If an exception can be accepted, record who has that authority and what restrictions accompany the decision.
Set thresholds around your business exposure and ability to respond. There is no useful universal allowance for unresolved orders that fits every retailer. Distinguish a known display delay from an unexplained financial mismatch. The approval record should preserve that reasoning, including the affected population and the next review point, rather than compressing unlike problems into one green status.
Separate evidence into three categories in your evaluation notes: completed work the vendor can explain, an illustrative sample, and a commitment to deliver something later. All three have a legitimate place during selection, but they carry different weight. Record when the project-specific version becomes due and how acceptance affects the next phase of work.
Zoolatech's Salesforce B2B migration case describes historical-data migration and custom integrations. It does not establish all seven artifacts or measured order continuity. Use that background to frame a deeper discussion: which relevant examples can the proposed team explain, and how would it adapt its approach to your order flows?
When evaluating ecommerce migration services, make these artifacts part of the scoping conversation. Agree on the responsibilities of the retailer and the delivery team, including access to existing systems and the availability of business reviewers. A deliverable cannot resolve a decision that nobody on the client side is authorized to make.
Frequently Asked Questions
What should an ecommerce migration partner show before we sign?
Request relevant examples of its mapping, testing, reconciliation, cutover, and recovery work, together with a plan for creating your project-specific artifacts. The vendor should explain who produces each deliverable and who approves it. Before signing for implementation, clarify what discovery must establish and which unresolved assumptions could change the scope.
How can we verify that a migration team understands order continuity?
Have the team trace a representative order through an interruption, including payment confirmation and fulfillment acceptance. Review what each system knows, how unresolved outcomes are found, and who acts on exceptions. The explanation should connect to testable behavior and business records. A successful storefront demonstration alone cannot answer all those questions.
Which migration deliverables need business approval?
Business owners should approve the expected purchasing and order outcomes, exception policies, and conditions for moving traffic. Finance and fulfillment need input where payment or delivery obligations are affected. Engineering approves the technical implementation. The release decision should combine those responsibilities and record any accepted risks with a named owner.
Discuss your checkout dependencies, order flows, and required acceptance evidence with Zoolatech.