Blue-green deployment is a well-understood pattern for stateless web apps, but Acumatica is not stateless — it is an application tightly coupled to one SQL Server database whose schema is versioned with the build. That single fact reshapes the whole pattern. You can run two application sites, blue and green, but they cannot point at two independent copies of live data without a plan for reconciling what changed while you were validating green. This is how blue-green realistically works for a self-hosted Acumatica instance, and where it stops being worth it.
What "blue" and "green" actually are
Blue is your current live Acumatica site, serving users. Green is a second, identical site — same version, same customizations — that you upgrade or publish the new customization set into. Users keep hitting blue. Once green is validated, you flip the switch (a load balancer rule, a DNS change, or an IIS binding) so traffic goes to green. Blue stays up, untouched, as your rollback. The appeal is obvious: the risky part (publishing a customization, running an upgrade) happens on a site nobody is using, and the cutover is a routing change measured in seconds.
The database is the hard part
Two application sites are easy. The database is where blue-green gets subtle. Acumatica's schema is tied to its build, and a customization publish can alter tables. If blue and green share one database, then publishing on green also changes the schema blue is running against — and you have lost your clean rollback. If blue and green have separate databases, then every order, invoice, and payment users entered on blue while you validated green is missing from green at cutover.
The longer green runs on a copy of the database, the more transactions accumulate on blue that green never saw. For an ERP, "reconcile the delta later" is not acceptable — you would be dropping real financial transactions. Keep the validation window on a separate database short, or freeze data entry during it.
Two shapes that actually work
The version that works for most self-hosted Acumatica shops is shared database, staged application: green points at the same database, you publish the customization during a maintenance window, smoke-test green, then flip the binding. Rollback is switching back to blue and restoring the database if the publish altered schema. The heavier version is separate database with a data freeze: clone prod to green, validate the full upgrade offline, then take a short outage to apply the same upgrade to the real database and cut over. That is closer to a rehearsed upgrade than to zero-downtime blue-green.
| Approach | Downtime | Rollback | Best for |
|---|---|---|---|
| Shared DB, staged app | Short (publish window) | Switch binding + restore DB if schema changed | Customization publishes, minor releases |
| Separate DB + data freeze | Planned outage | Keep blue + original DB untouched | Major version upgrades |
The cutover mechanism
Keep the switch itself boring and instant. A reverse proxy or load balancer in front of both sites, pointing at blue, is the cleanest — flipping the upstream is atomic and reversible. IIS host-header bindings work too if both sites live on the same server, though moving a binding is slightly less graceful than a proxy weight change. Avoid making the cutover a DNS change with a long TTL: DNS propagation is neither fast nor uniform, so some users hit green while others still hit blue, and for a shared-database setup that split-brain is confusing rather than dangerous, but it undercuts the "instant switch" you wanted.
Validating green before the switch
Green is worthless if nobody exercises it. Have a short scripted smoke test: log in, open the screens your customizations touch, create and release a test document, run a report that hits a customized DAC, confirm integration endpoints respond. This is the same validation you would run after any upgrade — the value of blue-green is that you run it before real users are exposed, on the actual production build, not on a dev box that has drifted from prod.
When it is not worth it
For a single-server, single-tenant Acumatica instance with an overnight maintenance window, full blue-green is often more machinery than the risk justifies. A tested database backup plus a documented restore is a simpler rollback than maintaining a second synchronized site, and it covers the same failure. Blue-green earns its keep when you cannot take a maintenance window — 24/7 operations, multiple time zones — or when validating a major upgrade against a full-size copy of production before touching the real database is worth the extra infrastructure.
Wrapping up
Blue-green on Acumatica is really a question about the database, not the web tier. Decide up front whether green shares the live database (short window, restore-based rollback) or runs on a copy behind a data freeze (planned outage, clean rollback), keep the cutover to an atomic proxy switch, and script the green validation. If your maintenance window already covers the risk, a proven backup-and-restore is the lazier and equally safe answer. If you want to talk through which shape fits your operation, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.