Hello,
We’ve been live on Acumatica for just over a month. One issue we’ve been encountering is the path to production process for customizations.
Is it standard practice for Acumatica developers to publish code directly to the production environment and to test tenants instead of promoting code through the test environments to production after testing?
Best answer by MichaelShirk
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.
+8Hi!
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
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:
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!
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.
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
+8
Are you interested only in having a safe place to test third part customizations, or also to develop your own customizations?
Are you interested only in having a safe place to test third part customizations, or also to develop your own customizations?
Hi Michael,
We’re looking for a place to test 3rd party right now.
Hello,
We’ve been live on Acumatica for just over a month. One issue we’ve been encountering is the path to production process for customizations.
Is it standard practice for Acumatica developers to publish code directly to the production environment and to test tenants instead of promoting code through the test environments to production after testing?
Best practice is to have either a locally hosted site with your data from a backup or an Acumatica hosted Sandbox.
Especially, when code is involved I would heavily discourage to publish directly to production to avoid operational disruptions or fatal errors.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
