Replatforming
Part of Ecommerce vendor and agency evaluation
Reviewing post-launch support arrangements
Review ecommerce support agreements through incident ownership, covered systems, service hours, response targets and supplier handoffs.
Review support by tracing a likely store problem to the people who must resolve it. Compare written coverage, service hours, response process and supplier handoffs with post-launch operations.
Follow an incident across suppliers
Use a concrete case: customers can pay, but paid orders do not reach fulfilment. Ask who receives the alert, checks the commerce and payment records, contacts the integration supplier, updates staff, and confirms recovery.
Repeat with a product that cannot be bought and with a routine change that fails.
Name a first responder and a resolution owner for each case. The platform vendor, agency, app developer, payment provider and host may control different parts. The merchant still needs a contact to coordinate its customer-facing answer.
| Arrangement | Question for the written agreement |
|---|---|
| Coverage | Which platform, theme, code, apps, feeds and environments are covered? |
| Hours | When can staff report an issue, and when will someone work on it? |
| Priority | Who sets severity, using what evidence? |
| Handoff | Who contacts another supplier and follows the case to resolution? |
| Targets | Is the promised time for acknowledgement, investigation or restoration? |
| Changes | Which updates, checks and fixes are included or separately quoted? |
| Exit | Which access, configuration notes and open issues will be handed back? |
Ask what happens when a third party is responsible, and whether the stated target or reporting duty changes. Read exclusions beside the service description.
Post-Launch Support Arrangement Criteria
- CoverageWhich platform, theme, code, apps, feeds and environments are covered?
- HoursWhen can staff report an issue, and when will someone work on it?
- PriorityWho sets severity, using what evidence?
- HandoffWho contacts another supplier and follows the case to resolution?
- TargetsIs the promised time for acknowledgement, investigation or restoration?
- ChangesWhich updates, checks and fixes are included or separately quoted?
- ExitWhich access, configuration notes and open issues will be handed back?
Incident Response Workflow Across Suppliers
- Alert ReceivedPlatform vendor or monitoring tool detects issue (e.g., payment processed but no order in fulfilment)
- Initial DiagnosisMerchant’s first responder checks commerce and payment logs; identifies integration failure
- Supplier ContactContact integration provider or app developer; escalate if needed
- Resolution CoordinationResolution owner tracks progress across vendors; confirms fix and recovery
- Customer CommunicationMerchant contact delivers update to affected customers; closes loop
Check the vendor's support boundary
A platform subscription and an agency retainer can cover different work. Vendor documentation can set boundaries around theme and app support. Check the current guidance for the specific platform, theme and issue, because coverage can depend on those details.
WooCommerce.com's support policy covers products sold on WooCommerce.com, including some made by third-party developers. Customisation is not covered. WooCommerce advises a current backup and staging checks for updates; the merchant's agreement needs to name who will do that work.
Adobe Commerce on cloud infrastructure uses a shared responsibility model: the merchant retains duties for custom code, integrations and parts of its customised application. If an agency proposes that deployment, ask which duties it will accept. Vendor documentation does not establish an agency's contractual coverage.
Vendor Support Boundaries: Platform vs Agency
- Pros – Platform Vendor CoverageCovers core platform, official themes and apps; documented policies available (e.g., WooCommerce.com support policy)
- Cons – Platform Vendor CoverageExcludes custom code, third-party integrations, and site-specific configurations; merchant bears responsibility for backups and staging
- Pros – Agency RetainerCan include customisation support, deployment oversight, and coordination across suppliers
- Cons – Agency RetainerCoverage not defined by vendor documentation; must be explicitly stated in contract; may not cover all post-launch changes
Include normal changes and handover
List the changes staff expect: product updates, app updates, payment configuration, new delivery rules and seasonal promotions. Identify what staff can do themselves, what needs a support request and what needs a new quote. Ask how changes are checked and where the incident and change history will be kept.
The handover should locate the live configuration, access ownership, key contacts, known limitations and routine instructions. Ask how an unresolved launch defect enters the support process and whether correcting it remains part of the delivery commitment.
The arrangement is usable when staff know whom to contact, suppliers have agreed handoffs, and the merchant can retrieve the information needed if the relationship ends. Keep unconfirmed coverage visible during contract review.
Key Elements of Normal Changes and Handover
- Product UpdatesConfirmed whether merchant or vendor performs update; check for compatibility with existing customisations
- App UpdatesDetermine if included in support agreement or requires separate quote
- Payment ConfigurationVerify who manages gateway settings and compliance (e.g., PCI-DSS, GST reporting in Australia)
- Delivery Rules & PromotionsConfirm who configures seasonal rules and how testing is managed
- Handover DocumentationEnsure live configuration, access credentials, key contacts, known limitations and routine instructions are transferred
- Unresolved Launch DefectsClarify whether fixing them remains part of delivery commitment or requires new work
