Skip to main content
Question

Deploying changes between Tenants

  • August 25, 2026
  • 4 replies
  • 39 views

We currently maintain separate Tenants within Acumatica for maintaining different testing environments, i.e., Production, UAT, DEV, etc. At this stage when we need to promote changes we have tested to either preferences, settings, other configuration, and customisation through code, we currently manually redo this in the target Tenant, thereby migrating the changes.

Unfortunately, this obviously raises the risk of human mistake i.e., missing something, making wrong changes, etc and takes much longer than some other platforms I’ve worked with i.e., Salesforce where we could promote changes either via automated tooling like change-sets or a full CI/ CD pipeline connected to a repo.

Does anyone know of a much better method for promoting changes between tenants, because from what I understand migrating via published customisation projects, or via setting only snapshots doesn’t cover all settings, etc.

Disclaimer - My primary focus is about MYOB Acumatica - so single cloud environment, with limited ability to maintain a complete separate series of sites to handle a traditional UAT/ DEV workflow.

4 replies

alanconroy31
Freshman II
  • Freshman II
  • August 26, 2026

Hi Brendan,

There's no change set equivalent in Acumatica.

There's a github project looking at the config as code idea. https://github.com/kborovik/acumatica-cli   tenant configuration as YAML in git, with apply and diff-for-drift running against the contract REST API. It might be something to look at or have a chat with Konstantin who wrote it.

 


Naveen Boga
Captain II
Forum|alt.badge.img+20
  • Captain II
  • August 27, 2026

@btsrBrendanC   I agree that manually migrating configuration and settings between tenants can introduce a significant risk of missing or incorrectly applying changes.

In my experience with Acumatica, Customization Projects are useful for managing code and customization changes, while Snapshots can help with many configuration/data components, but neither necessarily provides a complete change-set/CI-CD experience for every type of configuration.

For a more reliable promotion process, I would recommend separating the deployment into customization/code changes and configuration changes, and using version-controlled customization projects along with a documented/automated process for the remaining configuration items. For MYOB Acumatica in particular, the available options may be more limited because of the single-cloud-environment model.

I’d also be interested to hear if anyone has implemented a more automated Dev → UAT → Production promotion process specifically for MYOB Acumatica.


  • Author
  • Freshman I
  • August 27, 2026

Hi Brendan,

There's no change set equivalent in Acumatica.

There's a github project looking at the config as code idea. https://github.com/kborovik/acumatica-cli   tenant configuration as YAML in git, with apply and diff-for-drift running against the contract REST API. It might be something to look at or have a chat with Konstantin who wrote it.

 

Thanks ​@alanconroy31 - Yeah this is exactly what I’m looking for. Time to start trawling through Konstantin’s code and seeing how it works.

 

@btsrBrendanC   I agree that manually migrating configuration and settings between tenants can introduce a significant risk of missing or incorrectly applying changes.

In my experience with Acumatica, Customization Projects are useful for managing code and customization changes, while Snapshots can help with many configuration/data components, but neither necessarily provides a complete change-set/CI-CD experience for every type of configuration.

For a more reliable promotion process, I would recommend separating the deployment into customization/code changes and configuration changes, and using version-controlled customization projects along with a documented/automated process for the remaining configuration items. For MYOB Acumatica in particular, the available options may be more limited because of the single-cloud-environment model.

I’d also be interested to hear if anyone has implemented a more automated Dev → UAT → Production promotion process specifically for MYOB Acumatica.

@Naveen Boga - when you talk about version-controlled customisation projects - I’m assuming this is simply customisation projects managed separately through a git based repo/ versioned environment and manually uploaded/ applied to the target tenant/ environment correct? 


Naveen Boga
Captain II
Forum|alt.badge.img+20
  • Captain II
  • August 27, 2026

@btsrBrendanC  Yes, that's correct. I’m referring primarily to keeping the customization projects/source code in a Git-based repository with proper version control, so we can maintain and track changes across environments. The resulting customization package would then be published/applied to the target tenant as part of the deployment process.

This helps significantly with managing and promoting code/customization changes, but configuration and other tenant-specific settings would still need to be handled separately, unless they are included through snapshots or another deployment mechanism.