Implement Vendor Updates

Workflow 4 of 5. The vendor shipped a new version of the app you bought. This is how you take it in safely — whether or not you’ve customized the app — without losing work or corrupting the database.

The danger is simple to state. A vendor update is a fresh copy of their code. If you drop it straight on top of yours, it overwrites the files you edited and you lose hours of work. The whole point of the customization system (Workflow 3) was to keep your changes in update-safe homes so a new release can pass through cleanly. This playbook is where that investment pays off.

The core idea

Treat the new release as a known quantity before you apply it. You compare the new schema against your frozen author-vX.X.X snapshot to see exactly what will change in the database, apply the vendor files on a throwaway branch so the work is reversible, then re-run your restore script so your overlay and your ZajModules land back on top. Nothing is a surprise; everything is undoable.

flowchart LR
  A["New vendor<br/>release"] --> B["1 · Compare<br/>schema diff"]
  B --> C["2 · Apply update<br/>on a branch"]
  C --> D["3 · Restore your<br/>customizations"]
  D --> E["Verified app —<br/>nothing lost"]

Why this order matters: comparing first tells you whether a migration will quietly drop a column or table, so you can back up before — not after — the damage. Applying on a branch keeps your live code untouched until the update is proven. Restoring last re-applies the overlay that composer install always reverts to vanilla.

The three steps

1 · Compare the schema Diff the new release against your frozen author snapshot with Atlas, classify every change by risk, and stop on any destructive operation.

2 · Apply the update Tag a backup, create the author branch, drop in the vendor files, then merge and run migrations safely on a branch you can throw away.

3 · Restore customizations Re-apply your vendor-customizations overlay with the restore script, confirm ZajModules survived untouched, and verify nothing was lost.

This playbook builds directly on Implement Customizations (Workflow 3) — the _zaj tables, ZajModules, and the vendor-customizations overlay are what make a vendor update survivable. If you skipped that, read it first.

For security-only package bumps (composer audit / npm audit) with a rollback gate — not a full vendor release — use the Security package update runbook.

See everything in this collection

Every page in this CodeCanyon topic lives under /tech-stack/laravel/codecanyon/ — the exhaustive cross-shelf index.

Ready? The first move is always to look before you leap:

→Start here

Compare the schema