Acumatica tenant → Configuration-as-Code
For practice leads and ERP owners · Read-mostly access
Your hand-configured live Acumatica company is the only complete UAT surface — and there's no way to rebuild it on demand. Which settings are custom, which drifted from standard, and which no one has documented?
You get. A rebuildable UAT company from the live one: full configuration extracted into a Git repository you own, plus a findings report — configured, undocumented, drifted, custom. Rebuild the same company from that tree whenever you need a clean test surface. That extract is the base for business scenario validation, drift reports, release gates, and cutovers later.
I turn a hand-configured live Acumatica company into rebuildable UAT — extract, findings, on-demand rebuild from the same tree.
the obvious question
“Why not just copy the live Acumatica company into a test tenant and call that UAT?”
Copying a company is fast when you need production-like data for a one-off investigation. For a single look at today’s row state, a tenant copy is often the right tool.
- A copy is not rebuildable desired state. You get another database full of row state — not a versioned configuration tree you can rebuild, review, or merge. Next quarter’s UAT is another full copy, not apply-from-source.
- No findings on what is custom, drifted, or undocumented. A tenant copy does not tell a practice lead which settings are intentional, which drifted from standard, and which no one has documented. That triage still happens by clicking screens.
- No durable base for drift, scenarios, or cutover later. Without an extract the buyer owns, weekly drift, business scenario validation, and cutover rehearsal each start from scratch instead of the same configuration tree.
Copy a tenant when you need a quick data twin once. Use live company → rebuildable UAT when you need extract, findings, and a company you can rebuild from Git on demand.
how it works
Name the live company → extract to Git → findings → on-demand UAT rebuild — one configuration tree.
Nothing installs inside Acumatica. This is an engagement on a named company, not a Configuration-as-Code product you install and run alone. Configuration-as-Code is the category and method; the paid land outcome is rebuildable UAT.
- Name the live hand-configured company
- You name one Acumatica company (sandbox preferred; production only when sandbox is not representative) and a credentials owner. Read access is enough for the extract — no production write on this step.
- Extract full configuration into Git you own
- Full tenant configuration is extracted into a private Git repository you own — screens, settings, and structure as versioned files, not a click-through map only. That repository is the durable work product, not a PDF dump that goes stale.
- A findings report — configured, undocumented, drifted, custom
- Alongside the extract: what is configured, what is undocumented, what drifted from standard, and what is custom. The report is for the practice lead or ERP owner who has to decide what to keep, change, or leave alone next.
- UAT you can rebuild on demand from the same tree
- When a lab or non-prod path is in the SOW, the same tree rebuilds a clean company from the extract — not re-clicking years of setup. That rebuildable UAT surface is the land outcome and the base for business scenario validation, drift reports, release gates, and cutover later.
Work product stays in your repository. Extract is read-mostly on the source company; rebuild writes only to an agreed non-prod path. Same configuration tree, next engagement steps.