Demo and proof tenant builds

Every pitch leaves the demo tenant a little worse. Rebuilding a clean distribution, manufacturing, construction, or field-service demo by hand costs your pre-sales team days it does not have.

You get. Industry demo tenants rebuilt on demand — from empty to fully populated with realistic, linked transaction history: orders tie to customers, invoices to orders, payments to invoices. For a live prospect, the same build can be seeded from their own books so they see their business in Acumatica, not a canned demo.

I rebuild Acumatica demos from seed and scenarios.

“Why not just restore an Acumatica tenant snapshot?”

Often you should restore a snapshot — and any answer that starts by dismissing snapshots is not worth reading. An Acumatica tenant snapshot copies the database rows, so the restored tenant matches the source tenant’s transactions. Restoring a snapshot is faster than reloading the same data through the API. It also includes objects that have no REST endpoint. To move one tenant to one place, once, restore the snapshot. The trouble starts when you need that restore again.

• →Tied to one Acumatica version. The snapshot’s Acumatica version must match the destination instance exactly — earlier or later is rejected. After every Acumatica release, every partner recreates every demo snapshot by hand.
• →No drift detection. Acumatica has no native diff between a snapshot and a live tenant: no report, no exit code, nothing a release gate can read. Nobody can tell you what last week’s pitch changed in the live demo tenant.
• →All-or-nothing, and destructive. A restore overwrites the target tenant. You cannot push three new item classes into a tenant a prospect is already sitting in — it is the whole snapshot or nothing.
• →Not automatable. There is no supported REST path to create, export, import, or restore a snapshot. The extended-endpoint command returns 204 and creates nothing, the vendor’s answer was “use the Test SDK,” and the request was still open as of September 2025.
• →A scheduled outage. On 2025 Acumatica versions, copying a company or creating a snapshot forces a system lockout with no bypass. Refreshing a demo now means booking downtime for that instance.
• →A size cliff at 1 GB. Import through the web UI stops at 1 GB. Past that limit you are in the Configuration Wizard, moving raw XML by hand.
• →Not reviewable. XML mode is technically diffable, but it is thousands of database tables of row state. Nobody reviews that XML before a release, merges two people’s work into it, or uses it to answer who changed what.
• →One shape per snapshot. A snapshot freezes one transaction history. You cannot vary the industry flavour, extend the history, or replay it against a newer Acumatica version — you create another snapshot, by hand, and the cycle starts again.

A snapshot freezes one tenant state. What this offer delivers is rebuild-from-source: a repository that produces a new demo tenant. Restore a snapshot and you get last quarter’s demo; rebuild from source and you get a demo shaped for the pitch you are walking into, on the Acumatica release your prospect is buying.

Same loop under every offer: version → rebuild → exercise → report.

Nothing installs inside Acumatica. Nothing for you to keep running.

→Demo without the afternoon rebuild

Minutes, not a day: clean company, linked transactions already in it — same rebuild next week when the pitch goes sideways.

→See what is actually configured

Live tenant extracted to Git; agreed config versus live, sandbox versus production — ranked lists, no writes.

→Catch breakage before production

Business scenarios on an upgraded copy. Failures name the step — not a customer on the phone.

→Cutover becomes a rehearsal

Rebuild, load, exercise, recon, tear down — repeat until go-live is boring and the controller has a trail.