Skip to main content

Upgrade Vendorzo

Upgrade only to a release listed as supported in its compatibility notes. Review the release notes for schema changes, required actions, and any irreversible data normalization.

  1. Test the release against a recent, isolated restore using the same edition, database engine, integrations, and customization as production. Disable outbound payment, messaging, courier, and payout effects in that copy.
  2. Take and verify pre-upgrade database and media backups. Keep environment configuration protected and record the current release and edition.
  3. Obtain the archive verifier and public key through a trusted channel independent of the unverified archive. Verify the detached archive signature before extraction, then extract to a new release directory. The standard archive places application files under web/.
  4. Verify the extracted release-manifest.json against the trusted key and confirm the signed edition matches the installed deployment. Attach the existing .env and shared uploaded media to the new release using the installation's deployment procedure; the release archive includes its locked Composer dependencies.
  5. Place the site in maintenance mode and stop affected queue workers. Run the release's documented migrations with php artisan migrate --force during the planned maintenance window. Do not run key:generate or the first-install merchant:install command on an existing store.
  6. Run php artisan commerce:edition-check, rebuild only the caches required by the installation, and verify edition-specific workflows before switching traffic.
  7. Switch releases using the installation's deployment method. Restart only the workers that need the new code.
  8. Resume traffic and workers only after the release is switched. Verify admin login, storefront, product, cart, checkout, payment callbacks, fulfillment, reports, sitemap, queues, and error monitoring before ending the maintenance window.

Upgrade sequence from backup and edition checks through archive verification, release staging, migration, cutover, and post-switch testing.

Do not use migrate:rollback as a production recovery plan. Some data migrations are intentionally irreversible. If a migration fails, keep the site in maintenance mode and restore the verified pre-upgrade database backup before reopening traffic. If a release is defective after migrations complete, return to the prior code only if it remains compatible with the migrated schema. Use the verified recovery procedure when both code and database must be restored.

Marketplace is an additive upgrade from Merchant. Installing a Marketplace artifact does not make a downgrade safe; Marketplace-to-Merchant downgrade is unsupported.