Path to production question

Hi! 
This depends a lot on the size of the company, and or the complexity of their customizations. 

We’re probably in the middle of the pack as far as size and complexity goes, but I have a local Acumatica install that has the same version, data, and customization  as our production instance where I do all development on. Then once everything it working and tested there, I export the package and manually publish it to the production instance.

After publishing I test a few key screens just to make sure there were no major regressions, but that’s hardly necessary because I don’t know if I’ve ever really found anything since the dev site is pretty much a clone of production. 

I know larger companies will have anything up to full automated pipelines to push to production, rather than uploading and publishing manually. 

to your question of whether to publish directly to production, the answer is yes. Different tenants on the same instance share the same database schema and backend code, so you generally shouldn’t publish to a test tenant if you’re not ready to also publish to production. 

Whether you have developed your own customization, or are using some developed by a third party, it is always advisable to publish those to a non-production clone of your production instance for testing to make sure nothing breaks. 

To add to ​@MichaelShirk  excellent answer — short version: publishing directly to production is possible, but it's not the recommended path, and the reason comes down to how Acumatica isolates (or doesn't isolate) customizations.

The key thing to understand about tenants vs. instances: all tenants on the same instance share the same database schema and the same backend code. A customization isn't scoped per-tenant — when you publish, it applies to the whole instance. So a "test tenant" on your production instance is not a true sandbox for code; if a published customization alters the schema or breaks logic, every tenant on that instance is affected, production included. For testing customizations safely, you need a separate instance, ideally a clone of production (same version + customizations + a recent data copy).

A typical promotion path looks like this:

1. Develop on a local/dev instance (clone of prod).
2. Export the customization package and version-control it (Git).
3. Publish to a dedicated test/staging instance that mirrors production, and validate there.
4. Publish to production during a maintenance window, then smoke-test a few key screens.

On automation: smaller shops do step 4 manually (upload + publish), which is perfectly fine. As complexity grows, you can move to automated deployment using Acumatica's Customization REST API driven by a pipeline — Azure DevOps or GitHub Actions both work well. Gabriel Michaud (Velixo) did a great DevCon session on exactly this CI/CD setup if you want a reference implementation.

Bottom line: it's fine to publish to production directly as a mechanism, but always test on a non-production clone first — whether the customization is yours or from a third party

Hi Michael, 

I appreciate the response. Just to be sure I understand you correctly, you have a separate instance (install) that isn’t tied to your production and test tenant instance?

Thanks,

Brian