Acumatica live company to rebuildable UAT: extract, config twin, scenario gate

TLDR

Every production Acumatica company needs a UAT twin; today that copy is usually hand-built or stale, and nobody can prove it is ready for testers the same way twice. Extract live configuration into a Git tree you own, rebuild a virgin UAT as a configuration twin, run a linked scenario package as the readiness gate, and close with a clean config diff plus Account Summary books. That path is the paid land outcome under Acumatica tenant → Configuration-as-Code — method and tooling under an engagement, not a product you install and run alone.

Hand-built UAT cannot prove readiness twice

A second environment built from memory and screenshots drifts until something breaks, and there is no machine-checkable gate that the rebuild is ready for testers.

Production holds the only complete company setup after years of click-through change. Sandbox and UAT are often partial copies, last-quarter snapshots, or re-keyed approximations. When a release, integration, or process change needs a clean test surface, the team either risks production-adjacent testing or spends another cycle rebuilding UAT by hand. Snapshot restore copies database state, including open documents and history you may not want on a tester surface — and it still does not produce a reviewable configuration tree in Git.

The configuration-as-code post covers the greenfield loop: desired YAML in git, acu apply, acu diff. This post is the brownfield land path: start from a live company, extract, rebuild UAT on demand, and prove readiness with a scenario gate.

Extract production configuration into Git over REST

One read-only extract writes company, chart of accounts, masters, and related setup into a versioned tree under config/ — reviewable in a pull request, not a PDF dump that goes stale.

On a production stand-in (film uses tenant LAB5), extract is REST read against the live company:

acu --tenant LAB5 extract --out . --force

The emit lands in config/{bootstrap,baseline,setup,master}/ in dependency order — the same layout the configuration-as-code substrate applies. Nothing writes back to production on this step. The durable work product is the private Git repository the customer owns, not a one-time audit attachment.

Capture production books as evidence, not a load pack

acu state records derived trial-balance observations for the findings report; it does not import production money or open documents into UAT.

acu --tenant LAB5 state --out state/prod

State files sit beside the seed as evidence. They answer “what did production books look like when we extracted?” without turning UAT into a production database clone. Production history stays on production.

Virgin UAT receives the extracted tree

Stand up an empty company on purpose, then apply the extract so UAT is a configuration twin of production — same setup from files, not a restored snapshot.

acu tenant create --login UAT
acu --tenant UAT apply config/

tenant create produces a clean login with zero companies until apply runs. Apply walks bootstrap → baseline → setup → master as idempotent upserts. UI proof after apply shows the company and chart of accounts from the extract — for example the filmed LAB5 Electronics company and Checking Account on the COA.

Configuration alone is not enough for testers. They need sample document chains on day-one paths, not only empty masters.

Scenario folder is the UAT readiness gate

acu run scenario/ posts a linked exercise path — seed capital, buy, build, sell, collect — so exit zero means testers can open real document chains on this rebuild.

acu --tenant UAT run scenario/

Scenarios are package exercise data, not a clone of production transactions. They leave sales orders, closed supplier bills, and related history the tester can open — the same readiness story the service walkthrough films. If the gate fails, the fix is in the seed, the scenario pack, or the extract fidelity — not an unreproducible click path on a one-off UAT.

The single-tenant regression gate post describes apply / run / diff as ongoing change control. Here the same run step is the handoff gate: config twin plus green scenario package equals UAT ready for testers.

Diff and Account Summary close the proof

After scenarios, acu diff must stay clean on configuration, and Account Summary shows exercise books — scenarios post documents without drifting the extracted tree.

acu --tenant UAT diff config/
acu --tenant UAT state --out state/uat

Diff exit 0 means the live UAT configuration still matches the extract after the exercise. State under state/uat captures UAT trial balance separately from state/prod. Account Summary (GL401000) is the UI close: checking and peer accounts reflect sample history, company/branch filters use the extracted company code, and the handoff is “UAT ready” rather than “someone finished clicking setup.”

When production setup changes, re-extract and rebuild from the same tree — the engagement product is the repeatable path, not a one-time screenshot pack.

Scope boundaries: config twin, not database clone

Extract and apply move catalog configuration; scenarios supply linked test history; neither is a production snapshot restore or a multi-year document import.

Surface	What it is	What it is not
`acu extract` / `acu apply`	Configuration seed (company, COA, masters, setup)	Production database clone
`scenario/`	Scripted UAT exercise path for testers	Production open documents or multi-year history
`acu state`	Derived balance observations for evidence	A load pack that imports money
UAT outcome	Config twin + green exercise gate	Proof that every production edge case is covered

Raw production extracts that diverge from the demo package need a shrunk scenario pack or a findings pass before the readiness gate claims “green.” Findings (configured, undocumented, drifted, custom) remain part of the paid engagement; this post shows the rebuild path the extract enables.