A rollback strategy is what you fall back on when a customization publish or an ERP version upgrade doesn't go the way the sandbox run suggested it would. Acumatica gives you a few distinct rollback mechanisms — database snapshots, customization unpublish/revert, and full restores from scheduled backups — and they are not interchangeable. Picking the wrong one, or not having one ready before you start, is how a ten-minute publish turns into a weekend.
Snapshots are the primary safety net
Before any risky production change — a major customization publish, a version upgrade, a bulk data import — take a database snapshot. On self-hosted instances this is done through the Instance Manager; on Acumatica Cloud it's the snapshot feature in the cloud portal. Either way, you get a point-in-time copy of the tenant database that you can restore to if the change goes wrong.
Snapshots should be tied to events, not a calendar. A nightly snapshot schedule is fine for general safety, but it's not a substitute for taking one immediately before you touch production. The snapshot you need is the one from five minutes before the bad publish, not the one from last night.
Customization rollback is not data rollback
If a bad customization is causing errors but hasn't corrupted any data yet, unpublishing it — or reverting to a previously exported version of the project via the Customization Projects screen — is the fastest fix. It's a code-level change, it doesn't touch the database, and it typically takes effect in seconds.
The trap is assuming that unpublishing "undoes" everything. It doesn't. If the broken customization already posted a GL batch, released a document, or wrote bad values into a DAC field while it was live, unpublishing removes the code but leaves the data damage in place. At that point you're not choosing between customization rollback and DB restore — you need the restore, and the customization fix is a separate, second step.
Restoring to a pre-publish snapshot reverts every transaction entered since that snapshot was taken — including legitimate work from other users. If detection takes two hours, you lose two hours of real invoices, receipts, and GL entries along with the bad data. Lock users out during risky publishes so the detection-to-rollback window doesn't quietly grow the blast radius.
Upgrade rollback is higher stakes than a customization rollback
Version upgrades touch schema, stored procedures, and every customization in the instance at once, so there's no equivalent to "just unpublish it." The only realistic rollback for a bad upgrade is a snapshot restore to the pre-upgrade state, which means the snapshot has to exist and be verified before you start.
Test the upgrade path on a cloned or sandbox instance first, not because it guarantees production will behave identically, but because it surfaces the customizations that won't survive the upgrade untouched — deprecated APIs, changed DAC fields, generic inquiry breakage. Fix what you can find there so production only has to absorb the unknowns.
After the upgrade completes, use a documented go/no-go checkpoint — smoke-test the core screens and any customization-heavy workflows — before opening the instance back up to all users. That checkpoint is what keeps the decision to roll back from being made three hours later with three hours of new data at stake.
A basic pre-deployment checklist
The pattern doesn't need to be elaborate. It needs to be followed every time, including the times it feels unnecessary.
# Before a production customization publish or upgrade
1. Announce a maintenance window, lock out non-admin users
2. Take a snapshot via Instance Manager (self-hosted) or
the cloud portal snapshot tool (Acumatica Cloud) — confirm
it completed and note the snapshot name/timestamp
3. Export the current customization project(s) as a backup
.zip from the Customization Projects screen
4. Publish / run the upgrade
5. Run the go/no-go smoke test against core screens and
any customization-dependent workflows
6. If it fails: unpublish/revert customization first if no
data was written; restore the snapshot if data was
already touched
7. Only reopen the instance to all users after the checkpoint
passesChoosing the right rollback option
Each rollback mechanism trades recovery time against how much you lose. Match the option to what actually broke.
| Option | Recovery time | Data loss |
|---|---|---|
| Unpublish / revert customization | Seconds to minutes | None, if no bad transactions were posted while it was live |
| Snapshot restore | Minutes to an hour, depending on database size | All changes since the snapshot, including legitimate ones |
| Full DB restore from scheduled backup | Longest — often involves infrastructure/ops, not just Acumatica | Everything since the last backup, potentially a full day |
That is the working approach I use on Acumatica rollback planning. The same discipline applies whether the client is in Nairobi, Johannesburg, Kigali, Lusaka or Harare — snapshot before you touch production, know the difference between a code rollback and a data rollback, and don't let a slow detection turn a small mistake into a lost afternoon of real transactions. If you're setting up a rollback plan for an upcoming upgrade, reach out or browse more on the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.